What is DMARC?

What problem does DMARC solve?

The From address people see in their inbox is just a line of text in the message. Nothing in SMTP stops a stranger from writing From: billing@yourcompany.com on a phishing email. That’s why invoice fraud and fake password-reset emails work so well: the sender looks exactly like you.

SPF and DKIM, the two older standards, each prove something about a message, but neither one checks the visible From address. SPF checks the hidden envelope sender (the Return-Path). DKIM checks whichever domain signed the message, which can be anything. An attacker can pass SPF and DKIM for attacker.example while showing your domain in From.

DMARC closes that gap. It ties the SPF and DKIM results to the From domain, lets you publish a policy for mail that doesn’t tie back to you, and gives you reports so you can see every server sending as your domain, legitimate or not.

How DMARC works with SPF and DKIM

When a receiver such as Gmail gets a message whose From address is you@example.com, it:

1. Looks up the TXT record at _dmarc.example.com. If there isn’t one, it looks at the organizational domain’s record (for mail.example.com, that’s example.com).
2. Runs SPF on the envelope sender domain and verifies any DKIM signatures.
3. Checks alignment: does a domain that passed SPF or DKIM match the From domain?
4. If at least one aligned pass exists, the message passes DMARC. Otherwise it fails, and the receiver applies your policy.
5. Records the result in the aggregate report it sends you later.

You only need one of SPF or DKIM to pass with alignment, not both. In practice DKIM carries most of the weight, because it survives forwarding and works with email platforms that use their own bounce domains.

What is alignment?

Alignment is the rule that makes DMARC more than SPF plus DKIM. For SPF, the envelope sender (Return-Path) domain must match the From domain. For DKIM, the signature’s d= domain must match it. By default the match is relaxed: both sides only need the same organizational domain, so bounces.example.com aligns with example.com. Strict mode (aspf=s, adkim=s) requires an exact match. Most DMARC failures from legitimate senders are alignment failures, and DMARC alignment explained shows how to fix them.

DMARC record tags

A DMARC record is a list of tag=value pairs separated by semicolons. Only v and p are needed. These are the tags defined by RFC 7489, the specification most receivers implement today:

Unknown tags are ignored, and tag order doesn’t matter apart from v coming first. A domain must have exactly one DMARC record. If a receiver finds two, it treats the domain as having none.

What do p=none, p=quarantine and p=reject do?

A policy is a request, not a command. Gmail, Yahoo, Outlook.com and most large mailbox providers honor it, but each makes the final call and may override it (for example for mail that came through a known forwarder). Only quarantine and reject protect you. p=none gives you visibility, which is the reason to start there. Gmail, Yahoo and Microsoft also now require bulk senders to publish at least p=none; see their sender requirements.

DMARC reports: aggregate and failure

Aggregate reports (rua) are XML files, usually zipped or gzipped, that each participating receiver emails you about once a day. Each one lists the IP addresses that sent mail using your domain, how many messages each sent, and whether SPF, DKIM and DMARC passed. They contain no message content. This is where you discover the CRM, help desk or billing system that nobody told you about. How to read DMARC aggregate reports walks through the fields.

Failure reports (ruf) describe individual failing messages and can include headers or content. Many large providers don’t send them at all for privacy reasons, so don’t plan around them.

If reports go to an address at a different domain (a DMARC service, for instance), that domain must publish a record agreeing to receive them, such as example.com._report._dmarc.reports.example.net. Receivers skip the address otherwise. Reporting services publish this for you.

A minimal DMARC record to start with

Publish this at the _dmarc host of your domain, with your own report address:

It changes nothing about delivery and starts the reports flowing. The DMARC record generator builds a record with the options you pick. With DMARC Dojo, _dmarc is a CNAME to a record we host, so later policy changes go live in about a minute without another DNS edit.

The path from p=none to p=reject

1. Monitor. Publish p=none with a rua address and collect two to four weeks of reports.
2. Fix your senders. For each legitimate source in the reports, set up DKIM signing with your domain and, where the platform supports it, a custom return-path so SPF aligns too.
3. Quarantine. Move to p=quarantine, optionally with a lower pct first, and keep watching the reports.
4. Reject. When the only failures left are spoofing and forwarding noise, move to p=reject.

How to move from p=none to p=reject covers each step, and why DMARC fails helps when a real sender won’t pass.

DMARCbis: the updated standard (RFC 9989)

In May 2026 the IETF published the revised DMARC specification, known during development as DMARCbis, as RFC 9989, with aggregate and failure reporting split into RFC 9990 and RFC 9991. It obsoletes RFC 7489 and makes DMARC a Proposed Standard. Records keep v=DMARC1, and the main changes are:

• pct is removed. A new t=y test flag asks receivers to apply one policy level lower (reject is treated as quarantine, quarantine as none).
• np sets a policy for subdomains that don’t exist, and psd marks public suffix domains.
• The organizational domain is found with a “DNS tree walk” up the domain’s labels instead of the Public Suffix List.
• rf and ri are no longer defined.