DMARC p=reject: how to move from p=none safely

What p=reject does, and why p=none is not the end#

A DMARC record is a TXT record at _dmarc. plus your domain. Its p= tag is the domain owner’s handling preference for mail that uses the domain in the From header but fails DMARC. RFC 9989, the Standards Track version of DMARC published in May 2026, defines three values: none (“no expression of preference”), quarantine (the mail is suspicious) and reject (“a clear indication that the use of the domain name is not valid”).^[1] It obsoletes RFC 7489, the 2015 Informational document most tutorials still quote.^[2]

p=none is where every rollout starts, and it is enough to meet the bulk-sender rules: Gmail says “your DMARC enforcement policy can be set to none”,^[3] Yahoo asks for “at least p=none”,^[4] and Outlook.com accepts none, quarantine or reject.^[5] (The full rules are in the bulk sender requirements checklist.) But p=none protects nobody: a phishing message forging your From address is delivered exactly as it would have been without the record. Only an enforcement policy — quarantine or reject — asks receivers to act on it, and that is what the rest of this guide is about.

How DMARC decides: alignment and the organizational domain#

DMARC passes when SPF or DKIM passes and the domain it authenticated aligns with the domain in the From header. One aligned pass is enough; RFC 9989 asks senders for “at least one — preferably two”.^[1]

• SPF authenticates the envelope sender (the MAIL FROM, or return path), not the From header you see.^[7] A service that bounces mail to its own domain passes SPF for its domain, which does not align with yours.
• DKIM authenticates the domain in the signature’s d= tag, “the SDID claiming responsibility” for the message.^[8] A service signing with its own d= passes DKIM without aligning.

Relaxed and strict alignment#

Alignment has two modes, set by adkim= and aspf=, both relaxed by default. Relaxed alignment means the From domain and the authenticated domain share an organizational domain; strict means they are identical.^[1] Under relaxed alignment, a From of example.com aligns with a DKIM d=news.example.com or a return path at bounce.example.com; under strict, neither aligns. Stay relaxed unless you have a reason not to: nearly every sending service puts its return path on a subdomain.

The organizational domain#

The organizational domain is the registered domain a name belongs to — example.com for mail.eu.example.com. RFC 7489 left finding it to a public suffix list; RFC 9989 defines a “DNS Tree Walk” that queries _dmarc records up the name, capped at eight queries.^[1] For an ordinary company domain both give the same answer, and the practical rule is the same: a subdomain with no DMARC record of its own is governed by the organizational domain’s.

Play video: DMARC Training-4: DMARC Reporting

Before you start: what has to be true#

RFC 9989 lists the domain owner’s work in order: publish SPF for an aligned domain, configure DKIM with an aligned signing domain, set up a mailbox for aggregate reports, publish the record, then collect, analyse and remediate before deciding on enforcement.^[1] Three things make that go smoothly.

1. An inventory of who sends as you. Your mail platform, your marketing tool, the helpdesk, the invoicing system, the CRM, the office printers that email scans. Write down what you know; the reports will find the rest.
2. DKIM on every stream you control. Forwarding breaks SPF but usually leaves DKIM intact, which is why RFC 9989 says domains publishing p=reject “MUST NOT rely solely on SPF” and “MUST apply valid DKIM signatures”.^[1]
3. A way to read the reports. They are XML, and RFC 9989 recommends they be machine-parsed.^[1] A parsing service or a small script both work; reading raw files by hand stops working after the first week.

Step by step: from p=none to p=reject#

The order is the one RFC 9989 describes and Google’s own rollout guide follows: monitor, fix, then tighten in steps, reading reports between each.^[9]

1. 1

   List every service that sends as your domain

   Write down your mail platform, marketing tool, helpdesk, billing system, CRM and anything else that puts your domain in the From header. The aggregate reports will show you what the list missed.

2. 2

   Publish p=none with a report address

   Add a TXT record at _dmarc on your domain with v=DMARC1; p=none; and a rua=mailto: address that a person or a parsing service reads. Delivery does not change; receivers start sending daily aggregate reports.

3. 3

   Read the reports for a full sending cycle

   Match every source in the reports to a service. Google suggests at least a week; RFC 9989 suggests a month for domains whose users write to mailing lists. Wait for the monthly and quarterly sends to appear too.

4. 4

   Fix every legitimate source

   Give each service DKIM signing with your own domain in d= and, where it can, a return path on a subdomain of yours, until every legitimate source passes DMARC on an aligned DKIM signature.

5. 5

   Move to p=quarantine

   Publish p=quarantine, with a low pct first if you like. Receivers that follow RFC 9989 ignore pct and quarantine all failing mail, so take this step only when the reports show no legitimate source failing.

6. 6

   Move to p=reject and close unused names

   Once quarantine has run cleanly for a comparable period, publish p=reject with np=reject for subdomains that do not exist, and bring any subdomain with its own _dmarc record to the same policy.

7. 7

   Keep reading the reports

   Leave rua in the record. A new tool, a vendor change or a forwarding problem shows up in the reports first, and every new sender needs aligned DKIM before it goes live.

The records, stage by stage, for a domain whose reports go to its own mailbox:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

How long each stage should last#

Google suggests a week at p=none as “usually enough time for the daily reports to contain data representative of all your mail streams”, and a starting percentage of 10% for a small organisation or 1% for a large one.^[9] The standard is more cautious for domains whose people write to mailing lists:

Monthly and quarterly senders need longer: the invoice run that goes out on the first of the month will not appear in a week of reports. RFC 9989 warns it “may take many months” for a domain owner to be sure all its mail is authenticated.^[1] Move on when a full sending cycle shows no legitimate source failing, not when a calendar says so.

Reading DMARC aggregate reports#

Aggregate reports are defined in RFC 9990: daily (or more frequent) XML summaries from each receiver, listing every source that used your domain in the From header, how many messages it sent, and how SPF, DKIM and DMARC evaluated.^[10] Receivers send them only if your record has a rua= tag.^[1]

For each source IP in a report, ask four questions:

1. Is it mine? Resolve the IP and match it to a service in your inventory. Unknown sources at low volume from scattered networks are usually spoofing.
2. Did DKIM pass, and for which domain? Look at the raw DKIM result and its domain, not only the evaluated verdict.
3. Did SPF pass, and for which domain? A pass for the vendor’s bounce domain is not an aligned pass.
4. Does the DMARC verdict pass on at least one leg? If only SPF carries it, fix DKIM before enforcement: forwarding will break the SPF leg.

The existing post DMARC policy: none, quarantine or reject walks through one report record line by line. If your rua address is on another domain — a reporting service, say — that domain must publish a <your-domain>._report._dmarc.<their-domain> TXT record authorising it, or receivers will not send the reports.^[10]

Finding and fixing unauthenticated senders#

RFC 9989 is blunt: the failing streams in your reports mix abuse with “legitimate uses … not passing due to Authenticated Identifiers being unaligned or missing entirely”, and the legitimate ones “MUST be addressed prior to” enforcement.^[1] Google says the same of third-party services: they must pass SPF and DKIM.^[11] The fixes, most reliable first:

A return path on your own subdomain is what makes the SPF leg align; how it works is in custom return path, explained. When a service cannot sign with your domain at all, move it to a subdomain with its own DMARC record, or send its mail from an address on a domain that is not yours to protect — do not hold the whole domain at p=none for one tool.

pct, t=y and what RFC 9989 changed#

RFC 7489 offered pct=: apply the policy to that percentage of failing mail, and treat the rest one step softer — quarantine instead of reject, normal filtering instead of quarantine.^[2] RFC 9989 removed it. The reason given: “the ‘pct’ tag was usually not accurately applied, unless the value specified was either 0 or 100”. It is replaced by t=, a testing flag whose values y and n are meant to behave like pct=0 and pct=100.^[1]

Unknown tags “MUST be ignored”,^[1] which is what makes the table asymmetric. Three practical consequences while both generations are in service:

• Treat every quarantine step as possibly total. A pct=10 record still dampens the rollout at receivers that honour it, and Google’s rollout guide still uses it,^[9] but a receiver on the new standard quarantines everything. Publish quarantine only when the reports show no legitimate source failing.
• Never publish t=y alone to soften a policy. Older receivers ignore it and apply the full policy.
• A rehearsal for reject reads the same everywhere: p=reject; pct=0; t=y means quarantine to both generations. It is equivalent to stage 3, so skip it unless you want the reports to show the reject policy early.

Subdomains: sp= and np=#

p= covers the domain and its subdomains unless you say otherwise. sp= sets the policy for existing subdomains, and np= — new in RFC 9989, imported from RFC 9091 — for subdomains that do not exist in DNS. Without np=, non-existent names get sp=, or failing that p=.^[1] Google’s help says the same: without sp=, “subdomains inherit the DMARC policy set for the parent domain.”^[11]

• Close non-existent names early. Nobody legitimately sends from invoices-secure.example.com if it does not exist, so np=reject costs nothing and can go in while the apex is still at quarantine.
• A subdomain’s own record wins. A _dmarc.news.example.com record overrides the parent for that name, in both directions. A forgotten p=none on a subdomain is a hole in an otherwise enforced domain.
• Move a difficult stream aside. If one tool cannot align yet, send it from a subdomain with its own softer record and take the apex to reject. The trade-offs of doing that on purpose, for marketing mail, are in should you use an email subdomain for marketing?

Forwarding, mailing lists and p=reject#

Indirect mail flows are DMARC’s known weak spot. When mail is forwarded — an alumni address, a role alias — the forwarding server’s IP is not in your SPF record, so SPF fails, while “DKIM signatures will generally remain valid”.^[1] RFC 7960 documents the wider set of cases, including lists that rewrite the subject or add a footer and so break DKIM too.^[12]

The consequence matters most for a domain whose people use email to talk. RFC 9989 says domains “that host users who might post messages to mailing lists SHOULD NOT publish” p=reject, and those that do should warn their users.^[1] It also notes that list software has broadly adopted workarounds — rewriting the From to the list’s own address — and that ARC is the long-running attempt to carry authentication across hops.^[1]

Myths about DMARC enforcement#

• Unproven “p=reject improves your inbox placement.” No mailbox provider documents a placement reward for reject over none; Gmail, Yahoo and Outlook.com accept p=none.^[3][4][5] Enforcement protects your name from forgery; it is not a deliverability boost.
• Documented by Google “p=none is enough for the bulk-sender rules.” True, and Google says so.^[3] It is a floor, not protection.
• “pct=10 quarantines exactly 10%.” False even before RFC 9989, which found values other than 0 and 100 “usually not accurately applied”; under RFC 9989 the tag is ignored.^[1]
• “SPF alone is fine for reject.” The standard says the opposite: a domain at reject “MUST apply valid DKIM signatures”.^[1]
• “Reject means every forged message bounces.” Receivers may accept failing mail and apply their own analysis.^[1] In practice, the same document notes, mail that fails a reject policy “is frequently rejected”, so plan as if it will be.
• “DMARC is set-and-forget.” A new tool or a changed vendor can start failing any day, and the reports are how you find out; RFC 9989 calls consuming them “essential to any successful DMARC deployment”.^[1]

After p=reject: keep watching#

Leave rua= in the record for good. dmarc.org’s own summary of deployment is to move the policy “from ‘none’ to ‘quarantine’ to ‘reject’ as you gain experience”,^[14] and experience keeps arriving: a new vendor added without DKIM shows up in the reports before it shows up as a complaint. Two more things open up at enforcement. BIMI — the brand logo beside your name in supporting mail apps — requires p=quarantine or p=reject in Gmail,^[13] and the forgery that p=none only reported is now refused.

On Rasket, a verified domain signs every message with DKIM under your own domain and puts the return path on send. your domain, so both legs align under relaxed alignment. The DMARC card on the domain page builds the record in three steps — a policy, a report address and a record to copy — starting at monitor only; on a subdomain it writes the record for the parent domain unless you ask otherwise. Its middle step writes p=quarantine; pct=25, which you should read, as above, as “up to all failing mail”. See verified domains and the domains documentation; the three records themselves are covered in DKIM, SPF and DMARC explained.