DMARC Record Checker

What DMARC Does That SPF and DKIM Can't Do Alone

SPF and DKIM are the two workhorses of email authentication, but each one checks something the recipient never actually sees. SPF (RFC 7208) verifies that the sending server is authorized by the domain in the envelope sender — the hidden Return-Path address used for bounces. DKIM (RFC 6376, updated by RFC 8301 to retire SHA-1 and require RSA keys of at least 1024 bits) verifies a cryptographic signature tied to whatever domain appears in the signature's d= tag. Neither standard looks at the From address displayed in the inbox. That gap is exactly what phishers exploit: a message can pass SPF and DKIM for a domain the attacker controls while showing your brand in the From line.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) closes that gap. It tells receiving mail servers to check whether SPF or DKIM not only passed, but passed for a domain that matches the visible From domain — a concept called alignment. It then lets you, the domain owner, publish a policy stating what receivers should do with mail that fails, and it gives you reporting so you can see who is sending mail as your domain across the entire internet. The record itself is a single DNS TXT record published at _dmarc.yourdomain.com, always beginning with v=DMARC1.

Alignment: Relaxed vs Strict

Alignment is the rule that makes DMARC meaningful. For SPF, DMARC compares the Return-Path domain against the From domain. For DKIM, it compares the d= domain in the signature against the From domain. A message passes DMARC if at least one of those two checks both passes its own validation and aligns — you do not need both, though publishing both is strongly recommended because forwarding frequently breaks SPF while a DKIM signature usually survives intact.

Alignment comes in two modes, controlled by the aspf and adkim tags. Relaxed mode (r, the default) accepts a match at the organizational-domain level: mail signed by mail.example.com aligns with a From address at example.com. Strict mode (s) requires an exact, character-for-character domain match. Relaxed is the right choice for most senders, especially if you use subdomains for marketing or transactional mail. Strict is worth considering once your setup is stable and you want to prevent one subdomain's mail stream from being able to align on behalf of another.

The Policy Ramp: none → quarantine → reject

The p tag declares what receivers should do with mail that fails DMARC, and almost every successful deployment moves through three stages. Start with p=none, which is pure monitoring mode: nothing is blocked, but aggregate reports start flowing to the address in your rua tag. Use this phase to build an inventory of every system legitimately sending as your domain — the CRM, the helpdesk, the billing platform, the newsletter tool — and fix any of them that fail alignment.

Once the reports show your legitimate mail consistently passing, move to p=quarantine, which asks receivers to treat failing mail with suspicion, typically routing it to spam. The final stage, p=reject, instructs receivers to refuse failing mail outright, which is the only setting that actually stops spoofed messages from reaching inboxes. Under RFC 9989 the old pct tag for percentage-based rollout is gone; the modern equivalents are the t=y test-mode flag and a staged rollout that enforces on subdomains via sp before tightening the main domain.

A Worked Example, Tag by Tag

Here is a realistic record you might find when running a domain through the checker above: v=DMARC1; p=quarantine; sp=reject; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-fail@example.com; fo=1. The v=DMARC1 tag identifies the record type and must always come first — RFC 9989 did not change the version string, so existing records remain valid. p=quarantine is the active policy: receivers should send failing mail to spam rather than the inbox.

sp=reject applies a stricter policy to subdomains, and np=reject covers subdomains that do not exist in DNS at all — since no legitimate mail can come from a hostname that does not exist, rejecting it is risk-free. adkim=r and aspf=r set relaxed alignment for both authentication methods, meaning organizational-domain matches count. These two are the defaults, so listing them is optional, but being explicit makes the record easier to audit.

rua=mailto:dmarc@example.com is where aggregate reports are delivered, and ruf=mailto:dmarc-fail@example.com requests per-message failure reports. fo=1 asks reporters to generate a failure report if either SPF or DKIM fails alignment, rather than only when both fail. One operational note: if you send reports to an address on a different domain than the one publishing the record, the receiving domain must publish a small authorization record; otherwise reporters will ignore the destination.

Reading Aggregate (rua) and Forensic (ruf) Reports

Aggregate reports are the heart of DMARC's feedback loop. Mailbox providers that evaluate your mail send XML summaries — typically once a day — to the mailto: address in your rua tag. Each report lists the IP addresses that sent mail claiming to be your domain, how many messages came from each, whether SPF and DKIM passed, whether they aligned, and what policy the receiver applied. They contain no message content, which is why providers send them freely.

Reading them is a matter of sorting senders into three buckets. Aligned and passing: healthy, leave alone. Legitimate but failing: usually a vendor sending with its own Return-Path or signing with its own DKIM domain — fix this by setting up a custom return-path or delegated DKIM keys with that vendor. Unknown sources: either innocent forwarding or active spoofing; these are what your eventual p=reject policy will shut down. Raw XML becomes unmanageable quickly for any domain with real volume, which is why most teams feed reports into a parsing and monitoring service rather than reading files by hand.

Forensic reports (ruf), also called failure reports, are redacted copies of individual failing messages. In practice you should not depend on them: the large mailbox providers generally decline to send them because of privacy concerns, and RFC 9989 reflects this reality by removing the rf report-format tag entirely. Treat ruf as occasionally useful extra signal, never as your primary data source.

Subdomain Policies: sp and np

By default, subdomains inherit your main policy from p. The sp tag lets you override that, which is useful in both directions. While ramping up, some teams keep p=none on the organizational domain but set sp=reject early, since spoofers love inventing plausible subdomains like secure.example.com or billing.example.com. Later, mature deployments sometimes run p=reject with a looser sp for a subdomain still being migrated.

RFC 9989 adds np for non-existent subdomains — names with no A, AAAA, or MX records in DNS. Because nothing legitimate can originate there, np=reject is one of the few DMARC settings you can apply immediately with essentially zero risk, and it cuts off a popular spoofing technique on day one.

What RFC 9989 (DMARCbis) Changed

RFC 9989, often called DMARCbis, is the updated DMARC standard, and it requires no version change: records still start with v=DMARC1, and a well-formed existing record keeps working. Three tags were removed. pct, the percentage rollout knob, was dropped because receiver implementations were too inconsistent for it to behave predictably. rf (failure report format) and ri (requested reporting interval) were removed because receivers largely ignored them anyway — aggregate reports simply arrive on the reporter's own schedule, normally daily.

Three capabilities were added or formalized. The t tag provides an explicit test mode: t=y tells receivers the published policy is being trialed and they may choose not to enforce it strictly, filling the role the old pct=0 once played. The np tag, covered above, handles non-existent subdomains. And the psd tag lets public suffix operators — registries running zones like country-code top-level domains — participate in DMARC; ordinary senders will rarely need it. The standard also replaces the old Public Suffix List lookup with a DNS tree walk for determining the organizational domain, which makes alignment decisions more predictable.

DMARC Tag Reference (RFC 9989)

The table below summarizes the tags defined in RFC 9989, plus the three legacy tags you may still encounter in older records. The checker above flags removed tags so you can clean them out of your record.

Why Gmail and Yahoo Made DMARC Mandatory for Bulk Senders

DMARC moved from best practice to hard requirement when Gmail and Yahoo began enforcing sender requirements for bulk mailers. Senders above roughly five thousand messages a day to Gmail addresses must publish a DMARC record with at least p=none, must authenticate with both SPF and DKIM, and the From domain must align with at least one of them. Yahoo applies materially similar rules. Mail from non-compliant bulk senders is increasingly deferred or rejected outright rather than merely filtered.

Even if you sit below the bulk threshold today, treating these requirements as the baseline is the safe play: thresholds are measured across your whole organizational domain, marketing volume can spike without warning, and other providers tend to follow where the largest mailbox operators lead. A monitored p=none record costs nothing in deliverability and gets the reporting pipeline flowing — run your domain through the checker above to see exactly where you stand.

There is also a carrot to go with the stick. BIMI (Brand Indicators for Message Identification) displays your logo beside authenticated mail in supporting inboxes, and it requires DMARC at enforcement — p=quarantine or p=reject — as a prerequisite. The logo must be published as an SVG in the restricted SVG Tiny 1.2 Portable/Secure (P/S) profile, and Gmail additionally requires a Verified Mark Certificate (VMC) attesting to trademark ownership before it will show the logo, while Yahoo and AOL can display BIMI logos without one.

Frequently asked questions

Do I need both SPF and DKIM to pass DMARC?

No — DMARC passes if either SPF or DKIM passes and aligns with the From domain. That said, you should set up both. Forwarding commonly breaks SPF because the forwarder's server is not in your SPF record, while a valid DKIM signature usually survives forwarding, so having both gives your mail two chances to pass.

How long should I stay at p=none?

Stay until your aggregate reports show every legitimate sending source passing with alignment — there is no fixed calendar. For a simple domain with one or two senders that can be a few weeks; large organizations with many vendors often need longer. The mistake to avoid is staying at p=none indefinitely, because monitoring mode blocks nothing.

Is the pct tag still valid?

No. RFC 9989 removed pct along with rf and ri, and modern receivers ignore them. If you want a cautious rollout, use t=y to signal test mode, or enforce on subdomains first via sp before tightening the main domain. Leaving pct in a record will not break it, but it does nothing.

Why am I not getting any forensic (ruf) reports?

Most major mailbox providers simply do not send them, because forwarding even redacted copies of individual messages raises privacy concerns. This is expected behavior, not a configuration error. Build your monitoring around aggregate (rua) reports, which nearly all significant receivers send reliably.

My SPF passes — why does DMARC still fail?

Almost certainly an alignment problem. SPF is evaluated against the Return-Path domain, and many sending services use their own domain there, so SPF passes for the vendor's domain but does not align with your From domain. The fix is usually enabling a custom return path and delegated DKIM signing with that vendor.

What DMARC record should a domain that never sends email have?

Park it defensively: publish v=DMARC1; p=reject at _dmarc, an SPF record of v=spf1 -all, and no DKIM keys. This tells the world that any mail claiming to come from the domain is forged and should be refused. Parked and brochure-only domains are favorite spoofing targets precisely because nobody is watching them.

Where exactly does the DMARC record live?

It is a single TXT record at the host _dmarc under your domain — for example _dmarc.example.com — and its value must start with v=DMARC1. Publishing more than one DMARC TXT record at that name invalidates DMARC processing entirely, which is one of the most common errors the checker above detects.