What is DMARC? Policy, reports and getting to p=reject

DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is a DNS record that protects the domain people see in the From line. It has receivers check that SPF or DKIM passed for that domain, tells them what to do with mail where neither did, and asks them to report on every message that used your name.

Since May 2026 it has been on the IETF standards track: RFC 9989 replaced the informational RFC 7489 of 2015, with reporting moved into RFC 9990 and RFC 9991. Adoption is still uneven. EasyDMARC's 2026 scan of the top 1.8 million domains found a DMARC record on 52.1% of them, and fewer than half of those records at quarantine or reject.

For how the three records fit together, start with our overview of SPF, DKIM and DMARC. This guide goes deeper into DMARC alone.

What DMARC adds to SPF and DKIM

SPF and DKIM each vouch for a domain, but neither has to be the one in From. SPF checks the envelope sender, a hidden return address, and DKIM checks the signing domain in d=. As RFC 9989 points out, anyone can pass both for a domain they own and still put your name in From.

DMARC adds one rule: a message passes when SPF or DKIM passes and the domain it passed for aligns with the From domain. Alignment comes in two strengths, set with aspf and adkim:

Relaxed alignment asks for the same organisational domain, strict for the identical name. RFC 9989 notes that nearly every domain owner finds relaxed enough, and strict fails any service that bounces or signs from a subdomain such as bounces.example.com. Our guides to SPF and DKIM cover the two checks underneath.

The organisational domain and the DNS tree walk

Relaxed alignment and subdomain inheritance both rest on the organisational domain, the name that news.example.com and example.com share.

RFC 7489 found it with a public suffix list, the suffixes such as co.uk that people register domains under. RFC 9989 replaces the list with a DNS tree walk: with no record at _dmarc on the From domain, the receiver queries each parent in turn, at most eight lookups in all. The organisational domain is the name with the fewest labels that publishes a valid record, unless a psd tag says otherwise.

For a domain that publishes at its registered name, as most do, both methods agree, and subdomains without a record of their own find the apex one.

What a DMARC record looks like, tag by tag

A DMARC record is one TXT record at _dmarc on your domain. Here is one with the common tags spelled out:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r"

Records written for RFC 7489 stay valid, since the version is still DMARC1 and receivers ignore tags they do not know. That bites a record that relies on one. A newer receiver ignores pct, which was rarely applied accurately except at 0 and 100, so p=reject; pct=10 is full rejection there. An older one ignores t, so p=quarantine; t=y is full quarantine. A test step meant to work everywhere carries both, as in p=reject; pct=0; t=y, which both read as quarantine.

Many DNS hosts add your domain to the name themselves, so enter only _dmarc or the record lands at _dmarc.example.com.example.com.

Ready to write yours? The DMARC record generator reads the record your domain publishes today, explains each tag and builds the next one to copy. As you build, it warns about a missing rua, a jump straight to p=reject, a pct below 100, any ruf and strict alignment.

DMARC policies: none, quarantine and reject

p=none asks for reports and nothing else. RFC 9989 says a receiver must not change how it handles your mail because of it, so it stops nothing.

p=quarantine marks failing mail as suspicious. RFC 7489 lists the spam folder, closer scrutiny or a warning flag as what that can mean.

p=reject asks receivers to refuse failing mail during the SMTP conversation, with a reply such as 550 5.7.1 Email rejected per DMARC policy for example.com. Some accept it and discard it silently instead.

The receiver makes the final call. RFC 9989 tells receivers not to reject on p=reject alone and, without other evidence, to treat such mail as quarantined, because forwarders and mailing lists break authentication. It also admits that few hold back, so list mail with an unchanged From is often refused, and Yahoo rejects p=reject mail that has neither a proper DKIM signature nor SPF alignment. Sign everything with DKIM first: forwarding breaks SPF but usually spares the signature, and the standard forbids relying on SPF alone at p=reject.

How to read DMARC aggregate reports

Aggregate reports are why rua matters most. Each receiver that reports sends one per domain at least every 24 hours, usually for one UTC day: an XML file, normally gzipped, attached to an email. Each record counts what one IP address sent as your domain, with what SPF and DKIM found. This trimmed one shows the most common finding:

<record>  <row>    <source_ip>192.0.2.123</source_ip>    <count>412</count>    <policy_evaluated>      <disposition>none</disposition>      <dkim>fail</dkim>      <spf>fail</spf>    </policy_evaluated>  </row>  <identifiers>    <header_from>example.com</header_from>  </identifiers>  <auth_results>    <dkim>      <domain>crm.example.net</domain>      <selector>s1</selector>      <result>pass</result>    </dkim>    <spf>      <domain>bounces.crm.example.net</domain>      <result>pass</result>    </spf>  </auth_results></record>

SPF and DKIM both passed, but for the CRM's own domains, so policy_evaluated fails both. That is a real sender that needs DKIM with your domain before you tighten anything. Look for four things:

• Services you know that fail alignment. Turn on their DKIM for your domain, or give them a return path on it.
• Sources you do not know. Usually forgery, which is what enforcement is for.
• Mail that fails SPF but passes aligned DKIM. Usually forwarding, and harmless while you sign.
• A reason in policy_evaluated. The receiver overrode your policy, for example for a mailing list, a trusted forwarder or test mode.

Why failure reports rarely arrive

Failure reports describe single messages and can carry their headers and content. RFC 9991 notes that many large providers limit them or switch them off, and RFC 9989 says receivers worried about privacy redact them heavily or send none. Leave ruf out unless you have a specific problem to debug.

Sending reports to another domain

When rua points at another organisational domain, such as a reporting service, receivers first check that the other domain agreed, which it does with a TXT record named after your domain:

example.com._report._dmarc.reports.example.net.  TXT  "v=DMARC1"

Without it, receivers ignore that address. A service that takes reports for any domain publishes the wildcard *._report._dmarc.reports.example.net instead.

How to move from p=none to p=reject

1. List every sender. Beyond your mailbox provider and email API, the ones people forget are the CRM, billing and invoicing, the help desk, scheduling tools that send calendar invitations as the organiser, and the office scanner.
2. Make each one align. Turn on DKIM with your domain in every service, and give it a return path on your domain where it offers one.
3. Publish p=none with rua and read at least a month of reports, which RFC 9989 asks of any domain whose users post to mailing lists.
4. Move to p=quarantine once every legitimate source aligns, and watch it as long again.
5. Move to p=reject and keep rua. New tools get added, and the reports are how you notice one failing.

A domain with two or three senders can move faster, and a large organisation can need many months, as the standard warns. t=y softens a step by a level while reports keep coming, and np=reject asks receivers that read it to refuse mail from subdomains that do not exist.

One caution: RFC 9989 says a domain whose users post to public mailing lists should not publish p=reject, or should warn them if it does. Most list software now rewrites From to cope, but a list that leaves From unchanged still gets those posts refused.

DMARC requirements at Gmail, Yahoo and Outlook

All three large consumer mailbox providers require DMARC from bulk senders, and all three accept p=none:

Enforcement has hardened since. Gmail has been ramping it up since November 2025 with temporary and permanent rejections, and expects alignment with both SPF and DKIM to become a requirement. Outlook.com refuses non-compliant bulk mail with 550 5.7.515. The deliverability checker shows where a domain stands, reading its SPF, DKIM, DMARC, BIMI and MX records from live DNS.

DMARC and BIMI

BIMI, which lets inboxes show your logo beside your mail, works only at enforcement. The BIMI Group's implementation guide asks for p=quarantine or p=reject on the organisational domain and its subdomains, and accepts neither p=none nor a pct below 100. The BIMI checker shows whether a domain's record and logo are ready.

Common questions about DMARC

Is p=none enough?

For the bulk sender rules at Gmail, Yahoo and Outlook.com, yes. For protection, no: receivers must not treat your mail differently at p=none, so forgeries still arrive and no logo shows.

Do I need DMARC if I have SPF and DKIM?

Yes. Both can pass for a forger's own domain while yours sits in From. Only DMARC checks that the passing domain is yours, says what to do when it is not and sends you reports.

How long does it take to reach p=reject?

At least two months on RFC 9989's advice: a month or more at p=none, then as long at quarantine, and longer with many sending tools.

Can a domain have two DMARC records?

No. Receivers discard every record at a name that holds more than one, so two count as none. Merge them.

Does DMARC stop phishing?

At quarantine or reject it lets receivers stop mail forging your domain and its subdomains. Display names are outside its scope, as RFC 9989 says, so "Example Billing" over a stranger's address gets through, and so does a lookalike domain with passing records of its own.

Where Nextmail fits

Each domain you add to Nextmail gets a DMARC tab that shows the policy it publishes, what is wrong with it and, once it has read a record, a link to the DMARC record generator with the domain filled in. A domain with no record gets a starter at p=none whose rua is <domain>@dmarc.nextmail.sh, to copy into your DNS or write with a sync. The wildcard authorisation record for that address is already published, so receivers send the reports, and Nextmail keeps them with the domain, encrypted, up to 100 a day. Reading them inside Nextmail is not there yet.

Tightening the policy stays your decision, made on the DMARC tab, and Nextmail refuses quarantine or reject until the domain's mail is signed. DMARC policy covers the starter record, Connect a domain the setup, Multiple domains how each record is checked against live DNS, and the deliverability check the same tests over the API.