DMARC explained: what it is, why it exists, and how it works

Email has a spoofing problem. The protocol that delivers mail (SMTP) was designed in 1982, and it has no built-in way to verify that a message actually came from the domain in the From: header. Anyone can send an email that appears to come from ceo@yourcompany.com, and without authentication, the receiving server has no reliable means of telling a genuine message from a forged one. DMARC (Domain-based Message Authentication, Reporting, and Conformance) exists to fix this. It gives domain owners a mechanism to declare how their domain sends mail and what receivers should do when a message fails the authentication process.

The problem DMARC solves

Before DMARC, two authentication standards already existed: SPF and DKIM. Both function, but both contain a critical gap. SPF (Sender Policy Framework) is a record in DNS that lists which IP addresses are allowed to send mail for a domain; the receiving server compares the envelope sender (the MAIL FROM in the SMTP conversation) to this list. DKIM (DomainKeys Identified Mail) is a cryptographic signature added to a message header: the sending server signs the message with a private key, and the receiving server verifies it using a public key published in DNS.

Here is the gap: neither SPF nor DKIM is tied to the From: header, which is the address that appears on the recipient's screen. SPF validates the envelope sender, which is often a different domain entirely (like an ESP's bounce domain). DKIM validates the domain that signed the message, which could also be a third party. This means a message can pass both SPF and DKIM while the From: header claims to be from a completely unrelated domain. The recipient sees ceo@yourcompany.com, but the authentication process only validated bounces.someesp.com. Everything passes through, yet the message is spoofed.

DMARC closes this gap with a concept called alignment: the authenticated domain must match the From: header domain. SPF and DKIM are ID checks; alignment is the step that confirms the person showing the ID is the same person named on the meeting invitation. Without that step, the ID check means nothing to the recipient.

How a receiving server evaluates DMARC

The parts of DMARC

The standard has four working parts, each covered in its own entry. The record and its tags define what you publish in DNS. The three policies (none, quarantine, reject) define what receivers do with failing mail. Aggregate reports provide visibility into every source that sends mail using the domain. And a safe rollout process connects them, moving from monitoring to enforcement without breaking legitimate mail. DMARC also has known limitations, forwarding chief among them, that shape how it should be deployed.

This record does two things: it tells receivers a DMARC policy exists (even though none takes no action), and it tells them where to send aggregate reports so the domain owner can see who is sending mail as that domain.

DMARC as a compliance requirement

Since February 2024, Google and Yahoo require DMARC for domains sending more than 5,000 messages per day to their users, alongside valid SPF within the 10-lookup limit, DKIM signing (2048-bit keys recommended), From: alignment with at least one mechanism, one-click unsubscribe on promotional mail, and spam complaint rates below 0.3%. Microsoft adopted equivalent requirements for Outlook consumer domains in 2025. Meeting p=none satisfies the letter of these rules, but it provides zero spoofing protection; it only enables reporting. The goal should always be p=reject. That is where DMARC actually defends a domain.

The standard itself matured in parallel: DMARCbis, finalized at the IETF in 2025, replaced the original informational RFC 7489 with a Standards Track specification. Existing records remain valid, and the changes (a DNS tree walk for policy discovery, the retirement of the pct tag, a new np tag for non-existent subdomains) are covered in the record tags entry.