DMARC Explained: Policies, Alignment and a Safe Rollout Plan

SPF and DKIM can both pass on a message that is completely forged. A scammer can send from their own domain with valid SPF and DKIM while showing your domain in the From: line. DMARC is the check that connects authentication to the address your customers actually see, and tells receivers what to do when they don't match. This guide covers how DMARC decides pass or fail, what each policy does, what changed with the new DMARC standard in 2026, and a rollout plan that gets you to enforcement without blocking your own invoices.

AI Automation for Accounting Firms, Explained Step by Step · 3:03 Subscribe

What DMARC checks

DMARC (Domain-based Message Authentication, Reporting and Conformance) looks at the domain in the visible From: header and asks:

Did this message pass SPF or DKIM for a domain that aligns with the From: domain?

If either one does, DMARC passes. If neither does, DMARC fails, and the receiver consults your published policy.

Two things trip people up:

1. Only one of SPF or DKIM needs to pass and align. You don't need both.
2. Passing isn't enough. The domain has to align. SPF passing for bounces.esp-example.net doesn't help a message from hello@example.com.

Alignment, relaxed vs strict

You set this with adkim= and aspf= (r or s). Relaxed is the default for both and is right for almost every business. Strict alignment breaks common setups where a service signs with your root domain but sends from a subdomain, or the reverse.

For SPF alignment, the domain compared is the envelope sender (Return-Path). For DKIM, it's the d= value in the signature. Since DKIM survives forwarding and SPF usually doesn't, aim to have every legitimate service pass DKIM with your domain. Treat aligned SPF as a bonus. Our guides to SPF and DKIM cover the setup for each.

The DMARC record

DMARC is a TXT record at _dmarc. plus your domain:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Tags you'll actually use

The three policies

• p=none: monitoring only. Receivers deliver failing mail as they normally would, but they send you reports. Gmail, Yahoo and Outlook.com accept p=none as meeting their bulk-sender DMARC requirement.
• p=quarantine: failing mail should be treated as suspicious, usually delivered to spam or junk.
• p=reject: failing mail should be refused during the SMTP conversation. This is the policy that actually stops spoofing.

Receivers make the final decision. Your policy is a request, and receivers can apply local exceptions, for example for mail from known mailing lists or forwarders. Your aggregate reports show the action each receiver actually took.

What changed in 2026: RFC 9989

In May 2026 the IETF published DMARC as a standards-track specification, RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. They obsolete the original RFC 7489. Your existing record keeps working (v=DMARC1 is unchanged), but a few details are different:

• pct is gone. The old "apply the policy to X% of mail" tag was removed because in practice it was only reliably used as 0 or 100. It's replaced by t=y (test mode). With t=y, a receiver applies one step softer: p=reject is treated as quarantine, and p=quarantine as none.
• np was added to set a policy for non-existent subdomains, which spoofers like to invent (billing-secure.example.com).
• ri and rf were removed. Reports are expected daily.
• The organizational domain is found by a DNS "tree walk" instead of relying on the Public Suffix List.

Old records that still carry pct=100 are harmless. If your record has a partial value like pct=25, plan to replace it with t=y or remove it. Requirements written before the change still mention pct. Gmail's BIMI requirements, for example, ask for pct=100, which you meet by setting pct=100 or simply leaving pct out.

A safe rollout plan

The goal is p=reject without blocking legitimate mail. RFC 9989 is frank that getting there can take many months of reading reports, and that problems must be fixed before you enforce.

Phase 1: publish p=none and collect reports

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Use a dedicated mailbox or a DMARC reporting service. Reports are XML attachments, and even a small domain receives several a day. If the rua address is on a different domain, that domain must publish an authorization record, or receivers will ignore it:

example.com._report._dmarc.reports-vendor.net.  TXT  "v=DMARC1"

Reporting services set this up for you.

Phase 2: find and fix every legitimate sender

Use the reports to list every source sending as your domain. For each one:

• Your mailbox provider (Google Workspace, Microsoft 365): turn on DKIM signing for your domain.
• Marketing, CRM, help desk, billing tools: complete their domain authentication so they sign with DKIM as your domain. Set a custom return path if they offer one.
• Website and app mail: send through an authenticated service rather than the web server's local mail function.
• Unknown sources: if they fail and you don't recognize them, that's usually spoofing, which is exactly what you want to block.

Our guide to reading DMARC reports shows how to spot each case.

Phase 3: quarantine

Once your reports show legitimate sources passing consistently, move to quarantine. If you want a softer step first, use test mode, which receivers that implement RFC 9989 treat as none:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"

Then drop t=y:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Watch reports and complaints for a few weeks. Ask staff to tell you about anything that went missing.

Phase 4: reject

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Keep reading reports afterwards. New tools get added, and the first sign of a misconfigured one is often a spike of DMARC failures.

Subdomains and parked domains

• By default, subdomains inherit p. Use sp= only if a subdomain stream needs a different policy during rollout.
• Add np=reject once you're at enforcement to cover made-up subdomains.
• Domains that never send email should go straight to p=reject, together with v=spf1 -all.

Common DMARC mistakes

• Publishing at the wrong name. The record goes on _dmarc.example.com, not on example.com.
• Two DMARC records. Like SPF, multiple records mean receivers treat the domain as having no valid policy.
• No rua. You get no data, so you can never safely move past p=none.
• Staying at p=none forever. Monitoring doesn't block spoofing. It's a phase, not a destination.
• Jumping straight to p=reject without checking reports, then discovering the invoicing system wasn't signing.
• Assuming forwarding will be fine. Forwarded mail usually loses SPF. That's why DKIM on every stream matters before enforcement.

A free audit checks whether your DMARC record exists, parses its policy and tags, and puts any problems in a prioritized fix list next to your SPF and DKIM results.

Frequently asked questions

Does DMARC p=none do anything?

It doesn't change delivery, but it isn't useless. It satisfies the Gmail, Yahoo and Outlook.com requirement for bulk senders to publish DMARC, and with rua set it gives you the reports you need to move to enforcement.

Do both SPF and DKIM have to pass for DMARC to pass?

No. DMARC passes if either SPF or DKIM passes for a domain that aligns with the From: domain. Note that Outlook.com's high-volume sender rules separately require both SPF and DKIM to pass.

How long should I stay at p=none?

Until your reports show every legitimate source passing with aligned DKIM or SPF. For a small business with a few tools, that might be a few weeks. For organizations with many senders, RFC 9989 notes it can take many months.

Should I still use pct?

Not for new records. RFC 9989 removed pct and introduced t=y for testing. Leaving an existing pct=100 in place does no harm, and some older requirement documents still mention it.

What to do next

If you have no DMARC record, publish p=none with a reporting address today. It takes five minutes and starts the clock. If you've been at p=none for months, open your reports, fix the remaining failures and set a date to move to quarantine. For the bigger picture, see the email authentication checklist.

Related reading

• Automate DMARC Report Monitoring: Free Tools and Alert Rules: Automate DMARC aggregate report monitoring with free tools like parsedmarc, Postmark's digest or Cloudflare, set useful alerts and move from p=none to reject.

Sources

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990: DMARC Aggregate Reporting
• RFC 7489: DMARC (original, now obsoleted)
• Google: Email sender guidelines
• Microsoft: Outlook.com postmaster policies, practices and guidelines