Module 3: Email authenticationLesson 10 of 136 min read
DMARC policy rollout: from p=none to p=reject safely
SPF and DKIM each prove something about a message, but neither looks at the From address the reader actually sees. DMARC closes that gap: it checks that a passing SPF or DKIM result belongs to the same domain as the From address, tells receivers what to do when it doesn't, and asks them to send reports. DMARC became an IETF Proposed Standard in May 2026 as RFC 9989, which replaces the 2015 RFC 7489.
Alignment: the core idea
DMARC calls the domain in the visible From address the Author Domain. A message passes DMARC if at least one of these holds: SPF passed for a MAIL FROM domain that aligns with it, or a DKIM signature verified with a d= domain that aligns with it. Google's guidelines put it in one line: the authenticating domain must be the same domain that appears in the From header.
Alignment can be relaxed or strict, set with aspf= and adkim=; both default to relaxed. Relaxed means the two domains share the same Organizational Domain, roughly the registered domain, so d=mail.example.com aligns with From: news@example.com. Strict requires an exact match.
Why a newsletter fails DMARC
From: news@example.com. The email service sends with MAIL FROM bounce@mailer.example.net (SPF passes, but for example.net) and signs with d=mailer.example.net (DKIM passes, also example.net). Neither result is aligned with example.com, so DMARC fails even though SPF and DKIM both pass. Fix: set up the service to sign with d=example.com, or a subdomain of it, using a key you publish.
The record and its tags
The policy is a TXT record at _dmarc.example.com. The tags you will meet most often in RFC 9989:
- v=DMARC1: must be the first tag, or the record is ignored.
- p=: the policy for failing mail. none expresses no preference, quarantine says such mail is suspicious, reject says failures clearly mean the domain is being misused. A record without p= is treated as p=none.
- rua=: where aggregate reports go, usually a mailto: address. Without it, receivers must not send aggregate reports.
- sp= and np=: separate policies for existing subdomains and for subdomains that don't exist.
- t=: test mode, new in RFC 9989. t=y asks receivers to apply one level less than the policy: quarantine is treated as none, reject as quarantine.
- adkim= and aspf=: alignment mode, r (relaxed, the default) or s (strict).
What happened to pct=
RFC 7489 had a pct= tag to apply the policy to a percentage of failing mail. RFC 9989 removed it: operational experience showed values other than 0 and 100 were applied inconsistently. You will still see pct= in existing records and in older guides; pct=100 was the default and changes nothing. For a gradual step, RFC 9989 offers t=y instead.
Reports show who sends as you
Aggregate reports are XML files, defined in RFC 9990, that receivers send to the rua address. They summarise the mail they saw using your domain: which IP addresses sent it, how many messages each sent, and the SPF and DKIM results with the domains they were checked for. RFC 9989 recommends parsing them with software, since they are not designed for reading by eye.
Reports are how you find the senders you forgot: the billing system, the help desk, a partner who sends on your behalf. RFC 9989 says these shortcomings must be fixed before moving to an enforcing policy, and that reaching confidence can take many months, depending on how often each kind of mail is sent.
A rollout plan
RFC 9989 describes the order of work. Durations depend on your mail; the plan below is an example for a small organisation that sends some kinds of mail only monthly.
Example plan for example.com
Step 0: make sure every service sends with aligned SPF or DKIM, ideally both. Step 1: publish v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com and read reports for at least two full monthly cycles. Step 2: fix every legitimate source that fails alignment. Step 3: p=quarantine; t=y for a few weeks, which asks receivers to apply none for now, then remove t=y. Step 4: p=reject; t=y, then p=reject. At every step, keep reading reports and step back if a real sender starts failing.
What the big mailbox providers require
Google requires SPF, DKIM and DMARC from bulk senders, with messages aligned with the From domain, and recommends DMARC reports to see who sends as you. Yahoo's bulk sender rules require a valid DMARC policy of at least p=none, DMARC must pass, relaxed alignment is acceptable, and a working rua address is strongly recommended.
Both rules stop at p=none, which only monitors. Spoofed mail is still delivered until you move to quarantine or reject, which is why the rollout is worth finishing.
Read a domain's DMARC record tag by tag. The headline shows Policy with its p= value, the table explains each tag, and Suggested next DMARC record shows the next step for that domain. Whole email setup grades MX, SPF, DKIM and DMARC together.
DMARC checkerQuick check
Three questions. Pick an answer to see why.
SPF passes for mailer.example.net and DKIM passes with d=mailer.example.net. The From address is news@example.com. Does DMARC pass?
Show the answer
Answer: No, because neither passing domain is aligned with example.com Alignment is the core of DMARC; passing for an unrelated domain doesn't count.
Why does RFC 9989 recommend starting with p=none and an rua address?
Show the answer
Answer: So the reports reveal legitimate senders that would fail before any mail is rejected Starting at none lets the domain owner audit its own mail streams through aggregate reports.
A record has p=reject; t=y. How should receivers treat failing mail under RFC 9989?
Show the answer
Answer: As quarantine, one level below the stated policy t=y requests one level less: reject becomes quarantine, quarantine becomes none.
Standards, not guesses
These guides explain how the internet's plumbing works, using the published standards (RFCs) and official documentation. Each guide shows the date it was last checked.
Sources
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 9990: DMARC Aggregate Reporting
- Google Workspace Admin Help – Email sender guidelines
- Yahoo Sender Hub – Sender requirements and recommendations
Last checked October 28, 2026