emailmarketing.net
EnglishFrançais

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

What DMARC does and doesn't do, how it builds on SPF and DKIM, domain alignment, the DNS record, and choosing a handling policy.

Operational5 min read

Who it is for ESP operators, Senders

Applies to senders on any platform

ContentsOn this page — 11 sections

Why domain owners publish DMARC

Anyone can put your domain in the From line that recipients see. DMARC gives you, the owner of that domain, a way to show receivers which of that mail you authorized. It does so by checking the results of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) against the domain in the RFC5322.From header, which people also call the "Friendly From".

For a domain that sends in volume, DMARC is no longer optional. Google and Yahoo both require bulk senders to publish a DMARC record before their mail is considered for acceptance and delivery.

The sections below explain the ideas behind DMARC and the general shape of a setup. They are not a complete step-by-step guide.

Which specification applies

RFC 7489 first described DMARC in 2015, as an Informational document. In May 2026 its successor, known as DMARCbis, became a Proposed Standard in three parts: RFC 9989 for the core protocol, RFC 9990 for aggregate reports and RFC 9991 for failure reports. Together they obsolete RFC 7489 and RFC 9091.

The concepts on this page hold under both specifications, and the few details that changed since RFC 7489 are noted where they come up. For every record tag, and for the DNS Tree Walk that takes the place of the Public Suffix List, see the DMARC standard reference. For rollout in depth, including subdomain policy, the new np and t tags and report processing, see DMARC deployment in depth.

The three jobs DMARC does

A DMARC record lets a domain owner:

  • stop other people from using the domain in the RFC5322.From header without permission, which is what spoofing is
  • ask mailbox providers for reports on the mail that shows the domain in that header
  • ask receivers to handle in a particular way any message that shows the domain there but fails the DMARC check

What DMARC leaves unsolved

DMARC answers a single question: did the domain owner authorize this use of the From domain? A message that passes can still be spam.

Two common impersonation tricks also get past it:

  • Lookalike domains. A DMARC policy on "example.com" has no effect on mail from a near copy such as "ex4mple.com". The copy is a different domain, with its own DNS.

  • Display-name attacks. The attacker sends from a domain they control and writes a trusted name in the display name, which is the part many mail apps show first:

    From: "Your Bank Security Team" <alerts@unrelated-sender.example>

SPF and DKIM in brief

SPF checks the path a message took. The owner of a domain lists in DNS the servers and networks allowed to send mail whose RFC5321.MailFrom address, also called the "Envelope From", uses that domain. Mail servers rely on this address when they pass mail between them. It ends up in the Return-Path header, and most recipients never see it.

DKIM checks the message itself. The domain that takes responsibility for a message adds a DKIM-Signature header. The header carries two cryptographic hashes of the message and the details a receiver needs to verify them. Adding the header is called signing the message, and the domain named in it is the "DKIM d= domain". When verification succeeds, the receiver knows that the signed parts of the message have not changed since signing.

Organizational Domain and alignment

DMARC adds two terms of its own:

  • Organizational Domain: the registered domain behind a business, a brand or any other organization's presence on the internet, such as "example.com".
  • Domain Alignment: two domains are aligned when they share an Organizational Domain. So "billing.example.com" is aligned with "sales.example.com", and also with "example.com" itself. By contrast, "example.net" fails to align with "sales.example.com", even when a single company owns both.

This is relaxed alignment, which receivers apply by default. A domain owner can ask for strict alignment instead, where the two domains must be identical.

How a message passes

A receiver starts by looking up a DMARC record for the RFC5322.From domain. When one exists, the message passes if at least one of these is true:

  • a DKIM signature verifies, and its d= domain is aligned with the From domain
  • SPF passes for the RFC5321.MailFrom domain, and that domain is aligned with the From domain

One aligned pass is enough, so you do not need both. Even so, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Email Authentication Recommended Best Practices ask senders to get an aligned pass from both. If you can manage only one, choose DKIM. Mailbox providers give it more weight than SPF, in DMARC and also when they decide who may join feedback loops and other programs for senders.

Publishing the record

You take part in DMARC by adding a TXT record to your domain's DNS. Its format was first set out in RFC 7489 and is now defined by the standards-track RFC 9989. The record is a list of tag and value pairs separated by semicolons. Every record needs the first two tags below, and the third is strongly recommended:

Tag What it holds
v= The version. Today it has one valid value, DMARC1, and it must open the record as v=DMARC1;
p= What you ask receivers to do with mail that fails DMARC. none asks them to handle it as if DMARC had not failed, quarantine asks them to deliver it to the spam folder, and reject asks them to refuse it. Make your first record p=none; and tighten it later, unless the domain is brand new or sends no mail at all.
rua= The mailbox that receives aggregate reports, for example rua=mailto:dmarc-reports@example.com. Providers that check DMARC usually send these reports once a day. Each one is an XML file of statistics about mail that used your domain in the From header, grouped by sending IP address, authentication result and other fields. Software reads them, not people, so give them a mailbox of their own.

Moving to enforcement

For most domains, p=none is the right place to start. A domain that wants strong protection against spoofing, or that may later want its logo shown through BIMI, will then move on to p=quarantine or p=reject. Each of those policies counts as Enforcement: mail that uses the domain without authorization no longer reaches the inbox. M3AAWG goes further and treats the monitoring policy as a transitional state to leave as soon as you can.

Let the aggregate reports set the timing. For each source that sends with your domain, they show whether it authenticates with DKIM, SPF or both. Once every legitimate source does, tighten the policy.

Doing it yourself or hiring a specialist

A domain owner with enough technical skill can do all of the DMARC work in-house. Many find it easier to bring in an outside provider. dmarcvendors.com keeps a list of DMARC service providers, along with material for learning about DMARC.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 13 in Authentication →