Moving from p=none to p=reject

Why p=none is not protection

A record with p=none asks receivers for reports and nothing else. RFC 9989 is explicit that a discovered none policy must not change how a receiver already handles mail. A forged invoice that claims to come from your domain is judged exactly as it would be without any DMARC record: by the receiver's own spam filters, with no instruction from you. The forgery fails DMARC, the failure shows up in your next report, and the message may still land in the inbox.

The standard has a word for the state you are aiming at. It calls a domain "in Enforcement" when the policy for the organizational domain and every subdomain below it is something other than none. Only then can your domain appear in the From line solely when the message really authenticates.

A monitoring record satisfies the Gmail, Yahoo and Outlook sender requirements, but it does nothing to stop someone else from using your name.

Before you start: list everything that sends as you

Every problem in a p=reject rollout comes from the same place: a legitimate system that sends with your domain in the From line and was never set up to authenticate. Writing the list down before the first record goes live saves you from discovering those systems one bounced invoice at a time. Walk through these groups and ask the people who own each one:

• Your mailbox provider: the people in your company writing ordinary email.
• Marketing and newsletters: campaigns, product announcements, automated drip sequences.
• Transactional mail: receipts, password resets, sign-up confirmations sent by your app.
• Help desk and support: ticket replies that go out as support@ or help@ your domain.
• Billing and finance: invoices and payment reminders from an accounting or billing system.
• Your own servers and devices: website contact forms, cron jobs, monitoring alerts, office scanners.

Then list your subdomains. Note which ones send mail, such as a mail. or news. subdomain a marketing tool uses, and which ones never should. A policy on the organizational domain covers the subdomains as well unless you say otherwise, so they belong in the plan from day one.

Last, decide where reports go. The rua tag needs a mailbox that can take a steady stream of XML attachments from the receivers that send reports. The RFC recommends parsing them by machine rather than reading them by hand, which means either your own tooling or a report service. Without that mailbox, nothing in the rest of this plan can be measured.

Step 1: monitor with p=none

Publish a monitoring record at _dmarc with your report address. If an older DMARC record already exists, edit it rather than adding a second one, because two records at the same name are discarded together.

How long to stay here depends on how your domain sends, not on a fixed number of days: a monthly invoice run appears once a month, a yearly renewal reminder once a year. RFC 9989 notes it can take many months of reports before an owner is sure everything authenticates. Stay until every mail stream on your inventory has appeared in a report.

As the reports come in, go through the sources by volume and answer three questions for each one:

1. Is this one of the systems on my list, or something I did not know about?
2. Does it pass DKIM with a signature from my domain, and does it pass SPF for a return-path on my domain?
3. If neither is aligned, which of the two is easier to fix with this particular service?

A report row shows the source IP, the message count, the DKIM and SPF results and the domains they were checked for. How to read DMARC aggregate reports walks through those fields with an annotated example if you have not opened one before.

Step 2: fix alignment one sender at a time

Each sending service has to pass SPF or DKIM for your domain or one of its subdomains, and it gets there in one of two ways. If SPF passes but DMARC still fails, DMARC fails even though SPF passes explains the mismatch.

• SPF alignment needs the envelope sender, the return-path, to be on your domain. Services offer this as a custom return-path or bounce domain on a subdomain of yours. Postmark asks for a pm-bounces CNAME, SendGrid includes one in the records its automated security creates, and Amazon SES calls it a custom MAIL FROM domain, set up with an MX and an SPF record on the subdomain.
• DKIM alignment needs the service to sign with your domain in the d= tag. You publish the keys it gives you, usually as CNAME records under _domainkey. Mailchimp relies on this alone: it keeps its own return-path, so SPF never aligns, and DMARC passes through DKIM.

RFC 9989 asks for at least one aligned identifier and preferably two. For a domain heading to p=reject the DKIM half is not optional: the standard says such a domain must not rely on SPF alone and must sign its mail. Treat every service that passes only on SPF as unfinished.

A help desk is a typical example of a sender that gets missed. Ticket replies go out as support@ your domain, but they are sent by the help desk provider's servers. Look in its settings for a domain verification or email authentication page, which normally lists the DKIM records to publish. If a service offers no way to sign with your domain and no custom return-path, it cannot pass DMARC as you. The choices then are to send that mail from an address on the provider's own domain or to replace the service before you enforce.

Fix one sender, wait for the next reports to confirm it passes aligned, then move to the next. The Mailchimp DKIM setup guide, the Postmark return-path guide and the Amazon SES custom MAIL FROM guide show the exact records for those services. The DKIM checker confirms a published key, and if you do not know which selector a service uses, how to find your DKIM selector covers three ways to get it.

Step 3: test quarantine, then enforce it

Once the reports show every sender on your list passing aligned, you start tightening. The path has five stages. Each enforced policy is tested first, so receivers see the stricter record for a while before they act on it:

The testing stages use the t tag that RFC 9989 introduced. With t=y, the domain owner tells receivers it is testing and expects failing mail to get one level less than the published policy. Section 4.7 spells out both cases: p=quarantine; t=y means failing mail is handled as if the policy were none, and p=reject; t=y means it is quarantined rather than rejected. The tag never affects reporting, so your reports keep arriving at full detail.

Why t=y and pct=0 go together

Not every receiver has moved to RFC 9989 yet, so the testing record speaks both versions at once. A receiver built on RFC 7489 does not know t and, as that document requires for any unknown tag, ignores it. It does know pct=0: apply the policy to none of the failing mail. RFC 7489 says mail left out of a reject policy that way should be treated as quarantine, and mail left out of a quarantine policy gets the receiver's normal handling. A receiver built on RFC 9989 ignores pct, a tag the standard removed and now lists as historic, and follows t=y. Both land on the same result: one level below the published policy.

This is not an accident. Appendix A.6 of RFC 9989 explains that pct=0 had taken on a meaning of its own: some intermediaries, mailing lists in particular, rewrote the From header for domains that published it. The authors kept that signal and renamed it, defining t=y and t=n as the counterparts of pct=0 and pct=100. A useful side effect for you: while a testing record is live, the reports show how much of your mail passes through intermediaries that do not rewrite the From header.

Records that still use pct=25 or pct=50

Older rollout guides told people to raise pct in steps. Today a receiver that follows the new standard ignores pct=25 and applies the whole policy, while an older one samples roughly a quarter of failing mail. Neither gives you the gradual ramp the number promises. Treat such a record as a testing stage that has not finished: when your reports are clean, publish the same policy without pct; if they are not, go back to t=y; pct=0 until they are.

Here is the quarantine testing record, and the full quarantine record you publish after it:

After each change, compare the next reports with the previous ones: from quarantine on, a missed sender's mail goes to spam instead of the inbox.

Step 4: test reject, then enforce it

With quarantine enforced and the reports still clean, publish p=reject with t=y; pct=0 first. Receivers treat that record as quarantine, so nothing changes for mail that already fails, but intermediaries such as mailing lists may start rewriting From, which the reports reveal. When that stage is clean too, remove the testing tags:

Reject is a request, not a command. RFC 9989 tells receivers not to reject on the policy alone and to fall back to quarantine when they have no other evidence. The same document admits that few receivers apply that extra analysis in practice, and that list mail with an unmodified From line is frequently refused. For a forger, that is the protection you came for; for a sender you missed, it is the reason for the stages.

Without an sp tag, the same policy covers every existing subdomain, and without np it also covers names that do not exist in DNS. Usually that is what you want: a forger who invents billing.example.com should be rejected just like one using the main domain. Add sp=quarantine or sp=none only for a subdomain group that is genuinely not ready, and treat it as a temporary exception. A subdomain can also publish its own _dmarc record, which then overrides the inherited policy for that name.

Domains that never send mail, such as old brand names or parked domains, can skip the staging altogether. Nothing legitimate can break, so give them a DMARC record with p=reject, an SPF record that authorizes no one, and, if they receive no mail either, a null MX record:

Forwarding and mailing lists

Some of your mail reaches its reader indirectly. An alumni address relays to a personal inbox, a role address like finance@ at a customer forwards to whoever holds the job, a mailing list redistributes a post to its subscribers. The relaying server connects from its own IP address, so SPF for your return-path fails, while a plain forward usually leaves the DKIM signature intact.

Mailing lists are harder, because many of them change the message: a subject tag, a footer, a rewritten header. That breaks the DKIM signature too. RFC 9989 is blunt here. Domains whose users post to mailing lists should not publish p=reject, and if they do, should first run p=none for at least a month and quarantine for as long again, comparing results. It also notes that mailing list software has widely adopted workarounds that rewrite the From line so posts stay aligned, while mail relayed with the original From line intact is still often rejected.

You may read that ARC solves this. ARC lets each intermediary record the authentication results it saw and seal them, so a later receiver can see that a message passed before the list modified it. Its RFC is experimental, states that ARC is not a trust framework, and leaves it to each receiver whether to believe a given intermediary. RFC 9989 adds that, at its publication, none of these methods had become widely used. Treat ARC as something that may help some of your forwarded mail, not as a reason to skip DKIM.

A rollback plan

Every stage is reversible, and deciding how you will step back before you step forward makes each change much less stressful. If a legitimate sender starts failing after a change, republish the previous stage's record: from quarantine back to p=quarantine; t=y; pct=0, from reject back to its testing record. Keep the rua address in every version. Do not delete the DMARC record to roll back, because that also stops the reports you need to see when the problem is fixed.

A DNS change is not instant. Resolvers that already hold your old record keep using it until its TTL runs out, so a record with a one-day TTL can take up to a day to be replaced everywhere, in either direction. Check the TTL before you change stages. Lowering it a day ahead of a step means a rollback reaches receivers faster, and you can raise it again once the new stage has settled.

Fix the sender while the softer record is live, confirm in the reports that it passes aligned again, and only then repeat the step. What is DMARC? recaps what each policy asks of receivers.

Checklist

1. List every service and server that sends with your domain, and every subdomain that sends.
2. Set up a mailbox or report service that can take aggregate reports.
3. Publish v=DMARC1; p=none with your rua address. Edit an existing record instead of adding a second one.
4. Wait until every mail stream on your list has appeared in the reports at least once.
5. Fix each legitimate sender until it passes with an aligned DKIM signature, and with aligned SPF where the service supports it.
6. Publish p=quarantine; t=y; pct=0 and compare the next reports with the previous ones.
7. Publish p=quarantine and watch for senders that now land in spam.
8. Publish p=reject; t=y; pct=0 and keep reading the reports.
9. Publish p=reject. Leave out sp unless a subdomain group is genuinely not ready.
10. Give domains that never send mail p=reject, v=spf1 -all and, if they take no mail, a null MX.
11. Before each step, check the TTL and know which record you will republish to roll back.

How Patchkit helps

When you add a domain, Patchkit gives you a report address to put in your rua tag and parses every aggregate report that arrives there, grouping sources into authorized, misconfigured, forwarder and unknown senders, and a recognized service links to its setup guide. If an unknown source is yours, you can mark it as yours.

The domain page has a "Path to p=reject" card that follows the five stages above: p=none, quarantine (testing), quarantine, reject (testing), reject. It reads your record from the latest health check, shows the stage you are on, and checks three things against the last 14 days of data:

• Reports: at least 5 aggregate reports arrived in that window, so there is enough data to judge.
• Authorized senders passing: 98% or more of the mail from authorized senders, and from unknown sources you marked as yours, passed DMARC with alignment.
• Mail from misconfigured services: no more than 0.5% of all your mail came from senders marked misconfigured.

Unknown traffic does not count against you, because stopping mail you did not authorize is the point of enforcement. Forwarders you have marked as yours are left out of the calculation, since forwarded mail often arrives unaligned through no fault of yours.

Below the checks, the card shows the exact record for the next stage, built from your current one: the policy and testing tags change, your report addresses and other tags stay, and the retired pct, rf and ri tags are dropped. A record with a legacy value such as pct=25 gets a note explaining what receivers do with it, and its next step is the same policy at full strength. Until all three checks pass, the card says the step is not recommended yet and what to wait for. A subdomain that inherits its policy gets a record to publish at its own _dmarc name, so the main domain's record stays untouched. You publish every change yourself; Patchkit never edits your DNS. After publishing, Check again on the health card asks your name servers for the record first, so you are not looking at a stale cached copy.

The checks are a minimum, not a timer: weigh them against your own inventory. While you work through the stages, alerts tell you when a new unknown source sends a noticeable amount of mail as you, when a service's alignment drops below its usual rate, when reports stop arriving, and when your DMARC or SPF record changes or disappears.

To see where a domain stands today, run the free email domain health check, or build your record with the DMARC record generator; its testing mode, available for quarantine and reject, writes t=y; pct=0 for you. Report monitoring, the roadmap card and alerts need a Patchkit account; the Patchkit plans show how many domains and how much report history each one covers.