DMARC Record Examples for p=none, quarantine, and reject
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers how to handle messages that fail aligned SPF and DKIM authentication for a domain. It also gives domain owners a way to learn which systems are sending mail that claims to be from the domain.
The DNS host is always the name _dmarc under the organizational domain. For example, the DMARC record for example.com is published at _dmarc.example.com, not at the root domain.
The three core policies
| Policy | Request to the receiver | When it fits |
|---|---|---|
| p=none | Deliver normally while reporting the result | Discovery and monitoring |
| p=quarantine | Treat failing mail as suspicious, often by placing it in spam | Enforcement with a review step |
| p=reject | Reject failing mail when possible | Every legitimate stream is authenticated and aligned |
Receivers can apply local policy. DMARC does not guarantee inbox placement for passing mail or a specific folder for failing mail.
Example 1: monitoring
Use this as a starting record after SPF and DKIM are configured:
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comReplace the reporting address with a mailbox or DMARC reporting service that you control. Aggregate reports can contain data about sources sending for the domain, so do not route them to an address that cannot process them safely.
Example 2: quarantine
After reports show that legitimate mail is aligned:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.comQuarantine asks receivers to treat failing messages as suspicious. It does not repair a sender that is failing authentication, so keep reviewing reports after the change.
Example 3: reject
Use reject when the sender inventory is complete and the aligned paths have been tested:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comThis is strong protection against unauthenticated use of the domain, but a missing vendor, forgotten subdomain, or misaligned transactional stream can cause legitimate mail to be rejected.
Useful optional fields
| Field | Example | Purpose |
|---|---|---|
| rua | mailto:dmarc-reports@example.com | Aggregate reports |
| sp | quarantine | Policy for subdomains when you need a different default |
| adkim | s | Strict DKIM alignment |
| aspf | s | Strict SPF alignment |
| fo | 1 | Request failure reports when authentication fails |
Start with relaxed alignment unless you have a reason to require exact domain equality. Strict alignment can expose subdomain assumptions that were previously passing.
A note about pct in 2026
Many setup guides still show a pct field for applying quarantine or reject to only a percentage of messages. Google’s recommended DMARC rollout still includes pct examples.
However, RFC 9989, published in May 2026, updates DMARC and removes pct from the updated policy-record specification because implementations did not apply partial percentages consistently. Treat pct as deployment-dependent: use it only when your receivers and reporting tools explicitly support it, and prefer a provider-supported rollout or a separate controlled stream when you need staged enforcement.
Rollout order
- Inventory every service that sends with the domain.
- Configure SPF and DKIM for each service.
- Confirm that at least one of those methods aligns with the visible From domain.
- Publish p=none with aggregate reporting.
- Review representative reports, including low-volume and forgotten senders.
- Fix or remove unknown sources.
- Move to quarantine, then reject, with a rollback plan.
Google recommends setting up SPF and DKIM at least 48 hours before DMARC in its rollout guidance. Use that as an operational minimum, not a promise that every DNS cache will update on schedule.
Validate the record
Query the exact host:
dig +short TXT _dmarc.example.comThen send a real message from each stream and inspect:
- the visible From domain;
- SPF result and envelope-from domain;
- DKIM result, selector, and signing domain;
- DMARC result and applied policy;
- aggregate reports for unexpected sources.
Common mistakes
- Publishing the record at example.com instead of _dmarc.example.com.
- Using a report address that cannot receive or process aggregate reports.
- Moving to reject before finding an old CRM, support tool, or billing sender.
- Assuming a passing DKIM signature is aligned with the From domain.
- Treating DMARC as a spam filter rather than an authentication policy.
- Publishing multiple DMARC records at the same host.
FAQ
Does p=none protect against spoofing?
It gives receivers no enforcement request, but reports can reveal impersonation and missing senders. Use it as the discovery stage, not the final protection goal.
Does quarantine always send mail to spam?
No. It asks the receiver to treat failing mail as suspicious; local policy determines the final handling.
Can I use a personal mailbox for rua?
You can, but aggregate reports may be difficult to parse and can be noisy. A reporting service is usually easier to operate, especially for several domains.
Does DMARC replace SPF and DKIM?
No. DMARC evaluates their aligned results. You still need to configure SPF and DKIM at the sending systems.
See the DMARC TXT record guide for DNS-field details and the quarantine versus reject comparison for the policy decision.