None, quarantine, or reject? Choosing the right DMARC policy

none, quarantine, and reject tell receivers how to handle failures

Start by separating the authentication result from the policy. A message passes DMARC when SPF or DKIM passes and the domain authenticated by that method aligns with the domain in the visible From address. Changing p= does not change that test. It changes the handling you request for messages that fail it.

Authentication still works with none. A receiver may also block a message for malware, spam, or another reason. Likewise, quarantine is not a promise that a message will wait somewhere easy to recover. An invoice or sign-in message that a customer never notices in spam has effectively failed to reach them. Microsoft distinguishes DMARC handling from its other filtering decisions. How Microsoft handles DMARC failures ↗

For an initial rollout, none gives you room to investigate. Leaving it there indefinitely, however, means you never ask receivers to quarantine or reject unauthorized use of your domain. Set out the business processes to observe, the failures to resolve, and a date to review the evidence. Reaching that date is a reason to review the policy, not an automatic reason to tighten it.

A 99% pass rate can hide 100 failed invoices

In this example, Gaon reserves example.com for controlled customer notifications and billing; staff use a separate domain for everyday correspondence. During one reporting period, it sends 9,900 routine notifications and 100 month-end invoices. All the notifications pass DMARC. Every invoice, sent by an external accounting service, fails. These are fictional figures. In a real deployment, a dedicated transactional subdomain can provide this separation.

The team puts the policy change on hold. The failed 1% matters. Finance identifies the billing service and its owner, then IT compares the sending times and counts in that service's logs with the RUA aggregate reports. An IP address alone is not enough to identify an authorized service; the team needs evidence that this is the account Gaon actually uses.

The invoice was authenticated for the service, not the company

A test invoice received in an external mailbox reveals the problem. SPF and DKIM both pass for the accounting service's domain. The customer sees Gaon's address, but neither authentication result connects to it.

From: billing@example.com

[Before]
SPF:  pass · MAIL FROM=bounce@mailer.example.net
DKIM: pass · d=mailer.example.net
DMARC: fail · no passing method aligns with example.com

[After enabling company-domain DKIM]
SPF:  pass · MAIL FROM=bounce@mailer.example.net
DKIM: pass · d=example.com
DMARC: pass · DKIM passes and aligns

IT checks the accounting service's domain authentication feature, publishes the DKIM records issued for Gaon, and enables signing in the service. Finance then sends another test through the same process used for month-end invoices. This time DKIM passes for the company domain, so DMARC passes too. The different SPF domain does not invalidate that result. Google on DMARC authentication and alignment ↗

The completion record needs more than “DNS saved.” Record which service sent the message, the From address, the receiving service, and the receiver's authentication results. Test destinations used by customers, including Gmail and Microsoft 365 where relevant. Check the subject, attachments, and reply address as well. Finance should confirm that the test represents the real invoice process.

Decide from verified sending routes, not elapsed days

Fixing invoices does not finish the inventory. Password resets, support notifications, CRM messages, and quarterly notices may use the same domain. Low-volume or infrequent senders are easy to miss. Work through them with the people who run those processes.

Gaon has checked daily notifications and monthly invoices, but its quarterly notice has not appeared in reports yet. It can run an approved test through the real sending function instead of waiting three months. The owner should check whether the scheduled job, SMTP server, or any other part of the production route differs from the test. Anything that cannot be reproduced remains unverified.

Aggregate reports do not show every delivery outcome

RUA reports cover the messages observed by receivers that provide reports. They arrive after the fact, and some services do not send them. “No reported failures” therefore does not establish that every legitimate message arrived. Ordinary aggregate reports also cannot tell you whether a message reached the inbox or spam folder. What DMARC aggregate reports cover ↗

Use reports alongside external delivery tests, bounce logs, and support tickets. For a bounce, keep the error code and explanation, sending time, and sending service so you can establish whether DMARC caused it. Give support a specific request: record the sending time and recipient domain for missing invoice or sign-in messages. That produces evidence someone can investigate.

A zero failure rate is not the goal, either. An unrelated server trying to impersonate the company should fail. Identify an unfamiliar source before authorizing it; adding every reported IP address to SPF would defeat the purpose of the review.

Check subdomains and forwarded mail separately

Suppose Gaon sends newsletters from news.example.com. A change at the organizational domain can affect those messages too. The following example assumes example.com is the organizational domain and its record contains p=reject; sp=quarantine.

A valid record at the sending domain takes precedence. For inherited policy, sp applies to existing subdomains; without it, p applies. The np tag covers subdomains that do not exist in DNS. Without np, the fallback is sp, then p. A domain does not become nonexistent simply because it has no MX record or sends no mail. DMARC policy tags and inheritance ↗

This allows verified domains to move ahead separately. But renaming a service “newsletter” does not separate its policy. The actual From address must use news.example.com, authentication must align with that address, and the applied policy must be checked. Agree on any customer-visible address or reply changes with the business owner. Give a temporary subdomain p=none exception an owner and review date.

Forwarding can change a message's authentication result

After automatic forwarding, the final receiver sees the forwarder's IP, which can cause SPF to fail. DMARC can still pass if an aligned DKIM signature survives. A mailing list that changes a signed subject or message body may break DKIM as well. Test forwarding and mailing-list routes that your business uses separately from direct delivery. Forwarding, mailing lists, and DMARC ↗

ARC can convey an intermediary's authentication observations to the final receiver. It does not automatically turn a DMARC failure into a pass. The receiver decides how much to trust the chain and the intermediary. A product's claim to support ARC does not replace testing an important forwarding route. ARC and receiver decisions ↗

Make one change at a time, with a rollback plan already written

Gaon fixes its invoices, retests important processes, checks scheduled and forwarded mail, and assigns someone to respond to problems. For the controlled notification domain in this fictional example, it decides to move from none to reject. Valid, aligned DKIM is enabled on its sending routes: the standard says a reject domain must not rely only on SPF. This decision does not extend to the separate domain used for ordinary staff correspondence. DKIM and policy interoperability requirements ↗

Save the current record and TTL first. TTL tells DNS resolvers how long they may cache an answer. If needed, lower it within your DNS provider's limits in advance, allow the previous TTL to expire, and check what is publicly returned. Schedule the change when the responsible people are available and a major invoice run is not about to start.

Name: _dmarc.example.com
Type: TXT

Before
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

After
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

The domain and reporting address are examples. Preserve your real reporting destinations and other settings, and avoid creating a second DMARC record at the same name. Changing the policy, alignment mode, sending service, and DKIM key together makes a subsequent failure much harder to diagnose. This change alters only p.

1. Check the published DNS answer

   Query public DNS for the new policy and check that there is only one DMARC record. Record the time; some resolvers may still have the previous answer cached.

2. Repeat the same business tests

   Send the notifications, invoices, and support notifications checked during preparation. Inspect receiver authentication, delivery, and bounces. Success at one destination does not prove success everywhere.

3. Compare reports with business symptoms

   Separate reporting periods before and after the change. Compare failures by sending route with bounces and support tickets, then check the next scheduled run as well.

Write down what would justify a rollback

“The failure rate went up” is too broad: an increase in spoofing could trigger that rule. Gaon's condition is confirmed DMARC rejection of authorized, important business mail after the change, when the sending configuration cannot be corrected promptly. Bounce details, sending logs, and an external test help establish the cause. If customer impact is severe before diagnosis is complete, the designated owner follows the documented emergency decision process.

If a rollback is necessary, restore the saved value and repeat the DNS checks and delivery tests. DNS caches mean the reversal is not immediate everywhere. It also does not redeliver mail already rejected. Review failed messages and decide what to resend, taking care to avoid duplicate invoices or notifications.

Scope: _dmarc TXT for example.com
Change: p=none → p=reject; all other tags unchanged
Basis: notification, invoice, and support tests; scheduled senders checked
Evidence: test times, sending services, recipients, stored original headers
Owners: IT changes DNS; Finance checks invoice receipt
Monitoring: delivery retests, bounces, support tickets, post-change RUA periods
Rollback: confirmed DMARC rejection of critical legitimate mail without a prompt fix
Restore value: complete previous TXT value stored separately
Follow-up: check the next month-end run and recheck new sending services

Check receiver support before relying on pct or test mode

Older guides may recommend pct=10 to apply enforcement to a percentage of messages. RFC 9989, published in 2026, removed pct, the reporting interval tag ri, and the failure-report format tag rf. IANA now marks all three as historic. IANA's DMARC tag registry ↗

Google and Microsoft documentation checked in September 2026 still includes pct examples. Publication of a standard and deployment across receiving services are separate events. Do not treat pct=10 as a guarantee that exactly 10% of failing mail will be affected. Check the relevant provider's guidance and actual receiver behavior. Google rollout examples ↗ · Microsoft rollout examples ↗

The new t=y tag requests test mode. Under the standard, p=reject; t=y requests quarantine-level handling of failures, which differs from none. A receiver that does not understand t may ignore it and still see p=reject. Check support before copying a “test” record into a production domain. What DMARC test mode means ↗

Pick one unverified process from your sender inventory and send a real test through it. Record which domain authenticated the message and who can fix it if it fails. That evidence will tell you more about readiness than another day spent watching the overall percentage.