What Is DMARC? The Complete Guide to Email Authentication

Why DMARC Exists in the First Place

The SMTP protocol that all of the world’s email runs on dates back to 1982. It was designed in an era where the handful of mail servers on the network trusted each other. One central consequence of that design has survived intact: anyone can write whatever they want into the From: header of an email. That is not a bug. That is the protocol.

This gap is exactly what phishing and spoofing attacks have been exploiting for decades. An attacker drops your domain into the sender field, and without further measures the email lands in the inbox of your customers, employees, or suppliers — carrying your brand name.

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) is the answer to this problem. It is the DNS policy that lets you, as the domain owner, tell receiving mail servers: “This domain authenticates its email. If something doesn’t match up, do the following — and send me a report about it.”

DMARC does not invent new authentication of its own. It combines two pre-existing standards — SPF and DKIM — and adds two crucial building blocks on top: alignment and reporting.

The Three Layers: SPF, DKIM, DMARC

SPF (Sender Policy Framework)

SPF is a TXT record in your domain’s DNS that lists which servers are allowed to send email on behalf of your domain:

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

When a mail server receives an email from IP 1.2.3.4 with the sender domain example.com, it queries the SPF record and checks whether 1.2.3.4 is authorized. SPF checks the envelope-from (also called the return-path), not the From: header that the recipient actually sees.

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs outbound emails. The public key sits in DNS, the private key on the sending mail server. Receiving servers verify the signature, which lets them confirm that the message wasn’t altered in transit and really came from an authorized sender.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE..."

DMARC Ties Them Together — and Adds Alignment

Here is the crucial point: SPF and DKIM alone are not enough. An attacker can register a domain with a valid SPF record (say, attacker.com), send an email with From: [email protected] from there, and SPF will pass — because SPF only checks the sending domain, not the one the recipient sees.

DMARC closes this gap with identifier alignment: the domain in the visible From: header must match the domain that SPF or DKIM authenticated.

An email passes DMARC if:

1. SPF passes AND the SPF domain matches the From: header (SPF alignment), OR
2. The DKIM signature is valid AND the DKIM domain matches the From: header (DKIM alignment).

Only one of these conditions has to be met. That is exactly what makes DMARC robust against forwarding and mailing lists, which break SPF but usually preserve DKIM.

How a DMARC Check Actually Runs

When a receiving mail server (Google, Microsoft, Yahoo, etc.) gets an email:

1. It extracts the domain from the From: header — say, example.com.
2. It queries _dmarc.example.com over DNS and reads the DMARC record.
3. It runs SPF and DKIM checks.
4. It checks alignment: does either of the authenticated domains match example.com?
5. If neither alignment condition is met, it applies the policy stated in the DMARC record (none, quarantine, or reject).
6. It generates an aggregate report and sends it to the address you specified in the rua= tag.

Step 6 is the reason you ever learn anything about your own domain in the first place.

Anatomy of a DMARC Record

A typical DMARC record looks like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100; sp=reject"

Here are the key tags:

Tag	Meaning	Values
v	Version (required, always DMARC1)	DMARC1
p	Policy for the main domain (required)	none, quarantine, reject
sp	Policy for subdomains	none, quarantine, reject
rua	Address(es) for aggregate reports	mailto:[email protected]
ruf	Address(es) for forensic reports	mailto:[email protected]
adkim	DKIM alignment mode	r (relaxed, default) or s (strict)
aspf	SPF alignment mode	r (relaxed, default) or s (strict)
pct	Percentage of failing mail the policy applies to	0–100
fo	Conditions under which forensic reports are generated	0, 1, d, s
ri	Report interval in seconds	Default: 86400 (24h)
rf	Format of forensic reports	afrf

A few points that are commonly misunderstood in practice:

• pct is a migration tool, not a protection level. If you set p=reject; pct=10, only 10% of failing emails actually get rejected — the rest fall back to the next-weaker policy. That’s useful during a gradual rollout, but as an end state it’s not full protection.
• You only need sp if it differs from p. If you omit sp, subdomains inherit the policy from p automatically. A recommendation like “also set sp=reject” while you already have p=reject is redundant.
• adkim=s/aspf=s require an exact domain match. The default (r, relaxed) accepts a matching organizational domain — so mail.example.com and example.com are considered aligned.
• ruf (forensic reports) is barely supported anymore. For privacy reasons, most large providers no longer send forensic reports. Focus on rua.

What About “DMARC v2”?

The IETF DMARC working group has been working on a revision of RFC 7489 for several years, generally referred to as DMARCbis (occasionally called “DMARC v2” colloquially). One important clarification up front: the version tag in the record stays v=DMARC1 — and that is a deliberate design decision. Existing records are meant to remain valid without any change, and receivers shouldn’t accidentally reject DMARCbis records because they see an unknown version.

The most notable changes, as currently shaped:

• A new tag np= for “non-existent subdomain policy” — a dedicated policy for subdomains that don’t exist in DNS. Previously these fell under sp= (or p= if sp was absent), which could produce unexpected behavior in subdomain spoofing scenarios. With np=reject you can lock down non-existent subdomains without tightening sp= for real subdomains.
• Replacement of the Public Suffix List (PSL) with a DNS-based tree walk algorithm for determining the organizational domain. This addresses a known weakness, since the PSL isn’t guaranteed to be current and doesn’t cover every TLD.
• A psd= tag for operators of public suffix domains, letting PSDs (e.g. .gov.uk) explicitly state whether domains beneath them are subject to DMARC evaluation.
• Removal of pct=. The tag has long been considered problematic because it makes actual enforcement behavior hard to predict and receivers interpret it inconsistently. Migration is intended to happen via stepwise policy changes and np= instead.

Until DMARCbis is published as a final RFC, the practical guidance is: stay on v=DMARC1, keep using pct= for migration, and np= can be deployed optionally already — several large mailbox providers honor it.

Aggregate Reports: The Gold Mine Almost Nobody Reads

Once you set rua=, every major mail server in the world will send you a daily XML file. That file contains:

• Which IP addresses sent email in your name
• How many messages came from each source
• Whether SPF and DKIM passed or failed for each
• Which policy was applied (delivered, quarantined, rejected)
• Which From: domain was in the header

That is exactly the information you need to see who is actually sending email in your name — both legitimate services you forgot to authorize, and spoofers abusing your domain.

The catch: reading these reports manually is unrealistic. A medium-sized domain receives hundreds of XML files per day from dozens of receivers. Without tooling, this is just data, not insight — which is exactly where DMARC analysis tools like DMARCPulse come in.

The Three Policies — and Which One You Actually Need

p=none (monitoring)

Receiving servers do nothing with failing emails — they only send reports. Useful as a starting point to see what your domain is sending in the first place, without breaking legitimate mail. But: no protection.

p=quarantine (spam folder)

Failing emails land in the recipient’s spam folder. This provides protection but isn’t final — recipients can still pull mail out of spam.

p=reject (full protection)

Failing emails are rejected outright and never reach the recipient, typically with a 550 5.7.1 error. This is the only state where your domain is actually protected against spoofing.

The journey from p=none to p=reject is methodical, not fast — and the most common reason for stalling is fear of breaking legitimate mail. We have a dedicated article on that: DMARC Enforcement Gap: p=none Is Not Enough.

Common Pitfalls

The same problems show up over and over in practice:

• The SPF 10-lookup limit. SPF allows at most 10 DNS lookups per evaluation. Every include: counts — and large providers like Microsoft 365 burn several on their own. If you naively add every new service via include:, you’ll eventually hit PermError, and SPF will fail silently. SPF flattening or cleanup becomes unavoidable at that point.
• Raw IP addresses in SPF. ip4:1.2.3.4 is convenient short-term and brittle long-term: if the provider changes the IP, you break mail flow. Prefer include: against provider domains.
• DKIM with a revoked key. A DKIM record with an empty p= is an explicit revocation. Some tools accidentally do this when rotating keys.
• Weak DKIM keys. RSA below 1024 bits is considered insecure; the current recommendation is 2048 bits.
• Forgotten mail services. Marketing tools, ticketing systems, accounting software — every service that sends mail in your name needs to be added to SPF (or DKIM), or legitimate emails will fail DMARC.
• ruf address without recipient authorization. If you put a third-party domain into ruf=, that domain needs a _report._dmarc.{your-domain} record authorizing it. The same holds for rua= at external services.

What Comes After DMARC

DMARC is the foundation. But modern email security is built in layers:

• BIMI (Brand Indicators for Message Identification) — displays your brand logo next to authenticated emails in the inbox. Requires p=quarantine or p=reject.
• MTA-STS — enforces TLS encryption on inbound mail to your domain. Protects against downgrade attacks that DMARC doesn’t cover.
• TLS-RPT — gives you reports on when TLS connections to your mail server fail.
• Domain Connect — lets supported DNS providers set DMARC, SPF, and DKIM records with a single click.

But most domains aren’t struggling with “what comes after DMARC?” — they’re struggling with “how do we even get to p=reject?”. According to Cloudflare’s 2026 threat report, 46% of all emails worldwide fail DMARC validation — we broke that down here: Why 46% of Email Fails DMARC.

From Record to Practice

Publishing a DMARC record is trivial. That’s not the problem. The problem is what comes after:

1. Collect and parse reports. Daily XML files from dozens of sources.
2. Identify sending sources. Which IPs belong to which service? Which are legitimate, which aren’t?
3. Fix SPF and DKIM for every legitimate source. With concrete DNS values — not just “add this”.
4. Migrate gradually. p=none → p=quarantine → p=reject, with consistently high pass rates (>95%) as the precondition for each step.
5. Avoid drift. New services get added, keys rotate, IPs change. DMARC isn’t a project, it’s an operational process.

DMARCPulse is built for exactly this: reports are ingested and parsed automatically, sending sources classified, and concrete recommendations generated with copy-paste-ready DNS values. Instead of “SPF failed for source X”, you get the exact include: entry or DKIM selector that’s missing. Free 14-day trial.

Summary

• DMARC combines SPF and DKIM with alignment and reporting and closes the gap that SMTP leaves open by default.
• An email passes DMARC if either SPF or DKIM passes and the corresponding domain aligns with the From: header.
• A DMARC record consists of tags like p, rua, adkim, aspf, pct — the most important ones are p (policy) and rua (report address).
• The three policies are none (monitoring), quarantine (spam) and reject (full protection). Only p=reject actually protects you.
• Aggregate reports are the gold mine — but only if you actually parse them.
• DMARC is the foundation; BIMI, MTA-STS, and TLS-RPT build on top of it.