DMARC Explained: Policies, Tags, Reports, and Rollout Plan

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS record that tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication. A message passes DMARC when SPF or DKIM passes and the authenticated domain matches the visible From domain. Your policy (none, quarantine, or reject) decides what happens to the rest, and the reports show you who is sending as you.

This guide covers how DMARC evaluates mail, what each tag means, how the reports work, and what changed when DMARC became an IETF standard in 2026.

How DMARC works

SPF and DKIM each authenticate a domain, but neither checks the From address your recipient actually sees. DMARC closes that gap.

When a message arrives, the receiver:

1. Reads the domain in the From header, for example billing@example.com gives example.com.
2. Looks up the DMARC record at _dmarc.example.com.
3. Checks whether SPF passed for a domain that aligns with example.com.
4. Checks whether DKIM passed with a d= domain that aligns with example.com.
5. If either aligned check passes, DMARC passes. If neither does, the receiver applies your policy.

Only one aligned pass is needed. RFC 9989 describes DMARC as relying on SPF “and/or” DKIM. It also adds a caution: domain owners shouldn’t rely on SPF alone for a DMARC pass when their policy is p=reject, because SPF breaks on forwarding. Get DKIM aligned first.

Alignment is where most real-world DMARC failures happen. We cover the strict and relaxed modes in DMARC alignment: strict vs relaxed, and the existing post on why alignment fails while everything passes walks through the confusing cases.

DMARC became a Proposed Standard in 2026

For a decade, DMARC was defined by RFC 7489, an Informational document. In May 2026 the IETF published the updated specification (“DMARCbis”) as three documents:

• RFC 9989: the core protocol, on the Standards Track. It obsoletes RFC 7489 and RFC 9091.
• RFC 9990: aggregate reporting.
• RFC 9991: failure reporting.

What this means for you:

• Existing records still work. The version tag is still v=DMARC1.
• The pct tag is gone. RFC 9989 Appendix A.6 explains that operators found it was rarely applied accurately except at 0 or 100. It’s replaced by a t (testing) tag.
• The rf and ri tags are removed. Receivers should send aggregate reports at least once every 24 hours.
• New tags: np (policy for non-existent subdomains), psd (public suffix domain flag), and t (testing).
• Organizational domain lookup changed. Instead of relying on a Public Suffix List, receivers do a “DNS tree walk” up the domain’s labels to find the right record.

Some mailbox provider documentation still shows pct in examples. Receivers that haven’t updated will keep honoring it for a while, and unknown tags are ignored under the new spec, so leaving pct=100 in place does no harm.

DMARC policies: none, quarantine, reject

Policy	What receivers do with failing mail	When to use it
p=none	Deliver normally; just report	Starting out, discovering senders
p=quarantine	Treat as suspicious, usually spam folder	Once known senders pass
p=reject	Refuse the message during SMTP	Full enforcement

p=none is enough to meet the published bulk sender requirements at Gmail, Yahoo, and Outlook.com. But none doesn’t protect your domain from spoofing. It’s a monitoring mode.

When Gmail rejects mail because of your DMARC policy, the bounce looks like this, per Google’s SMTP error reference:

550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.

DMARC record tags

A complete record might look like this:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r; rua=mailto:dmarc-reports@example.com"

Here’s every tag defined in RFC 9989 section 4.7:

Tag	Values	Default	Purpose
v	DMARC1	required	Version; must be first
p	none, quarantine, reject	none if absent	Policy for the domain
sp	same as p	inherits p	Policy for existing subdomains
np	same as p	inherits sp or p	Policy for subdomains that don’t exist in DNS
adkim	r, s	r	DKIM alignment mode (relaxed/strict)
aspf	r, s	r	SPF alignment mode
rua	mailto: URIs	none	Where aggregate reports go
ruf	mailto: URIs	none	Where failure reports go
fo	0, 1, d, s	0	When to generate failure reports
t	y, n	n	Testing mode; replaces pct=0
psd	y, n, u	u	Marks a public suffix domain (registries only)

A few notes from the field:

• Use np=reject once you’re enforcing. Attackers like to spoof made-up subdomains like secure-login.example.com that have no DNS records at all.
• Leave adkim and aspf at relaxed unless you have a specific reason. Relaxed lets mail.example.com align with example.com.
• ruf reports are sparse. Many large receivers don’t send failure reports because they can contain message content. Don’t build your monitoring around them.
• rua to another domain needs permission. If reports go to reports@example.net, that domain must publish an authorization record (example.com._report._dmarc.example.net). Hosted DMARC services set this up for you.

You can build a record with the DMARC generator and check a live one with the DMARC checker on this site.

DMARC reports: aggregate and failure

Aggregate (rua) reports

Aggregate reports are XML files, usually gzip-compressed and emailed daily, from each receiver that processed your mail. Each one lists:

• Source IP addresses that sent mail claiming your domain
• Message counts per IP
• SPF and DKIM results and the domains they authenticated
• Whether each passed DMARC alignment, and what policy was applied

This is how you find the forgotten sender: the CRM that sends invoices, the help desk tool, the old WordPress plugin. Our existing guide on how to read a DMARC aggregate report walks through the XML line by line.

Failure (ruf) reports

Failure reports are per-message copies or summaries of mail that failed. They’re useful for forensic work but, as noted above, many receivers don’t send them.

A DMARC rollout plan

The goal is p=reject without blocking any of your own legitimate mail. Google’s recommended DMARC rollout says to set up SPF and DKIM at least 48 hours before adding DMARC, then start with monitoring. A practical sequence:

1. Inventory senders. List every system that sends as your domain: workspace mail, marketing platform, CRM, billing, support desk, website forms.
2. Authenticate each one. Set up custom DKIM for each platform using your domain, and a custom bounce (MAIL FROM) domain where the platform supports it. See how to set up SPF, DKIM, and DMARC step by step.
3. Publish p=none with rua. Google suggests about a week of monitoring is usually enough for reports to cover all your mail streams; larger organizations often need longer to catch monthly and quarterly senders.
4. Fix what fails. Every legitimate source in the reports should show an aligned DKIM pass.
5. Move to p=quarantine. Under the old spec you could ramp with pct; under RFC 9989 the clean option is to go straight to quarantine once reports are clean, or test on a subdomain first.
6. Move to p=reject. Add sp=reject and np=reject.
7. Keep reading reports. New tools get added; someone will forget to authenticate one.

The existing post on getting from p=none to p=reject without losing mail covers the hard parts of steps 4 through 6 in detail.

Common DMARC mistakes

• Publishing at the wrong name. The record goes at _dmarc.example.com, not example.com.
• Two DMARC records. Like SPF, a duplicate record breaks evaluation. Keep one.
• Staying at p=none forever. It meets the bulk sender minimum but leaves your domain spoofable.
• Platform signing with its own domain. DKIM passes as d=platform.example.net, but that doesn’t align with example.com. Turn on custom DKIM in the platform.
• Forgetting parked domains. Domains that never send mail should publish v=DMARC1; p=reject; alongside v=spf1 -all.

DMARC protects your domain’s name; list quality protects your sending reputation. If you’re cleaning up authentication before a big send, also run your list through our free email verifier to remove syntax errors, domains without MX records, disposable addresses, and typo domains. It checks what DNS can tell you, without connecting to the mailbox.

FAQ

Is DMARC required?

For bulk senders, yes. Google and Yahoo have required a DMARC record from bulk senders since February 2024, and Microsoft requires one from domains sending more than 5,000 messages a day to Outlook.com, effective May 5, 2025. A p=none policy meets all three minimums.

Does DMARC stop my emails from going to spam?

Not directly. DMARC proves you are who you say you are, which mailbox providers require, but inbox placement still depends on engagement, complaints, and list quality. See why are my emails going to spam.

Do I need to change my DMARC record because of RFC 9989?

No. v=DMARC1 records written for RFC 7489 still work. You can optionally add np= and drop pct, rf, and ri, which the new spec removed.

What’s the difference between p=quarantine and p=reject?

Quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder. Reject asks them to refuse it during the SMTP conversation, so it’s never delivered and the sender gets a bounce.