NetDetectHubGet the app

Home / Learn

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: [email protected]. Strict requires an exact match.

Why a newsletter fails DMARC

From: [email protected]. The email service sends with MAIL FROM [email protected] (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:[email protected] 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 checker

Quick check

Three questions. Pick an answer to see why.

  1. SPF passes for mailer.example.net and DKIM passes with d=mailer.example.net. The From address is [email protected]. 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.

  2. 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.

  3. 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

Last checked October 28, 2026

Results come from public DNS, registry and certificate data and from checks run from Cloudflare's network at the moment you ask. They can differ from what another network sees. How our tools work · Terms of use.