What is DMARC?

The problem it solves

The From address in an email is just text. Without DMARC, anyone can send a message that shows your domain there, and receivers have no instruction from you about what to do with it. That's how invoice fraud and phishing in your name work. SPF and DKIM don't close the gap on their own: SPF checks the envelope sender, DKIM checks whichever domain signed, and neither has to match the From line.

How DMARC works, end to end

RFC 9989, which replaced RFC 7489 in May 2026, describes what a receiver does with each message:

1. It takes the domain from the From header. That is the domain DMARC protects.
2. It looks for a DMARC record at _dmarc under that domain. If there is none, it walks up the DNS tree to find the organizational domain, so a subdomain without a record of its own is covered by its organizational domain's record, usually the registered domain such as example.com. No record anywhere means DMARC doesn't apply to the message.
3. It takes the SPF and DKIM results it already has for the message.
4. It checks alignment: did SPF or DKIM pass for a domain that matches the From domain? With relaxed alignment, a subdomain like mail.example.com counts as a match for example.com. DMARC alignment explained covers the exact rules.
5. One aligned pass is enough for the message to pass DMARC. With none, it fails, and the receiver weighs your policy in its decision: p for the domain itself, sp for an existing subdomain and np for one that doesn't exist.
6. It records the outcome and later sends it, grouped by sending IP address, in an aggregate report to your rua address.

Two details are easy to miss. If a DNS lookup needed for the check fails, the message neither passes nor fails, and your policy isn't applied. And the final decision always belongs to the receiver: RFC 9989 tells receivers not to reject mail on the strength of p=reject alone, and to treat it like quarantine unless they have other evidence.

Anatomy of a record

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Only v is required. A record without a valid p is treated as p=none if it lists a syntactically valid rua URI; otherwise the receiver skips DMARC for the message. The alignment tags default to relaxed. RFC 9989 also defines np, t for testing, ruf and fo for per-message failure reports, and psd, which public suffix operators use.

The three policies

• p=none changes nothing about delivery. You receive reports and learn who sends as you.
• p=quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder.
• p=reject asks receivers to refuse failing mail outright. This is full protection, and moving from p=none to p=reject safely takes a staged rollout.

A worked example

example.com publishes the record above: p=quarantine for itself and sp=reject for its subdomains. Here is how four messages with an example.com address in the From line fare.

• Mail from an employee's mailbox. The mailbox provider sends with an envelope sender at example.com, which SPF authorizes, and signs with d=example.com. Both pass and both align. DMARC passes.
• A newsletter from a mailing service, set up properly. The envelope sender is the service's own bounce domain, so SPF passes for a domain that doesn't align. But the service signs with your domain's DKIM key, d=example.com. One aligned pass is enough: DMARC passes.
• The same newsletter before DKIM was set up. The service signs with its own domain, say d=mailer.example.net. Both SPF and DKIM pass, but neither for your domain. DMARC fails, and the receiver applies p=quarantine: your own newsletter lands in spam. This is the mistake reports catch before you enforce a policy.
• A phishing message from a stranger's server, with From: billing@shop.example.com. shop.example.com has no DMARC record, so the receiver walks up to example.com and, since this is a subdomain, uses sp=reject. Nothing passes for your domain, so the message is refused, or at least quarantined by a receiver that wants more evidence.

Had the attacker used a made-up name like billing@x7.example.com that doesn't exist in DNS, the receiver would look for np=. This record has none, so sp=reject applies to non-existent subdomains as well.

Testing a policy first

RFC 9989 adds a t tag. With t=y a receiver doesn't apply the published policy yet and treats failing mail one level softer: p=quarantine; t=y behaves like p=none, and p=reject; t=y like p=quarantine. The older pct tag asked receivers to apply the policy to a percentage of failing mail, but in practice only pct=0 and pct=100 were applied consistently, so RFC 9989 removed pct and made t=y the stand-in for pct=0. Until every receiver follows the new RFC, publish both, t=y; pct=0, so older receivers hold back too; the migration guide explains each stage. Patchkit's roadmap moves through p=none, quarantine (testing), quarantine, reject (testing) and reject.

One record only

A domain must publish exactly one DMARC record at _dmarc. With two, receivers discard both and the domain behaves as if it had none: a subdomain falls back to its organizational domain's record, and an organizational domain is left without DMARC. If a tool or your DNS host created one for you, edit it instead of adding another.

Reports

The rua tag tells mailbox providers where to send aggregate reports: XML files listing which servers sent mail as your domain and whether they passed. Learning how to read DMARC aggregate reports is how you find the services you forgot to set up before tightening the policy. If the address is on someone else's domain, that domain has to publish an authorization record, or RFC 9990 tells receivers to ignore the address.

Who requires it

Since 2024, Google and Yahoo require a DMARC record from bulk senders, and Microsoft followed in May 2025. A record with p=none meets the minimum, but only enforcement actually protects your domain.

Gotchas

• Google's guide still talks about pct. Google's DMARC setup page recommends including pct to roll a policy out gradually; under RFC 9989 use t=y instead (see Testing a policy first above). Google also says to wait 48 hours after setting up SPF and DKIM before adding DMARC.
• Microsoft's onmicrosoft.com domain needs its own record. Microsoft sets up SPF and DKIM for the initial onmicrosoft.com domain, but you add its DMARC record yourself, in the Microsoft 365 admin center.
• Failing mail from Microsoft 365 leaves through a separate pool. When your policy is quarantine or reject, Microsoft routes outgoing messages that fail DMARC through its high-risk delivery pool, with no override.
• p=reject needs DKIM. Forwarding breaks SPF but usually leaves DKIM intact, so RFC 9989 says a domain publishing p=reject must sign its mail with DKIM rather than rely on SPF alone. It also warns that p=reject on a domain whose people post to mailing lists can cause trouble for those lists, and suggests a month of p=none and an equally long stretch of quarantine first.
• Unused domains are easy wins. Microsoft recommends a DMARC record with p=reject for parked domains that never send mail, so nobody can send as them either.

Check yours

Check your current record with the DMARC checker or build one with the DMARC generator.