DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication protocol that tells Gmail, Outlook, and other providers what to do when an email claims to be from your domain but fails SPF or DKIM checks. Without DMARC, any server can forge an email from your domain and you have no way to stop it or even see that it is happening.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS-based email authentication standard published in 2012. It builds on SPF and DKIM to give domain owners control over how unauthenticated email is handled. DMARC also generates regular reports so you can see who is sending email from your domain, whether they are authorized, and how receiving servers are handling authentication failures.
DMARC Explained in One Sentence
DMARC is a rule you publish in your DNS that says: "If an email from my domain fails SPF or DKIM, here is what to do with it — and send me a report when that happens."
How DMARC Relates to SPF and DKIM
SPF (Sender Policy Framework) lists which IP addresses are authorized to send from your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message to prove it hasn't been tampered with. Both are authentication checks that either pass or fail.
DMARC sits on top of both and answers the question: "So what?" If SPF passes but DKIM fails, what does the receiving server do? DMARC gives you three options: do nothing, quarantine the email, or reject it outright.
Without DMARC, receiving servers handle failures inconsistently. Some deliver to spam. Some deliver to inbox. Some block silently. You have no control and no visibility. DMARC gives you both.
| Protocol | What It Does | What It Proves | What It Does NOT Do |
|---|---|---|---|
| SPF | Lists authorized sending IPs in DNS | The sending server is allowed to send for the domain | Does not verify message content or prevent forged domain |
| DKIM | Cryptographic signature on each email | The message was not altered after signing | Does not verify the sender's identity |
| DMARC | Policy + reporting mechanism | The domain owner controls handling of failed authentication | Does not authenticate on its own — depends on SPF/DKIM |
The Three DMARC Policies: p=none, p=quarantine, p=reject
Your DMARC policy lives in a DNS TXT record and consists of a tag called p (policy). You set it to one of three values:
1. p=none (Monitor mode)
p=none tells receiving servers: "Send me reports about authentication failures, but deliver the email normally." This is the starting point. You deploy p=none first to see what email is being sent from your domain, by whom, and how often authentication is failing. Most domain owners discover shadow senders — legitimate services sending from your domain that you forgot about — during this phase.
2. p=quarantine (Spam folder)
p=quarantine tells receiving servers: "Send authentication failures to spam or the promotions folder." This is the intermediate step. Once you have reviewed reports under p=none and fixed the authentication for your legitimate senders, you move to p=quarantine to start filtering unauthorized email.
3. p=reject (Block)
p=reject tells receiving servers: "Block all email that fails authentication. Do not deliver it anywhere." This is the strictest setting and the one that actually prevents domain spoofing. Google and Yahoo required p=reject or p=quarantine for bulk senders starting in 2024. p=reject is the recommended final state for any domain that sends email.
How to Read a DMARC Record
A DMARC DNS record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; pct=100; sp=quarantine; adkim=r; aspf=rBreaking it down tag by tag:
- v=DMARC1 — version identifier. Must be DMARC1. No other version is valid.
- p=none — the policy for the domain (none, quarantine, or reject).
- rua=mailto:... — where aggregate forensic reports are sent. These are XML reports generated daily by receiving servers, summarizing how many emails passed or failed authentication and what policy was applied. Expect human-unreadable XML — you need a parser or a service (like dmarcian or Postmark's DMARC tool) to read them.
- ruf=mailto:... — where failure reports (forensic copies of individual failed messages) are sent. Optional. Can generate high volume.
- pct=100 — percentage of email the policy applies to. 100 means all email. You can start with a lower percentage to test impact.
- sp=quarantine — policy for subdomains. If omitted, subdomains inherit the parent policy.
- adkim=r — DKIM alignment.
r= relaxed (the signing domain only needs to match the organizational domain).s= strict (the signing domain must match exactly). - aspf=r — SPF alignment. Same logic:
r= relaxed,s= strict.
DMARC Alignment: When SPF and DKIM Pass but DMARC Fails
This is the most misunderstood part of DMARC. SPF and DKIM can both pass authentication, yet DMARC still fails. Why? Because DMARC requires alignment — the domain in the "From" address must match the domain that signed the DKIM signature or the domain that passed SPF.
If your email is From: news@acme.com but it was signed with a DKIM key for mailchimp.com, DKIM passes authentication (the signature is valid) but DMARC fails alignment (the signing domain does not match the From domain). The same applies to SPF: if the envelope from domain (return-path) is sendgrid.net but the From is acme.com, SPF passes but DMARC alignment fails unless you use relaxed alignment and the organizational domains match.
Alignment is why third-party senders (Mailchimp, HubSpot, Salesforce) need you to publish SPF and DKIM records for your domain. Without them, their emails fail DMARC.
How DMARC Stops Domain Spoofing and Phishing
Before DMARC, anyone could forge an email that looked like it came from your domain. The receiving server had no way to verify it was truly from you. Phishing campaigns that impersonated banks, payment processors, and government agencies relied on this vulnerability.
With DMARC set to p=reject, a forged email claiming to be from your domain but sent from an unauthorized server hits the recipient's server, fails SPF (the IP is not in your SPF record), fails DKIM (no valid signature from your domain), and the receiving server checks DMARC, sees p=reject, and drops the email. It never reaches the recipient's inbox. The phisher gets blocked and often does not even know why.
For email senders — especially cold email senders — DMARC prevents domain spoofing by competitors or bad actors that could destroy your sender reputation. If someone else sends spam from a forged version of your domain and you have no DMARC policy, the receiving servers see your domain in the From address and the spam reports hurt your reputation. DMARC prevents this by blocking those forged emails before they land.
Step-by-Step: How to Set Up DMARC
Setting up DMARC is a four-week process. Do not skip to p=reject on day one. Here is the correct sequence:
Week 1 — Deploy p=none and collect reports
Publish a DMARC record with p=none and a valid rua email address. Wait 3-5 days for receiving servers to start sending aggregate reports. During this period, identify all legitimate services sending email from your domain — email marketing platforms, CRMs, support desks, calendar tools, transactional email providers. You will discover services you forgot about.
Week 2 — Review reports and fix authentication
Use a DMARC report parser (GlockApps, dmarcian, Postmark's DMARC tool). Identify senders that are failing authentication. For each legitimate sender, add their sending IPs to your SPF record and publish their DKIM key in your DNS. This ensures their email also passes DMARC.
Week 3 — Deploy p=quarantine
Once your authenticated senders are passing, move to p=quarantine. Monitor reports to see if any legitimate email is being sent to spam. If you catch issues, fix them and wait another week.
Week 4 — Deploy p=reject
After verifying that all legitimate email passes authentication under p=quarantine, move to p=reject. This is the final state recommended by Google, Yahoo, and Microsoft for all senders.
Common DMARC Setup Mistakes
- Using an invalid rua email — the email address in your rua tag must accept mail from external servers. Using the same domain you are protecting means the reports may not arrive if delivery to that domain is affected. Use a Gmail or Outlook address on a separate domain.
- Not configuring SPF or DKIM first — DMARC has nothing to enforce if SPF and DKIM are not set up. You must configure both before DMARC does anything useful.
- Going straight to p=reject — you will almost certainly block legitimate email. Every domain has shadow senders — services that send from your domain without your knowledge. Discover them at p=none before you enforce at p=reject.
- Setting pct below 100 permanently — some guides suggest starting at pct=20 and ramping up. This is fine during testing, but the goal is pct=100. Partial policies leave gaps for spoofers.
- Not handling subdomains — the sp= tag controls subdomain policy. If you have subdomains sending email (like
mail.yourdomain.com), set sp= explicitly rather than relying on the parent policy.
What Happens When DMARC Is Misconfigured
Scenario 1: No DMARC at all
Anyone can spoof your domain. Phishing emails impersonating your company get delivered to your customers, partners, and employees. You have zero visibility into who is sending from your domain. Your reputation takes damage from spam complaints that are not your fault. Recovery requires setting up DMARC after the fact, but the reputational damage is already done.
Scenario 2: p=none permanently
You get reports but never enforce. Spoofing continues because receiving servers see p=none and deliver the email anyway. Many domain owners get stuck here because they are afraid of breaking email delivery. The fix is to actually fix the authentication for legitimate senders, not to stay at p=none forever.
Scenario 3: p=reject before fixing third-party senders
You deploy p=reject immediately and discover that your marketing automation platform, your support ticketing system, and your calendar booking tool all fail DMARC. Their emails get blocked. Customer support tickets go undelivered. New account verification emails disappear. You scramble to roll back the DNS record while tracking down every service that sends from your domain.
Frequently Asked Questions
Is DMARC required for cold email?
Since February 2024, Google and Yahoo require DMARC for any sender sending more than 5,000 messages per day to their domains. For smaller volumes, DMARC is not technically required but is strongly recommended. Sending without DMARC leaves your domain vulnerable to spoofing and provides no protection against reputation damage from forged emails.
Does DMARC stop all phishing?
DMARC stops phishing that uses exact domain spoofing — emails where the From address exactly matches a legitimate domain. It does not stop lookalike domains (acme-support.com instead of acme.com), cousin domains (acme.co instead of acme.com), or email accounts on free providers that impersonate your brand. DMARC is one layer in a broader email security strategy.
Can I have DMARC without SPF or DKIM?
Technically yes, but it is pointless. DMARC evaluates SPF and DKIM results. If neither is configured, every email from your domain fails authentication and DMARC enforces your policy against every email — including your own. You must have at least SPF or DKIM (preferably both) for DMARC to work as intended.
How do I read DMARC reports?
DMARC reports are XML files sent as email attachments. They are human-readable only if you have a tool to parse them. Free options: Postmark's DMARC tool (free for up to 1 domain), dmarcian (free tier), and BIMI Group's DMARC Check. Paid options: GlockApps, Valimail, MxToolbox. Do not try to read raw DMARC reports in a text editor — the XML structure is deeply nested and not designed for manual analysis.
What is BIMI and how does it relate to DMARC?
BIMI (Brand Indicators for Message Identification) is a standard that displays your brand logo next to email in participating providers (Gmail, Yahoo, Fastmail). BIMI requires a DMARC policy of p=quarantine or p=reject. It does not require SPF or DKIM but since DMARC needs them, effectively BIMI requires all three. DMARC is the prerequisite for BIMI.
How long does it take for a DMARC DNS change to propagate?
DMARC records are published in DNS, so propagation depends on your DNS provider's TTL settings. Most changes propagate within 5-15 minutes, but some DNS providers cache for up to 24 hours. Set your TTL low (5-10 minutes) during the initial deployment phase to enable rapid changes. After you reach p=reject, you can increase the TTL to reduce DNS lookup load.
For a complete technical walkthrough of all three protocols, see our cold email deliverability guide.