What is DMARC, and why
does your domain need it?
Every day, billions of emails claim to be from domains they're not. DMARC is the protocol that tells receiving mail servers exactly what to do when that happens — and lets you see the full picture of who's sending on your behalf.
The problem DMARC solves
Email's original design had a serious blind spot: anyone could send a message claiming to be from any address. Your domain name — the part after the @ — was just text. No proof required.
This made spoofing trivial. Attackers could send emails that look exactly like they came from your bank, your boss, or your business. DMARC closes this gap by giving domain owners a way to publish a policy that receiving servers can actually enforce.
Email is sent
Someone sends a message claiming to be from your domain.
Receiver checks DNS
The receiving server looks up your DMARC record in DNS.
Authentication runs
SPF and DKIM are checked against the From: header.
Policy is applied
Your DMARC policy tells the server what to do with failures.
SPF and DKIM
DMARC's two pillars
DMARC doesn't work alone. It relies on two underlying protocols to do the actual authentication work.
SPF — Sender Policy Framework
Checks whether the mail server that actually sent the message is authorized to send on behalf of your domain. You publish a list of allowed IP addresses in DNS, and receiving servers verify against it.
DKIM — DomainKeys Identified Mail
Adds a cryptographic signature to your outgoing emails. The receiving server fetches your public key from DNS and verifies that the message wasn't tampered with in transit.
You can have valid SPF and DKIM and still be spoofed. DMARC adds alignment — it checks that those authenticated domains actually match the From: address the human sees. Without DMARC, the two systems can be bypassed independently.
Anatomy of a DMARC record
A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It's human-readable once you know the tags.
The three enforcement modes
Your p= value tells receiving mail servers how aggressive to be with failing messages.
Monitor
Take no action on failing messages. Delivers everything, but sends you reports. Best for observing your mail ecosystem before enforcing anything.
Quarantine
Failing messages go to the spam or junk folder. Recipients can still find them, but they're flagged. A middle ground for cautious enforcement.
Reject
Failing messages are refused outright at the SMTP layer. They never reach the inbox. Maximum protection — but requires all legitimate senders configured first.
Don't jump straight to reject. If you have third-party services sending on your behalf — marketing tools, support platforms, CRMs — that aren't yet SPF/DKIM authenticated, a p=reject policy will block their emails too. Always start with p=none, analyze the reports, and move through quarantine before reaching reject.
Policy simulator
See how DMARC responds to different email scenarios depending on your policy setting.
What DMARC reports tell you
One of DMARC's most underrated features is its reporting capability. Even before you enforce any policy, the reports give you a detailed map of everyone sending email that appears to come from your domain.
Daily summary reports
Sent once per day by participating mail receivers. Contains counts of messages, SPF/DKIM results, source IP addresses, and which policy was applied. Delivered as XML, usually parsed by a reporting tool.
Per-failure reports
Triggered by individual failures. Contains more detail — sometimes the full message headers. Privacy-sensitive and not sent by all receivers, but useful for diagnosing specific issues.
Reports are sent to a destination you specify. If that destination is outside your domain — for example, a third-party reporting service — DMARC requires a verification step. The receiving domain must publish a special DNS record confirming it accepts reports on your behalf. This prevents report flooding attacks where a bad actor publishes a DMARC record pointing reports at a victim address.
Recommended rollout path
A phased approach ensures you never block legitimate email.
Audit your sending sources
List every service that sends email using your domain: CRM, marketing platform, helpdesk, transactional email provider. Each one needs to be SPF-authorized and DKIM-signed before you enforce anything.
Publish p=none with reporting
Deploy your DMARC record in monitor mode with rua= set. This is safe — nothing gets blocked. Collect at least 2–4 weeks of reports to see who's sending on your behalf.
Move to p=quarantine at pct=10
Begin enforcement at a low percentage. Increase pct gradually — 10 → 25 → 50 → 100 — watching reports at each step.
Reach p=reject
Full enforcement. Unauthenticated email from your domain is rejected at the SMTP level. Your domain is no longer usable as a spoofing vector.
Frequently asked
No. DMARC only protects against spoofing of your specific domain. It doesn't prevent spam from other domains, compromised accounts, or lookalike domains. It's one layer of a multi-layer defense.
Only if you rush to reject before properly configuring all your senders. Starting with p=none gives you visibility with zero disruption risk. Never skip directly to p=reject on a live domain.
DMARC includes an sp= (subdomain policy) tag. If not specified, subdomains inherit the parent domain's policy. Subdomains you don't send from should generally be protected too.
Arguably more so. Low-volume domains are prime targets for spoofing precisely because they're less monitored. Publishing p=reject on a silent domain is low-risk and high-reward — you have nothing to break.
In early 2024, both Gmail and Yahoo Mail began requiring bulk senders (5,000+ messages/day) to have DMARC in place with at least p=none. This formalized what was previously a best practice into an effective deliverability requirement.
Get visibility into your domain today
Set up in minutes, and start understanding your email activity. First DMARC insights within 24–48 hours.