DMARC Record Explained: Policy, Reports and Roll-Out Roadmap (2026)

What is a DMARC record?

A DMARC record is a single DNS TXT entry at _dmarc.yourdomain.com that does three things. First, it tells receiving mail servers what to do when a message claiming to be from your domain fails authentication: nothing, mark as suspicious, or reject. Second, it requires alignment between the authenticated domain (from SPF or DKIM) and the visible From header. Third, it asks receivers to send you regular reports listing every source sending mail in your domain’s name.

DMARC is the layer that turns SPF and DKIM from passive signals into an enforceable policy. Without DMARC, an attacker can spoof your From header and the receiver has no instruction on what to do about it. With DMARC at p=reject, the receiver simply refuses unauthenticated mail before it reaches a single inbox.

How DMARC works, step by step

When a message arrives at a receiving mail server, DMARC processing runs after SPF and DKIM:

1. The receiver extracts the From header domain, for example news@example.com gives example.com.
2. SPF and DKIM are checked. SPF authenticates the envelope sender; DKIM authenticates the signing domain in the message header.
3. The receiver looks up the DMARC record at _dmarc.example.com.
4. Alignment is evaluated. For DMARC to pass, at least one of SPF or DKIM must pass AND its authenticated domain must align with the From header domain.
5. If neither aligns, the receiver applies your policy: none (deliver normally and report), quarantine (route to spam), or reject (refuse delivery).
6. The receiver records the outcome and bundles it into a daily aggregate report sent to the address in your rua= tag.

DMARC record syntax

A DMARC record is a single TXT string starting with v=DMARC1, followed by a policy and optional parameters:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; aspf=r; adkim=r; pct=100; sp=quarantine

DMARC tag reference

The three DMARC policies

Policy choice is the single most consequential decision in DMARC. Treat it as a roadmap, not a setting.

p=none (monitoring)

Receivers take no enforcement action; they just report. Use this as the starting policy. You learn which IPs and services send mail in your domain’s name (including ones you forgot about), and which would fail authentication, without risking deliverability.

p=quarantine (mark as suspicious)

Failing mail goes to spam. Use this once your reports show that all legitimate sources authenticate correctly and you want to start enforcing without hard-blocking.

p=reject (block)

Failing mail is refused at SMTP time. The strongest possible protection against domain impersonation. Use this as the final destination of your DMARC journey, typically 60 to 90 days after starting at p=none. For the detailed staging plan and what to watch in aggregate reports at each step, see our DMARC reject vs quarantine roadmap.

Real-world DMARC examples

Day-1 monitoring policy

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

Reports flow in, no enforcement yet. The minimum policy that satisfies Gmail and Yahoo 2024 bulk sender requirements.

Intermediate quarantine policy

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; aspf=r; adkim=r

Twenty-five percent of failing mail is sent to spam. Gradually raise pct to 100 as you gain confidence.

Strict enforcement policy

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; aspf=s; adkim=s; pct=100; fo=1

The destination policy. Failing mail is rejected outright on both apex and subdomains, with strict alignment for both SPF and DKIM. Maximum impersonation protection.

Outsourced reporting

v=DMARC1; p=none; rua=mailto:reports@yourdmarcprocessor.com!10m

The !10m suffix limits report file size to 10 megabytes. Required by third-party DMARC processors (Postmark, dmarcian, EasyDMARC, Valimail) and many ESPs.

DMARC alignment, in plain English

Alignment is what separates DMARC from plain SPF and DKIM. A message can pass SPF or DKIM but still fail DMARC if the authenticated domain does not match the From header.

Two modes exist:

• Relaxed (default). Parent domain and subdomains match. If the From header is news@marketing.example.com and DKIM signs with d=example.com, alignment passes.
• Strict. Domains must be identical. The same example would fail strict alignment.

Relaxed is the right choice for most senders. Strict is useful when you operate completely separate brands on subdomains.

Reading DMARC aggregate reports

Aggregate (RUA) reports are XML files sent daily by each major receiver (Google, Microsoft, Yahoo, Mail.ru). They list, for every source IP that sent mail in your name during the day:

• The IP address and how many messages it sent.
• Whether SPF passed and aligned.
• Whether DKIM passed and aligned.
• What the receiver did (none, quarantine, reject).

Reading raw XML is unpleasant. Most senders route their RUA address to a processor (Postmark DMARC, dmarcian, EasyDMARC, Valimail, OnDMARC) that parses, deduplicates, and visualises the data. Use one. Even free tiers are sufficient for most domains under 100,000 messages per day.

Forensic (RUF) reports contain redacted copies of individual failing messages. They are rare in practice because most large receivers (Gmail above all) do not send them for privacy reasons. Do not depend on RUF for diagnosis; the RUA aggregate view is what matters.

The 90-day DMARC roll-out roadmap

A sensible journey from zero to p=reject:

1. Week 1: Confirm SPF and DKIM are deployed for every sending source. Publish v=DMARC1; p=none; rua=mailto:reports@example.com. Sign up for a free DMARC processor.
2. Weeks 2 to 4: Read your reports. Identify every legitimate source that is failing authentication or not aligning. Fix them.
3. Week 5: Move to p=quarantine; pct=10. Ten percent of failing mail goes to spam.
4. Weeks 6 to 8: Raise pct to 25, then 50, then 100 if reports stay clean.
5. Week 9: Switch to p=reject; pct=100. Optionally tighten alignment to aspf=s; adkim=s.
6. Ongoing: Watch reports weekly. New ESP onboarded? Validate it under p=quarantine first before letting it sign under your domain.

Common DMARC mistakes

1. Jumping straight to p=reject. Without first running p=none and reading the reports, you will block legitimate mail (forgotten internal mailers, vendor notifications, transactional services) and never know it.
2. No rua= address set. Without reports, you are flying blind. Even at p=none, you cannot diagnose what is happening without aggregate reports.
3. Using an inbox you do not check for RUA. Raw XML reports arrive daily. If they pile up unread, they are worthless. Route them to a processor, not a human mailbox.
4. Missing sp= on a domain with subdomains. If you publish p=reject only on the apex but send marketing from news.example.com, the subdomain inherits the apex policy unless sp= says otherwise. Set sp= explicitly.
5. Using pct<100 at p=reject. The pct tag is for gradual rollout during p=quarantine. At p=reject with pct=50, half the failing mail is still delivered, undermining the policy. Once at reject, always use pct=100.
6. Two DMARC records on the same domain. Like SPF, multiple TXT records starting with v=DMARC1 at _dmarc.example.com cause a permerror.
7. Strict alignment without need. Setting aspf=s; adkim=s when your ESP signs with a subdomain breaks alignment and creates DMARC failures for legitimate mail.
8. Forgetting third-party senders. Salesforce, HubSpot, Mailchimp, your ATS, your billing platform: each one sends mail as your domain. All must authenticate and align before you tighten DMARC.
9. Treating DMARC as set-and-forget. Reports keep arriving. New sources keep appearing. Audit your DMARC posture monthly at minimum.
10. Ignoring BIMI prerequisites. If you want your brand logo in Gmail and Apple Mail (via BIMI), DMARC must be enforced at p=quarantine or p=reject. Going to BIMI without enforced DMARC is impossible.

How to test your DMARC record

1. Use the free SMTPedia DMARC Checker at smtpedia.com/free-dmarc-record-checker. It validates syntax, confirms the record location, and parses every tag.
2. Send a test email to a Gmail or Outlook account. View full headers and look for dmarc=pass in the Authentication-Results line.
3. Query DNS directly:

   dig TXT _dmarc.example.com +short

   You should see one record starting with v=DMARC1.
4. Wait 24 to 48 hours after publishing, then check that aggregate reports start arriving at your rua= address.

DMARC FAQ

Final words

DMARC is where email authentication graduates from a checkbox to a strategy. SPF says who can send. DKIM says the message is intact. DMARC says what happens when either fails, and gives you visibility into every source claiming your domain.

Three habits keep DMARC effective: read your reports, advance the policy on a calendar (not when you remember), and review your sending sources monthly. The reward is durable: a domain that cannot be impersonated, deliverability that holds up under Gmail and Yahoo’s tightest filters, and a clean path to BIMI brand logos in the inbox.

To dig deeper into how all three records work together, read our Email Delivery Infrastructure guide.