What Is DMARC? Email Authentication Explained
DMARC protects your domain from email spoofing and phishing. Learn how DMARC works with SPF and DKIM, what the policies mean, and why Google and Yahoo now require it.
Every day, billions of phishing emails are sent using spoofed sender addresses — "From: ceo@yourcompany.com" — and many mail servers will deliver them. DMARC is the protocol that stops this. Yet fewer than 30% of domains have a DMARC record, and of those, many are set to do nothing.
This guide explains what DMARC is, how it fits into the email authentication stack, and what the policies actually do.
The Email Spoofing Problem
Email was designed in 1971 without authentication. The From: header in an email is not verified by the original SMTP protocol — any server can claim any sender address.
This is why phishing works. An attacker sends an email with From: support@yourbank.com and many mail servers will accept and deliver it. The recipient sees a trusted sender name and acts accordingly.
The Email Authentication Stack
DMARC doesn't work alone. It builds on two existing protocols:
SPF (Sender Policy Framework)
SPF publishes a DNS record listing which mail servers are authorized to send email for your domain.
yourdomain.com TXT "v=spf1 include:_spf.google.com ip4:203.0.113.1 ~all"
When a mail server receives a message claiming to be from yourdomain.com, it looks up your SPF record and checks whether the sending IP is on the list. If not, SPF fails.
SPF's limitation: SPF checks the Return-Path (envelope sender), not the From: header that users see. An attacker can have a valid SPF record for attacker.com while putting bank.com in the From: header — and SPF passes.
DKIM (DomainKeys Identified Mail)
DKIM cryptographically signs outbound emails. The public key is published in DNS. Receiving servers verify the signature to confirm the message was sent by someone with access to the private key.
DKIM checks the d= domain tag in the signature. Again, an attacker can have valid DKIM for attacker.com while spoofing the From: domain.
DMARC — The Missing Piece
DMARC adds two things that SPF and DKIM lack:
-
Alignment check: Requires that the domain in SPF or DKIM matches the
From:domain the user sees. This closes the loophole where attackers pass SPF/DKIM for their own domain while spoofing yours. -
Policy enforcement: Tells receiving servers what to do with messages that fail — deliver, quarantine, or reject.
How DMARC Works Step by Step
When a mail server receives an email:
- Extract the
From:domain (e.g.,yourdomain.com) - Look up
_dmarc.yourdomain.comfor a DMARC record - Evaluate SPF: did the
Return-Pathdomain pass SPF and align withFrom:? - Evaluate DKIM: did the
d=signature domain pass DKIM and align withFrom:? - If either passes + aligns: DMARC passes → deliver
- If neither passes + aligns: apply the
p=policy (none/quarantine/reject) - Send an aggregate report to
rua=address
DMARC Record Anatomy
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100"
| Tag | Required | Description |
|---|---|---|
v=DMARC1 | Yes | Version identifier |
p= | Yes | Policy: none, quarantine, or reject |
rua= | Recommended | Aggregate report destination |
ruf= | Optional | Forensic report destination |
pct= | Optional | % of failing mail to apply policy to (default: 100) |
sp= | Optional | Subdomain policy |
adkim= | Optional | DKIM alignment: r relaxed, s strict |
aspf= | Optional | SPF alignment: r relaxed, s strict |
The Three DMARC Policies
none — Monitoring Only
p=none
DMARC results are reported but not acted on. All mail is delivered, including spoofed messages. Use this during the initial setup phase to map your email streams before enforcing anything.
⚠️ Many organizations deploy p=none and leave it there permanently. This provides zero protection.
quarantine — Soft Enforcement
p=quarantine
Mail that fails DMARC is sent to the spam/junk folder. Recipients can still find it, but it's flagged as suspicious. Good as a stepping stone.
reject — Full Enforcement
p=reject
Mail that fails DMARC is rejected at the SMTP level and never delivered. This is the only policy that actually prevents spoofed email from reaching recipients.
DMARC and Business Email Compromise
Business Email Compromise (BEC) — where attackers impersonate executives or vendors to redirect wire transfers — caused $2.7 billion in US losses in 2022 according to the FBI.
Many BEC attacks use exact domain spoofing (CEO@yourcompany.com). A p=reject DMARC policy stops exact domain spoofing entirely for participating receivers. It doesn't stop lookalike domains (yourcompany-secure.com), but it eliminates the easiest attack vector.
Why Google and Yahoo Require DMARC (2024)
In February 2024, Google and Yahoo began requiring that bulk senders (5,000+ emails/day to Gmail or Yahoo) have:
- A valid SPF record
- DKIM signing
- A DMARC policy of at least
p=none
Organizations without these will see their mail rejected or quarantined by Gmail and Yahoo. This requirement pushed DMARC adoption dramatically and is expected to trigger similar requirements from other major providers.
What DMARC Reports Tell You
Aggregate reports are XML files sent daily to your rua address. They contain:
- Source IP addresses sending mail claiming to be your domain
- Whether SPF and DKIM passed or failed for each source
- Whether DMARC alignment passed
- Volume of messages by source
This data is invaluable for discovering:
- Third-party services sending mail on your behalf that you forgot to authorize
- Forwarding services that break SPF alignment (mailing lists, email forwarders)
- Active spoofing attempts against your domain
Getting Started
The fastest safe start:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
Review reports for 30 days, fix all SPF/DKIM alignment issues, then escalate to p=reject.
For parked domains that never send email, deploy maximum enforcement immediately:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; sp=reject"