DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a DNS-based policy that tells receiving mail servers what to do when SPF or DKIM checks fail for messages claiming to be from your domain: do nothing (p=none), quarantine (p=quarantine), or reject (p=reject). DMARC records also specify where to send aggregated reports (rua=) and forensic reports (ruf=) so domain owners see who's sending mail on their behalf. Best practice: start at p=none for monitoring, fix any legitimate senders that fail, then escalate to p=quarantine and eventually p=reject. Major providers (Gmail, Yahoo) now require DMARC for bulk senders.

Why DMARC needs both SPF and DKIM underneath it

DMARC itself doesn't authenticate anything — it's a policy layer that reacts to the results of SPF and DKIM, plus one additional requirement neither of those checks on its own: alignment. SPF can pass while checking the envelope-from domain, and DKIM can pass while checking the domain in its signature — but DMARC additionally requires that whichever of those passes also matches (or is a subdomain of) the domain shown in the visible "From:" header the recipient actually sees. This closes a gap attackers exploited for years: sending mail that technically passed SPF for an unrelated domain in the invisible envelope-from, while showing a spoofed, trusted-looking domain in the visible From header that the recipient's inbox displayed.

Worked example

A company sends transactional email through three systems: its primary Exchange Online tenant, a marketing platform, and a support ticketing tool — and only the first two have SPF and DKIM configured correctly. The company publishes a DMARC record at p=none with a rua= reporting address. Within a couple of weeks, the aggregate reports (delivered as XML, most practically read through a DMARC report-parsing service) show that the marketing platform passes cleanly, but the support tool's messages are failing both SPF and DKIM alignment — meaning they'd be quarantined or rejected the moment the policy tightened. The company configures DKIM signing and adds the tool's sending IP range to the SPF record, waits for a clean reporting period showing no more legitimate failures, then moves the policy to p=quarantine and finally p=reject — at which point any mail spoofing the domain that doesn't pass through one of the three known-good systems is rejected outright by receiving mail servers, rather than merely flagged.

Percentage rollout and subdomain policy

DMARC supports a pct= tag to apply the enforcement policy to only a percentage of failing messages at first — a cautious way to escalate from quarantine to reject without an all-or-nothing jump, useful for a domain sending high volumes where even a small residual misconfiguration would otherwise affect many messages at once. A separate sp= tag sets the policy specifically for subdomains, which matters because a company with many subdomains (marketing.contoso.com, mail.contoso.com) can have a strict policy on the root domain while phasing in subdomains independently, or vice versa.

Common pitfalls

The most common mistake is jumping straight to p=reject without ever reviewing aggregate reports, which reliably breaks some legitimate sending system nobody remembered still existed (an old CRM integration, a scanner's scan-to-email feature, an event platform's confirmation emails) — DMARC failures are silent to the sender by default; the sending system gets no bounce, it just finds its mail rejected or quarantined at the recipient's end with no obvious error on its own side. The second is setting up DMARC reporting and then never actually reading the reports, which defeats the entire point of the p=none monitoring phase.