DMARC Records Explained: Policy, Setup & p=reject (2026)

A DMARC record is the DNS entry that ties SPF and DKIM to the address your recipients actually see, tells receiving servers what to do with mail that fails, and asks them to send you reports. It is the keystone of email authentication: SPF and DKIM each prove a domain, but only a DMARC record forces that domain to match your visible From: and lets you set a DMARC policy of none, quarantine or reject. This guide explains the DMARC record syntax, alignment, what p=reject means, a real DMARC record example, the safe rollout sequence, troubleshooting, and best practices.

What is a DMARC record?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Published as a DNS TXT record at _dmarc.yourdomain.com, a DMARC record does three things: it sets a policy for messages that fail authentication, it requires alignment between the authenticated domain and your visible From address, and it requests aggregate reports so you can see who is sending as your domain. The original specification is RFC 7489; in May 2026 the IETF published the updated “DMARCbis” standard (RFC 9989), but deployed records and receivers still follow RFC 7489 syntax, so configure against it today.

Alignment: what makes a DMARC record work

Alignment is the idea at the heart of DMARC. SPF authenticates the envelope sender and DKIM authenticates whatever domain signed the message — but neither has to match the From: your reader sees. A DMARC record passes only when SPF or DKIM passes and the domain it authenticated aligns with your From domain.

• SPF alignment — the Return-Path (envelope) domain matches your From: domain.
• DKIM alignment — the signature’s d= domain matches your From: domain.
• Relaxed (default) matches at the organizational-domain level, so mail.example.com aligns with example.com. Strict requires an exact match.

Only one aligned pass is needed, which is why DKIM — surviving forwarding — is the more resilient of the two.

DMARC record syntax and policy tags

A DMARC record begins with v=DMARC1 and a required DMARC policy tag. The most important tags:

DMARC record example

Here is a DMARC record example partway through a rollout — quarantining half of failing mail while collecting reports:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@example.com; pct=50; adkim=r; aspf=r"

This DMARC record example reads: quarantine failing mail from the main domain, reject it from subdomains, send aggregate reports to dmarc@example.com, apply the policy to 50% of failing messages, and use relaxed alignment. A monitoring-only record would simply be v=DMARC1; p=none; rua=mailto:dmarc@example.com.

The DMARC policy levels and what p=reject means

• p=none — monitor only. Nothing changes for failing mail, but you receive reports. This is where every rollout starts.
• p=quarantine — send failing mail to spam/junk.
• p=reject — refuse failing mail outright. So what does p=reject mean in practice? Receivers bounce any message that fails DMARC for your domain — the strongest protection against spoofing, and the level you should reach once monitoring confirms your legitimate mail aligns.

Managing more than one domain? Save each scan to your free Email Health Workspace to track history and get an email alert the moment DMARC, SPF or DKIM regresses.

How to roll out a DMARC record safely

1. Publish p=none with rua. Start in monitoring mode and collect aggregate reports for one to two weeks.
2. Fix alignment. Use the reports to find every legitimate sender and make sure each aligns via SPF or DKIM.
3. Move to p=quarantine, ramping pct from 25 to 50 to 100 as you confirm nothing legitimate is caught.
4. Move to p=reject for full protection.
5. Set sp= explicitly so subdomains are covered.

Never publish p=reject before monitoring — doing so can block your own mail. The slow ramp is the whole point of a safe DMARC policy rollout. The catch is that most domains never finish the ramp: in our 2026 analysis of 10,000 top domains, 76.6% published a DMARC record but only 54% had reached enforcement, and 29.4% of DMARC adopters were still parked at p=none — protected on paper, spoofable in practice. Don’t be one of them: p=none is a starting line, not a destination.

Troubleshooting a DMARC record

• SPF/DKIM pass but DMARC fails. This is an alignment failure — the authenticated domain does not match your From. Align the Return-Path (SPF) or the d= (DKIM), or use relaxed alignment.
• No reports arriving. You forgot rua, or the mailbox is rejecting the XML reports.
• Legitimate mail blocked. You jumped to enforcement before fixing all senders — drop back to p=none and review reports.
• Forwarded mail failing. Forwarding breaks SPF alignment; robust DKIM alignment is what keeps it passing.
• Multiple DMARC records. Only one _dmarc TXT record is allowed; more than one is ignored.

Reading your DMARC aggregate reports

The reports you receive at your rua address are the reason a careful rollout works. Each one is an XML file, sent daily by a mailbox provider, listing every source that sent mail using your domain that day, the IPs involved, and whether each passed SPF, passed DKIM, and aligned. Raw XML is hard to read by hand, so most people feed it into a DMARC report analyzer that turns it into a dashboard of “who is sending as me.” That visibility is what lets you confidently answer the only question that matters before enforcement: have I found and aligned every legitimate sender? Until the reports show a clean run of aligned mail from all your real services, you stay at a lower policy. People often ask what does p=reject mean for these reports — once you reach reject, the reports also show you exactly how much spoofed mail is now being blocked on your behalf.

Be realistic about the failure-report tag, ruf. In theory it delivers per-message forensic copies of failures; in practice the major mailbox providers rarely send them, for privacy reasons. Treat aggregate rua reporting as your primary source of truth and do not build your process around forensic reports that may never arrive.

Subdomains, BIMI, and the new DMARCbis standard

Spoofers love subdomains, because a domain protected at p=reject often leaves news.example.com or mail.example.com wide open. The sp= tag exists precisely for this: it sets the policy for every subdomain independently of the main domain. Set it explicitly to quarantine or reject rather than relying on defaults, and remember that a subdomain with no DMARC record of its own inherits the organizational domain’s policy through sp=.

Reaching enforcement also unlocks a tangible marketing benefit: BIMI (Brand Indicators for Message Identification) displays your verified logo beside authenticated messages in supporting inboxes — but only if your DMARC policy is at quarantine or reject. In other words, finishing your DMARC rollout is what earns the logo, which is a useful incentive to push past p=none.

Finally, a forward-looking note. In May 2026 the IETF published DMARCbis (RFC 9989 and its companion reporting RFCs), the first time DMARC has been on the Standards Track. It refines several details — most notably replacing the percentage-based pct ramp with a simpler testing flag — but adoption is just beginning, and effectively all deployed records and receivers still follow the long-established RFC 7489 syntax this guide uses. Configure against RFC 7489 today, keep your record valid and monitored, and revisit the newer tags as receiver support matures.

DMARC record best practices

• Always set rua and read the reports — it is the only way to see who sends as your domain before you enforce.
• Reach p=reject eventually; p=none forever offers no protection.
• Set sp= explicitly and keep alignment relaxed unless you control every sender.
• Prioritise DKIM alignment for forwarding resilience.
• Enforcement unlocks BIMI — a logo in the inbox requires a DMARC record at quarantine or reject. Build DMARC on a correct SPF record and DKIM record; see the full sequence in our email authentication hub and the wider deliverability guide.

A common alignment scenario, solved

The single most frequent support question we see is a domain whose mail “passes SPF and DKIM” yet still fails DMARC, and it almost always traces to one setup: sending through a marketing platform that uses its own Return-Path and signs with its own domain. SPF passes for the platform, DKIM passes for the platform, but neither is aligned with your From:, so DMARC fails. The fix is two changes inside the platform. First, set a custom Return-Path (often a CNAME like bounces.yourdomain.com) so the envelope domain aligns for SPF. Second, enable domain-based DKIM signing so the signature uses d=yourdomain.com instead of the platform’s domain. Either change alone is enough for DMARC to pass, because it needs only one aligned mechanism — but configuring both gives you the redundancy that keeps mail authenticated even when one path breaks on forwarding.

Work through your aggregate reports one sender at a time using this pattern, and within a couple of reporting cycles you will have every legitimate source aligned and be ready to tighten your DMARC policy with confidence.

Related reading

• Best DMARC software
• DMARC adoption by TLD
• SPF records guide
• DKIM records guide
• TLS-RPT guide

DMARC record FAQ

What does p=reject mean?

It instructs receiving servers to refuse any message that fails DMARC for your domain — the strongest anti-spoofing setting. Only deploy p=reject after a monitoring period with p=none confirms all your legitimate mail aligns, or you risk blocking real messages.

Do I need a DMARC record in 2026?

Yes. Google, Yahoo and Microsoft require bulk senders to publish a DMARC record at a minimum policy of p=none, with SPF and DKIM aligned. It is also the only standard that stops criminals from spoofing your exact domain in phishing attacks.

What is the difference between DMARC quarantine and reject?

A DMARC policy of quarantine tells receivers to deliver failing mail to the spam folder, while reject tells them to refuse it entirely. Quarantine is a useful intermediate step during rollout; reject is the end state for full protection.

Why does my DMARC record fail when SPF and DKIM pass?

Because of alignment. DMARC requires the SPF- or DKIM-authenticated domain to match your visible From: domain. If a provider authenticates with its own domain, the check passes for them but is not aligned with you, so DMARC fails. Align the Return-Path or DKIM d=, or relax alignment.

What is the rua tag in a DMARC record?

The rua tag sets the address that receives daily aggregate reports — XML summaries showing every source sending as your domain and whether it passes and aligns. It is the single most valuable tag because it lets you find legitimate senders before tightening your DMARC policy.

Can I have more than one DMARC record?

No. A domain may publish only one _dmarc TXT record. If two exist, receivers ignore your DMARC policy entirely, so consolidate everything into a single record. If you need different handling for a subdomain, do not create a competing record — use the sp= tag on your main record, or publish one dedicated DMARC record on the subdomain itself.