What Is DMARC? A Plain-English Guide for Migrations

DMARC is the policy layer that sits on top of SPF and DKIM and tells receiving mail servers what to do when a message claiming to be from your domain cannot be authenticated. If you are about to move mailboxes from one provider to another, DMARC is the setting most likely to silently break legitimate mail on cutover day. This entry covers what the record means, how the three policy modes behave, and what you have to change on the DNS side when your sending platform changes.

The short definition#

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is defined in RFC 7489. It is a TXT record published at _dmarc.yourdomain.com that does three jobs:

1. It declares a policy (none, quarantine, or reject) for messages that fail authentication.
2. It declares an alignment requirement — the domain in the visible From: header must match the domain that signed the message with DKIM, or the domain that passed SPF.
3. It declares a reporting address so receivers can send you XML reports about who is sending as your domain.

A minimal record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The three policy modes#

The p= tag is the single most important value in your record.

• p=none — monitor mode. Receivers still deliver failing mail, but they send you reports. This is where every rollout should start.
• p=quarantine — failing mail goes to spam or junk. Most users will not see it but it is recoverable.
• p=reject — failing mail is dropped at the SMTP layer. The sender gets a bounce. The recipient sees nothing.

SPF and DKIM alignment — the rule DMARC actually enforces#

DMARC does not replace SPF or DKIM. It layers on top of them and adds a second test called alignment.

• SPF alignment — the domain in the MAIL FROM (envelope sender) must match the domain in the visible From: header.
• DKIM alignment — the d= tag in the DKIM signature must match the domain in the visible From: header.

A message passes DMARC if at least one of SPF or DKIM passes and is aligned. That second word is the part that catches people. SPF can pass on a forwarded message and still fail alignment, which means DMARC fails too.

Aggregate vs forensic reports#

The rua= tag tells receivers where to send aggregate reports — daily XML files listing how many messages from each source IP passed or failed for your domain. These are how you discover the marketing tool, the ticketing system, or the accounting platform that has been sending as you for two years without DKIM.

The ruf= tag asks for forensic reports — per-message redacted samples of failing mail. Most receivers no longer send these for privacy reasons. Set rua= and skip ruf= unless you have a specific reason.

What changes during a migration#

When you move mailboxes — for example, when working through the complete email migration guide or running an Office 365 migration — the sending IP and the DKIM key change. Your new provider will give you one or two CNAME records (or a TXT record) to publish for DKIM. Until those resolve, the new platform is unaligned and DMARC will fail for any mail it sends.

The safe order on cutover day is:

1. Publish the new provider's DKIM CNAMEs at least 24 hours before cutover.
2. Update SPF to include the new provider (do not remove the old one yet).
3. Confirm DMARC is at p=none or p=quarantine, not reject.
4. Cut MX records over.
5. Watch aggregate reports for a week. Once the new provider is passing cleanly, remove the old SPF include and consider tightening policy.

Common gotchas#

• Subdomains inherit your DMARC policy unless you publish a separate record at _dmarc.sub.yourdomain.com, or unless you set sp= on the parent record.
• A relaxed alignment mode (adkim=r, the default) lets a signature on mg.yourdomain.com align with a From: of yourdomain.com. Strict mode (s) does not.
• Forwarding services and mailing lists routinely break SPF alignment. DKIM usually survives. This is one of the reasons DKIM matters more than SPF for DMARC outcomes.