DMARC: the complete guide

SMTP was standardised in 1982, when the handful of connected networks trusted one another. Nothing in the protocol checks a sender's identity. Typing “accounts@your-company.com” into the From field takes exactly as much technical skill as typing the subject line.

SPF arrived in 2006 to declare which servers may send for a domain, DKIM the same year to sign messages. Each left a door open: SPF checks the Envelope-From, which the recipient never sees, and DKIM checks the domain the signer declares for themselves. A fraudster could therefore pass both checks on their own domain while displaying yours.

DMARC, published in 2015 as RFC 7489, closes that door with two simple ideas: alignment, and a public instruction on what to do when a check fails.

On receiving a message, a server that enforces DMARC proceeds in four steps.

1. It reads the domain of the visible From field, the Header-From, and looks up the DMARC record published at _dmarc. followed by that domain.
2. It evaluates SPF and DKIM separately, as it would have without DMARC.
3. It checks alignment: is the domain that passed SPF or DKIM the same as the From domain?
4. If neither is both valid and aligned, it applies the policy published in the record.

_dmarc.example.com.  IN  TXT
  "v=DMARC1; p=reject; rua=mailto:reports@example.com;
   adkim=s; aspf=s; pct=100"

The defaults are permissive. A record reduced to v=DMARC1; p=reject works, but it applies relaxed alignment and sends no reports: you are blocking blind and you will never know what you blocked.

A message carries two sender addresses, and this is the heart of the subject. The Envelope-From is used for transport and bounces: it is what SPF checks, and nobody sees it. The Header-From is what your client displays. Nothing requires the two to match.

Alignment requires exactly that they match. In relaxed mode (r, the default) a subdomain suffices: invoices.example.com aligns with example.com. In strict mode (s) the two domains must be identical.

It is also the commonest cause of failure on perfectly legitimate mail. An email service provider often sends with its own Envelope-From (bounces.provider.com): SPF passes, but on the wrong domain, so alignment fails. The fix is to configure a custom return path at the provider, under your own name.

The large majority of the records we look up on small-firm domains are still at p=none. That is the gap between “we have DMARC” and “we are protected”: an alarm fitted but never wired in. Each value is covered in detail in the article on policies.

Publishing a rua address makes mail servers around the world send a daily aggregate report as compressed XML. For every IP address that sent in your name it gives the message count, the SPF result, the DKIM result and the DMARC outcome.

No message content, no recipient addresses: only counters by source. That is what makes these reports straightforward under the GDPR, and completely unreadable by eye.

They serve two purposes. During rollout, they build the complete list of services legitimately sending in your name, including the invoicing tool nobody remembers signing up for. Afterwards, they show impersonation campaigns arriving, usually before a client complains.

1. 01

   Check what is already there

   Query DNS before publishing anything. A forgotten DMARC record, or two competing records, account for a good share of the surprises.

   dig +short TXT _dmarc.example.com

2. 02

   Prepare an address for the reports

   A dedicated mailbox on your own domain. It will receive one file per provider per day: do not put the address you read each morning here.

3. 03

   Publish in monitoring mode

   One TXT record, under the name _dmarc, with a policy that blocks nothing yet.

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

4. 04

   Wait, and read

   Two weeks minimum. That is what it takes to see the monthly sends go past: payroll, reminders, the quarterly newsletter.

5. 05

   Fix SPF and DKIM before tightening

   Every legitimate sender found in the reports must be aligned before the policy changes. The full procedure is in the article on moving to rejection.

No law requires DMARC today. Three converging pressures make it hard to avoid all the same.

The first comes from the mailbox providers. Since February 2024, Google and Yahoo require SPF, DKIM and a DMARC policy from any sender exceeding 5,000 messages a day to their mailboxes. Microsoft followed on 5 May 2025 for Outlook.com, Hotmail and Live.

The second is regulatory. The NIS2 directive, transposed in France through the so-called Resilience law, widens the number of entities under security obligations from 500 to ten to fifteen thousand on ANSSI's own figures. The ReCyF framework published on 17 March 2026 turns those obligations into concrete objectives; it is not yet binding, but it shows what the obligation will look like.

The third is contractual and quiet: cyber-insurance questionnaires and large customers' due-diligence packs now ask about the state of email authentication. An honest answer to that question is sometimes what starts the engagement.

• p=none, quarantine or reject: which and when · the three policies in detail and the choice they force.
• Moving DMARC to reject without breaking your mail · the rollout, stage by stage.
• What DMARC does not stop · cousin domains, display names, compromised mailboxes.
• The SPF ten-lookup limit · the silent failure that invalidates a correct SPF record.
• Business email compromise · what all of this is for.

DMARC protects one identity: your domain name, written identically. It does not block cousin domains, which the fraudster owns and configures; it does not check the display name, which can claim anything; and it validates without hesitation any message sent from a mailbox whose password has been stolen. Nor does it filter the mail you receive.

All three blind spots, with what to put against them, are covered in the article on what DMARC does not stop.