DMARC

DMARC is the policy layer above SPF and DKIM. SPF and DKIM each authenticate one part of a message: which IP sent it, who signed it. DMARC adds three things on top.

1. Alignment. The authenticated identity from SPF or DKIM has to match the From: header domain. Without DMARC, a sender can pass SPF for one domain while displaying a totally different domain in From:.
2. Policy. Tell receivers what to do when authentication fails. None, quarantine, or reject.
3. Reporting. Aggregate reports (rua=) and forensic reports (ruf=) that surface what's authenticating and what isn't, across every receiver that touches your mail.

DMARC is what closes the loop on email authentication. SPF and DKIM provide the signals. DMARC tells receivers how to act on them, and gives senders a way to see what's happening.

A DMARC record is a TXT record at _dmarc.<your-domain>. Typical example:

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

What each tag does:

• v=DMARC1. Version. Always 1.
• p=quarantine. Policy for the organisational domain. Three values: none (monitor only), quarantine (route fails to spam), reject (block fails outright).
• pct=100. What percentage of failing messages to apply the policy to. Useful during ramp-up: p=quarantine; pct=10 applies the policy to 10% of failures.
• sp=quarantine. Policy for subdomains. Without this, subdomains inherit p=. Set it explicitly so you actually control subdomain policy.
• rua=mailto:.... Where to send aggregate reports. Daily XML summaries of authentication outcomes.
• ruf=mailto:.... Forensic report destination. Most receivers stopped sending these years ago for privacy reasons.
• adkim / aspf. Alignment mode. r for relaxed (default), s for strict.
• fo=1. Failure reporting options. Generate reports for any authentication failure.

The three policy values are escalating enforcement levels. Most credible senders should be at p=reject. Getting there safely takes 60-90 days. Here's how the ramp goes.

p=none. The starting point. Receivers don't enforce anything but they do generate aggregate reports back to you. Stay here for the first 30 days while you find every legitimate sender that uses your domain. The reports will surface unauthorised senders, misconfigured legitimate senders, and forwarder edge cases you didn't know existed.

p=quarantine. The middle step. Failing messages go to spam. Move here once your aggregate reports show 99%+ of legitimate mail authenticating cleanly. Stay 30-60 days while you fix remaining edge cases.

p=reject. The destination. Failing messages get rejected at the receiving SMTP server. The strongest posture, and the only one that actually prevents domain spoofing. Quarantine still delivers spoofed messages to the recipient's spam folder where they can still be read by anyone curious.

The pct tag lets you ramp gradually. p=reject; pct=10 rejects 10% of failures and quarantines the rest. Increase pct over weeks. Some large enterprises take six months to get from p=none to p=reject pct=100, and that's fine. The point is to get there.

DMARC requires that at least one of SPF or DKIM aligns with the From: header domain. Two modes:

Relaxed (r), the default. The authenticated domain just needs to share an organisational domain with From:. From: foo@example.com aligns relaxedly with DKIM d=mail.example.com or SPF MAIL FROM: bounce.example.com. Both share example.com.

Strict (s). Authenticated domain must exactly match From:. From: foo@example.com aligns strictly only with d=example.com or MAIL FROM: example.com. Subdomain mismatches fail.

Most senders should stay on relaxed. Strict alignment is for high-security senders (banks, government, identity providers) where any subdomain that does not match exactly should be treated as suspicious by default.

Why this matters: a message can pass SPF technically (the connecting IP is on the authorised list for the MAIL FROM domain) while failing DMARC alignment (because that MAIL FROM doesn't match the From:). DMARC catches the gap that SPF alone misses.

Aggregate reports are XML files sent daily to the rua= address. Each report covers one receiver and one 24-hour period. Inside, you get:

• Every IP that sent mail claiming to be from your domain
• Volume from each IP
• SPF result, DKIM result, DMARC result
• The disposition the receiver applied (none, quarantine, reject)

This is the single most useful operational data source for sender authentication. Without rua= you're guessing about whether your auth works. With rua= you have ground truth from every major receiver.

The reports are XML. They're not human-readable. Do not try to read them by hand; use a parser. dmarcian, OnDMARC, Postmark DMARC Digests, or self-hosted parsedmarc. We configure DMARC report parsing for every customer at provisioning, surfacing the data in their dashboard rather than leaving them to deal with raw XML.

BIMI (Brand Indicators for Message Identification) requires DMARC at p=quarantine or p=reject. It's the visible reason most senders deploy DMARC properly: your verified brand logo shows next to your messages in supported clients. Gmail, Apple Mail, Yahoo.

BIMI is a pipeline:

1. DMARC at p=quarantine or p=reject with pct=100
2. BIMI record published at default._bimi.<domain>
3. SVG logo conforming to the BIMI Profile (constrained SVG subset)
4. Verified Mark Certificate (VMC) from a Mark Verifying Authority: required by Gmail, optional for Apple/Yahoo

Without DMARC at the right level, the rest of BIMI does nothing. DMARC is the gate.

DMARC moved from "best practice" to "regulatory requirement" in several places:

• Gmail and Yahoo bulk-sender requirements (2024). Anyone shipping more than 5,000 messages per day to Gmail or Yahoo accounts must publish DMARC. p=none meets the threshold for now, but the trajectory is clearly toward p=quarantine minimum.
• US federal (BOD 18-01). US federal agencies must publish DMARC at p=reject by mandate.
• UK government (Cabinet Office). All UK government domains require DMARC at p=reject.
• Financial services (PCI-DSS, FFIEC). Not required explicitly but increasingly cited in audits as expected practice.

For commercial senders, "no DMARC" or "DMARC at p=none indefinitely" is no longer defensible. Receivers know it. Regulators know it. Competing senders are using DMARC to differentiate themselves at the inbox.

The bulk-sender enforcement that completed at Gmail in November 2025 and at Microsoft on April 30, 2026 has made DMARC enforcement at p=quarantine or p=reject operationally required for any sender exceeding the 5,000 daily message threshold to personal Gmail and consumer Outlook accounts. The structural pattern is that authentication has moved from a beneficial signal to a binary requirement: pass and your mail is evaluated normally, fail and your mail is rejected at SMTP time without reaching the receiver.

For senders below the bulk threshold, the formal enforcement is less strict but the practical placement penalty for unauthenticated mail is still substantial. Gmail and Microsoft both treat unauthenticated mail with greater suspicion regardless of volume; the binary rejection applies only above the bulk threshold but the placement degradation applies at any volume. Most senders sending to consumer mail in 2026 effectively need DMARC at p=quarantine or higher regardless of whether they hit the bulk threshold.

The DMARC policy transition timeline that has worked across the deployments we have completed: 30 days at p=none for monitoring and identifying unauthorized sending sources, 30-45 days at p=quarantine with pct=25 ramping to pct=100, transition to p=reject once aggregate reports show clean operation. The total ramp typically runs 60-120 days depending on how complex the senders sending landscape turns out to be once aggregate reports surface all the actual sending sources.

For senders complete with DMARC at p=reject, the maintenance overhead is modest: ongoing review of aggregate reports for new unauthorized sending sources, occasional updates when new authorized senders are added (new ESPs, new transactional vendors, new subdomain delegations), authentication setup verification when sending infrastructure changes. The ongoing time investment is typically 1-3 hours monthly for well-maintained deployments.

DMARC requires either SPF or DKIM alignment to pass. The alignment concept is subtle and produces a substantial fraction of the DMARC failures that operators encounter; understanding it precisely prevents most of the common configuration errors.

SPF alignment requires the domain in the SMTP MAIL FROM (return-path) address to match (or be a parent of) the domain in the From header that the recipient sees. The MAIL FROM domain is set by the sending MTA at SMTP transaction time and is independent of what the user sees as the sender. ESPs and transactional vendors typically use their own bounce-handling domain in MAIL FROM by default, which produces SPF authentication but fails DMARC alignment because the bounce domain differs from the From header domain.

The fix for SPF alignment is configuring the sending infrastructure to use a MAIL FROM domain under the senders own domain (typically a subdomain like bounces.example.com). The sender publishes appropriate SPF for that subdomain and ensures the MAIL FROM matches the From header domain at the organizational level. Most reputable ESPs support this configuration; vendors that do not are operating below the deliverability standard required for 2026.

DKIM alignment requires the domain in the DKIM signature (d= tag in the DKIM-Signature header) to match (or be a parent of) the domain in the From header. DKIM alignment survives forwarding while SPF alignment does not, which makes DKIM the more reliable alignment path for senders whose recipients use forwarding.

The fix for DKIM alignment is signing mail with a DKIM key whose d= value matches the From header domain. For senders using third-party ESPs, this requires the ESP to support custom-domain DKIM signing (where the signing identity uses a subdomain of the senders domain rather than the ESP own domain). Standard ESP DKIM where the d= value is the ESP own domain produces DKIM authentication that does not align with the senders From header.

Organizational vs strict alignment is configured through the DMARC adkim and aspf tags. Default is relaxed (organizational), which means alignment is satisfied at the registrable domain level (example.com matches mail.example.com). Strict mode (set through adkim=s or aspf=s) requires exact match at the full hostname level. Most senders should use the default relaxed mode; strict mode is occasionally useful for advanced configurations but typically produces more alignment failures than benefits.

DMARC aggregate reports (rua) arrive daily from most major receivers and provide the visibility that makes DMARC deployment tractable. The reports are XML documents documenting all the mail that receivers observed claiming to be from your domain during the previous reporting window, with authentication results for each sending source.

The processing pattern that works at scale: aggregate reports flow to a dedicated mailbox, automated parsing extracts the structured data from the XML attachments (gzipped XML is the common format), the parsed data flows into a queryable store for trend analysis and per-source breakdown. Multiple commercial dashboard services (DMARC Analyzer, Valimail, Dmarcian, Postmark) handle the parsing and dashboard rendering for senders who prefer managed solutions; multiple open-source tools (ParseDMARC, several language-specific libraries) provide equivalent self-hosted capability.

The data analysis priorities during initial deployment (first 30 days at p=none): identify all the sending sources currently using your domain, classify each as authorized or unauthorized, document the authentication status (passing or failing for each authentication mechanism), establish baseline metrics for the legitimate sources. Most senders discover 30-50% more sending sources than they expected during this period; the dashboard surfaces vendors, applications, and internal systems that the operator did not know were sending under their domain.

The data analysis priorities during enforcement transition (after p=quarantine deployment): monitor for new failure patterns that the policy is now affecting, identify any legitimate sources that authentication issues are now suppressing, address authentication issues for legitimate sources before they cascade into customer-impact problems. The transition window is when most enforcement-related incidents occur; close monitoring during this period catches issues quickly enough to prevent customer-facing damage.

The data analysis priorities during steady-state operation (after p=reject): periodic review for new sending sources appearing, alerting on volume changes that indicate new sources or changing patterns, occasional deep-dive analysis when specific deliverability incidents need investigation. The steady-state overhead is modest compared to the deployment overhead.

Most DMARC deployments encounter one or more of the pitfalls below during the deployment process. The patterns are common enough that experienced operators plan for them rather than being surprised by them.

Pitfall 1: jumping to p=reject before aggregate reports show clean operation. The compressed timeline pressure produces the temptation to move to enforcement before the data supports it. The result is legitimate mail blocked at receivers and customer complaints from recipients who lost mail. The fix is patience: 14-30 days of clean p=quarantine aggregate reports before transitioning to p=reject, with intermediate validation at each pct increase.

Pitfall 2: not authorizing all legitimate sending sources. The 30-day discovery period at p=none reveals more sources than expected; senders who miss this step and transition to enforcement without complete authorization block their own legitimate mail. The fix is comprehensive review during the discovery period including coordination with marketing, sales, support, finance, IT, and any team that might be sending mail under the domain.

Pitfall 3: aggressive subdomain policy without explicit need. The sp= tag controls policy for subdomains. Setting sp=reject at the apex domain affects all subdomains unless overridden. Operators sometimes set this aggressively early in deployment, then discover that subdomains used by specific applications fail authentication. The fix is starting with sp=none or sp=quarantine and tightening only after evidence supports it.

Pitfall 4: forgetting to configure the rua mailbox correctly. Aggregate reports flow to the address in the rua tag. If this mailbox does not exist, has aggressive spam filtering, or routes to a black-hole, the operator never sees the reports and cannot make informed deployment decisions. The fix is testing the rua mailbox before publishing the DMARC record by sending a test message that includes a DMARC report format attachment.

Pitfall 5: not coordinating with third-party vendors. Many transactional and marketing vendors require specific configuration to produce DMARC-aligned sending. Operators deploying DMARC without coordinating with their vendors discover that vendor-sent mail fails authentication, which then either gets blocked (at p=reject) or generates large aggregate-report failure volumes that obscure the patterns operators actually want to see. The fix is coordinated deployment with vendors before tightening DMARC policy.