What Is DMARC?

DMARC is the layer that finally makes email authentication useful to the person reading the inbox. It stands for Domain-based Message Authentication, Reporting, and Conformance, and it does not replace SPF or DKIM — it sits on top of both and ties them to the one thing recipients actually see: the From address. This article explains what each part of DMARC does, why it exists, and what it means to move a domain to enforcement.

The gap DMARC closes

SPF and DKIM are the two workhorses of email authentication, but each one checks something the recipient never sees. SPF verifies that the sending server is authorized by the domain in the envelope sender — the hidden Return-Path address used for bounces. DKIM verifies a cryptographic signature tied to whatever domain appears in the signature's d= tag. Neither standard looks at the From address displayed in the inbox.

That gap is exactly what phishers exploit: a message can pass SPF and DKIM for a domain the attacker controls while showing your brand in the From line. DMARC closes the gap. It tells receiving mail servers to check whether SPF or DKIM not only passed, but passed for a domain that matches the visible From domain. Then it lets you, the domain owner, publish a policy for mail that fails, and it gives you reporting so you can see who is sending mail as your domain across the internet.

The record itself is a single DNS TXT record published at _dmarc.yourdomain.com, and its value always begins with v=DMARC1. You can confirm any domain's record with our DMARC record checker.

Alignment: the rule that makes DMARC meaningful

Alignment is the concept that turns SPF and DKIM from technical checks into a real anti-spoofing control. For SPF, DMARC compares the Return-Path domain against the From domain. For DKIM, it compares the d= domain in the signature against the From domain. A message passes DMARC if at least one of those two checks both passes its own validation and aligns.

You do not need both to pass, though publishing both is strongly recommended. Forwarding frequently breaks SPF because the forwarder's server is not in your SPF record, while a valid DKIM signature usually survives forwarding intact — so having both gives your mail two chances to pass.

Alignment comes in two modes, set by the aspf and adkim tags:

• Relaxed (r, the default) accepts a match at the organizational-domain level. Mail signed by mail.example.com aligns with a From address at example.com. This is the right choice for most senders, especially if you use subdomains for marketing or transactional mail.
• Strict (s) requires an exact, character-for-character domain match. It is worth considering once your setup is stable and you want to stop one subdomain's mail stream from aligning on behalf of another.

The policy: what receivers should do with failing mail

The p tag declares what receivers should do with mail that fails DMARC. It has three values, and almost every successful deployment moves through them in order:

• p=none is pure monitoring. Nothing is blocked, but aggregate reports start flowing. This is where you build an inventory of every system that legitimately sends as your domain.
• p=quarantine asks receivers to treat failing mail with suspicion, typically routing it to the spam folder.
• p=reject instructs receivers to refuse failing mail outright. This is the only setting that actually stops spoofed messages from reaching inboxes.

Enforcement means running at quarantine or reject. A record that stays at p=none forever blocks nothing — it only watches. The walkthrough in how to set up DMARC covers how to ramp through these stages safely. Note that the old pct tag for percentage-based rollout was removed in DMARCbis (RFC 9989, published May 2026, which obsoletes the original RFC 7489); the modern equivalents are the t=y test-mode flag and enforcing on subdomains via sp before tightening the main domain.

Aggregate (rua) and forensic (ruf) reports

Reporting is the half of DMARC that pays for itself immediately. There are two kinds.

Aggregate reports are the heart of the feedback loop. Mailbox providers that evaluate your mail send XML summaries — typically once a day — to the mailto: address in your rua tag. Each report lists the IP addresses that sent mail claiming to be your domain, how many messages came from each, whether SPF and DKIM passed, whether they aligned, and what policy the receiver applied. They contain no message content, which is why providers send them freely. Reading them is a matter of sorting senders into three buckets: aligned and passing (healthy), legitimate but failing (a vendor to fix), and unknown sources (forwarding or active spoofing).

Forensic reports (the ruf tag), also called failure reports, are redacted copies of individual failing messages. In practice you should not depend on them — the large mailbox providers generally decline to send them over privacy concerns. The updated standard reflects this by removing the rf report-format tag entirely. Treat ruf as occasionally useful extra signal, never as your primary data source.

Subdomain policy: sp and np

By default, subdomains inherit your main policy from p. The sp tag overrides that. While ramping up, some teams keep p=none on the organizational domain but set sp=reject early, since spoofers love inventing plausible subdomains like secure.example.com or billing.example.com. The np tag covers non-existent subdomains — names with no A, AAAA, or MX records. Because nothing legitimate can originate there, np=reject is one of the few DMARC settings you can apply immediately with essentially zero risk.

Why it matters now

DMARC moved from best practice to hard requirement when Gmail and Yahoo began enforcing sender rules for bulk mailers. Senders above roughly five thousand messages a day to Gmail addresses must publish a DMARC record with at least p=none, authenticate with both SPF and DKIM, and align the From domain with at least one. There is a carrot too: BIMI, which shows your logo beside authenticated mail, requires DMARC at enforcement (p=quarantine or p=reject) as a prerequisite. Run your domain through the DMARC record checker to see exactly where you stand, then follow how to set up DMARC to publish your first record.