DMARC quarantine and reject: how to move from p=none without losing real mail

1. What p=none, quarantine and reject ask receivers to do

The p tag in the DMARC record at _dmarc.example.com states what you would like receivers to do with mail whose From domain fails DMARC, meaning that neither SPF nor DKIM passed for a domain aligned with it. It is a request. RFC 9989, the DMARC standard published in May 2026 that replaces RFC 7489, leaves the final decision to each receiver’s local policy.

Two points shape the rollout. First, p=none protects nothing on its own; it produces reports, and only if the record has a rua address. Second, receivers do not all enforce in the same way. RFC 9989 tells them not to reject solely because a policy says reject, and some quarantine such mail instead, so one policy change can look different at different mailbox providers. Plan the move as a sequence of small, reversible steps rather than one switch.

The large mailbox providers already ask bulk senders for a DMARC record but accept p=none. The SPF and DMARC check guide lists their requirements and explains every tag of the record.

2. How to read DMARC aggregate (rua) reports

Aggregate reports are what make a safe move possible. Add a reporting address to the record, for example rua=mailto:dmarc-reports@example.com, and receivers that send reports will mail you a compressed XML file, typically covering one UTC day, listing every IP address that sent mail with your domain in the From line and how that mail fared. The format is defined in RFC 9990. A file name such as receiver.example!example.com!1791590400!1791676800.xml.gz names the reporting receiver, your domain, and the start and end of the period as Unix timestamps.

Each <record> in the file groups messages by source and result. These fields matter most:

The difference between the last row and policy_evaluated is the most useful thing to learn. A newsletter platform can show a DKIM pass in auth_results for mailer.example.net and still fail DMARC, because that domain does not align with example.com. Only policy_evaluated tells you what DMARC concluded.

Read reports over several weeks, not one day: monthly invoices, quarterly newsletters and annual renewal notices arrive on their own schedules. At any volume, raw XML is tedious; a parser or reporting tool that groups rows by source, alignment and disposition per day makes the review practical. Not every receiver sends aggregate reports, so a quiet week does not mean a quiet domain. If the rua address sits at another organizational domain, that domain must publish an authorization record such as example.com._report._dmarc.reports.example.net starting with v=DMARC1, or receivers ignore the address (RFC 9990, section 4).

3. Find every legitimate sender before you enforce

Enforcement is safe only when you know every system that puts your domain in the From line. Build the list from two directions: what the organization uses, and what the reports show. Typical sources:

• The mailbox platform your staff use every day.
• Marketing and newsletters, including an old campaign tool someone still logs into.
• Transactional mail from your application: sign-up confirmations, password resets, receipts.
• Business tools: CRM, invoicing and billing, support desk, HR and recruiting, calendar and e-signature services.
• Website forms and plugins that send as noreply@example.com.
• Devices and scripts: scanners, monitoring alerts, scheduled jobs and on-premises relays.

Then match every source in the reports to an entry on the list. A reverse lookup of the IP address (dig +short -x 192.0.2.10) often names the provider, and the provider’s documentation explains the SPF include and DKIM setup it supports. Keep the result in a table like this one:

The last row is the point of the exercise. Once every known source passes, what still fails is mostly forged or misconfigured mail, and that is exactly what enforcement should stop. Sources that send rarely are the ones most often missed, so ask finance, HR and support which tools they use before you trust a quiet month.

4. SPF and DKIM alignment: relaxed or strict

DMARC passes when SPF or DKIM passes and the domain it passed for is aligned with the From domain. One aligned pass is enough. For SPF the domain checked is the envelope sender (RFC 7208); for DKIM it is the d= value of a valid signature (RFC 6376). The aspf and adkim tags set how close the match must be:

• Relaxed (r, the default): both domains share the same organizational domain, so bounce.example.com and news.example.com align with example.com.
• Strict (s): the domains must be identical.

RFC 9989 determines the organizational domain with a DNS Tree Walk, querying _dmarc records from the full name upward, instead of the public suffix list that RFC 7489 relied on.

RFC 9989 observes that nearly all domain owners find relaxed alignment sufficient. Strict alignment breaks the common pattern of a dedicated bounce subdomain per provider, so keep the default unless you have a specific reason, for example subdomains delegated to vendors, where relaxed alignment would let mail authenticated for vendor.example.com pass for example.com. Whatever you choose, make DKIM the aligned method for every source. SPF breaks when mail is forwarded, because the forwarding server is not in your record; a DKIM signature generally survives forwarding as long as the message is not modified.

5. Staged rollout: pct is gone, use t=y

Older guides stage enforcement with pct: p=quarantine; pct=10, then 25, 50 and 100, so that the policy covers a growing sample of failing mail. Under RFC 7489, mail outside the sample received the next lower policy. RFC 9989 removed the tag; its Appendix A.6 explains that values other than 0 and 100 were usually not applied accurately and that the inaccuracy varied widely between implementations.

The removal has a sharp edge. RFC 9989 tells receivers to ignore tags they do not know, so a receiver that follows the new standard reads p=quarantine; pct=25 as plain p=quarantine and applies it to all failing mail. A partial pct can no longer be relied on to limit the impact.

The replacement is the test flag t. With t=y, receivers are asked to apply one level below the published policy: p=quarantine; t=y is handled like none, and p=reject; t=y like quarantine. Reports continue as usual, and a receiver can record the deviation with the reason policy_test_mode. RFC 9989 describes t=y and t=n as the counterparts of pct=0 and pct=100.

During the transition some receivers still implement only RFC 7489 and ignore t, while newer ones ignore pct. Because pct=0 under the old rules and t=y under the new ones ask for the same handling, you can publish both while testing:

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Watch the reports for a few weeks, then remove both tags so that p=quarantine applies in full. Repeat the pattern before reject: p=reject; t=y; pct=0 asks receivers to quarantine, and removing the two tags turns on reject.

You can also stage by mail stream instead of by percentage. A subdomain such as news.example.com can carry its own DMARC record and move to enforcement earlier or later than the main domain; RFC 9989’s own deployment example tests p=quarantine with t=y on a subdomain before tightening further.

6. Subdomain policy: sp and np

A DMARC record on example.com also covers subdomains that have no _dmarc record of their own. Two tags let the subdomain policy differ from p:

A few rules keep this predictable. sp is meaningful only in the record at the organizational domain; a subdomain that publishes its own record is governed by that record’s p. Setting np=reject while p is still at none is a low-risk early step: forged mail from invented names such as billing-support.example.com is refused, and receivers that do not support np simply fall back to sp or p. Before you rely on it, make sure every subdomain you actually send from has at least one DNS record, so that it counts as existing. And remember that SPF is not inherited: each name used as an envelope sender needs its own SPF record, whatever the DMARC policy says.

7. A realistic timeline from p=none to p=reject

No timeline fits every domain, and RFC 9989 warns that it may take many months of reports before a domain owner is ready to enforce. For domains whose users post to mailing lists, it suggests at least a month at p=none and an equally long period at p=quarantine, comparing the results, and even then it says such domains should not publish reject. An organization with a handful of sending services might plan like this:

Before each change, lower the TTL of the _dmarc TXT record, for example to 300 seconds, at least one old TTL period in advance, so that a rollback reaches resolvers quickly. Change the record early in the week, tell the support team what to watch for, and keep a dated log of every value you publish. RFC 9989 requires any domain that publishes p=reject to sign its mail with valid DKIM signatures rather than rely on SPF alone. Reject is not the only good end state: for a domain your staff use on mailing lists, a well-monitored quarantine can be the better choice, while a domain used only for invoices and notifications is a strong candidate for reject.

8. When legitimate mail fails: diagnose, fix, roll back

Sooner or later a report or a colleague will show legitimate mail failing. Find the matching rows in the aggregate reports, or ask for the full headers of an affected message and read its Authentication-Results header, then compare the pattern:

If the failure is large, or it hits revenue mail such as receipts and password resets, roll back first and investigate second: add t=y and pct=0, or return to the previous policy. With a short TTL the change reaches most resolvers within minutes. A 5xx rejection is permanent, so mail that was already rejected is not delivered later; tell the affected team which messages to send again. Then fix the source, watch it pass in a few days of reports and step forward again. Forwarders and lists that preserve authentication results with ARC (RFC 8617) can help, but RFC 9989 notes that no such mechanism is widely used yet, so DKIM on every source remains the dependable fix.

9. How to check the published DMARC record

Check what is actually published, not what the DNS dashboard shows:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

The first two lines show what resolvers return; the last one queries an authoritative server directly, which shows a change before cached answers expire. Confirm that:

• exactly one TXT record at _dmarc starts with v=DMARC1; when there are two, receivers discard both and the domain behaves as if it had no DMARC record;
• v=DMARC1 is the first tag and p holds none, quarantine or reject;
• the rua mailbox exists and, if it is at another domain, is authorized with a _report._dmarc record;
• tags are separated by semicolons, with no typographic quotes or stray characters pasted from a document.

Then send a message from each sending service to a mailbox you control and read the Authentication-Results header: dmarc=pass together with your From domain is the receiver’s verdict, and it is the one that counts.

For a quick outside view, the free SPF and DMARC record checker reads the _dmarc record on the exact hostname you enter, with no fallback to the parent domain. It flags a missing record (medium, when the host has MX records) and p=none (low, as monitoring mode); quarantine and reject raise no signal. It does not read your reports or evaluate sp, np, t, pct, rua or alignment. The same mail DNS check also reads SPF, MTA-STS and CAA, and it is one of the eight passive checks in the free Launch Readiness Snapshot, which needs no signup and returns a score with a result for each check. For an ongoing review routine, see the DNS and email security guide.