What DMARC actually is (in plain English)
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. That's a mouthful. Here's what it actually means in practice:
DMARC is a DNS record — a small piece of text you add to your domain's settings — that tells inbox providers like Gmail, Outlook, and Yahoo what to do when someone sends an email claiming to be from your domain.
Imagine your domain is a bank. SPF and DKIM are your security guards — they check ID at the door. But they don't actually do anything when someone tries to sneak in with a fake ID. DMARC is the policy that tells the guards: "if the ID is fake, turn them away." Without DMARC, the guards check credentials but shrug and let everyone in anyway.
DMARC was introduced in 2012 and is now used by every major inbox provider in the world. It builds on SPF and DKIM by adding linkage to the author's "From" domain name, published policies for how recipients should handle authentication failures, and reporting back to senders about what's happening with their email.
How DMARC works with SPF and DKIM
DMARC doesn't work alone — it's the third layer of a three-part email authentication system. Here's what each piece does:
SPF — "Did this email come from an authorized server?"
A list of IP addresses allowed to send email on your behalf. When an email arrives, the receiving server checks whether the sending server's IP is on your approved list.
DKIM — "Was this email tampered with in transit?"
A cryptographic signature added to every email you send. The receiving server verifies the signature using a public key in your DNS — if the email was altered, the signature breaks.
DMARC — "What should happen if SPF or DKIM fails?"
DMARC reads the results of SPF and DKIM, checks that they align with your visible "From" domain, and then applies the policy you've chosen: monitor, quarantine, or reject.
The key word in step 3 is "alignment." This is where many senders get caught out. It's not
enough for SPF or DKIM to pass — the authenticated domain must match the domain in your visible
From: address. If you send email through Mailchimp but your SPF record isn't aligned
to your From domain, DMARC will fail even if SPF technically passes.
You send from [email protected] via Mailchimp. SPF checks Mailchimp's sending
servers — they're authorized. But if the SPF is on Mailchimp's domain, not mybusiness.com,
DMARC alignment fails. The fix: set up a custom return-path domain in your Mailchimp settings
so SPF aligns with your actual From domain.
The three DMARC policies: none, quarantine, reject
The heart of your DMARC record is the p= tag — the policy. It has three possible values,
and choosing the right one at the right time matters a lot.
| Policy | What it does | Effect on delivery | When to use |
|---|---|---|---|
p=none Monitor |
Collect reports only. No action taken on failing emails. | None — emails deliver as normal regardless of result | Starting out. Always begin here. |
p=quarantine Caution |
Failing emails are sent to the spam/junk folder | Unauthorized emails go to spam. Legitimate emails with correct auth are unaffected. | After confirming your legitimate email passes. Step 2. |
p=reject Full protection |
Failing emails are blocked and never delivered | Unauthorized emails are rejected outright. Maximum protection. | When you're confident all your legitimate senders are passing. Goal state. |
If you skip directly to p=reject before your SPF and DKIM are properly configured,
you could block your own legitimate emails. Always start with p=none, read your reports
for 2–4 weeks, confirm everything is passing, then move to p=quarantine, then p=reject.
Do I actually need DMARC?
Short answer: yes. Here's why, broken into two categories — legal/platform requirements and business protection.
It's now required by Gmail, Yahoo, and Microsoft
DMARC is now essential due to Google and Yahoo requirements for bulk senders.
Since February 2024, any sender sending more than 5,000 emails per day to Gmail addresses must have a DMARC record with at least p=none. Yahoo has the same requirement. Microsoft has also enforced DMARC requirements, and non-compliance has direct consequences for email deliverability, brand trust, and regulatory standing.
Even if you send fewer than 5,000 emails per day, DMARC is still strongly recommended — the thresholds are minimums, not ceilings, and inbox providers use DMARC status as a trust signal for all senders.
It protects your brand from spoofing
DMARC is a standard that prevents spammers from using your domain to send email without your permission — also known as spoofing. Without DMARC, anyone can send an email that appears to come from [email protected] or [email protected]. Your customers see your name and logo. They trust it. And then they get scammed.
HMRC (the UK tax authority) reported that the number of phishing emails sent from their domain decreased by 500 million in just 1.5 years after implementing DMARC. That's the scale of protection a single DNS record provides.
It improves your deliverability
DMARC allows you to see whether emails sent using your domain are properly authenticated using SPF and DKIM — helping you identify and fix authentication issues that affect deliverability. The reports show you exactly which emails are passing, which are failing, and which third-party services are sending as your domain without authorization.
- Any business that sends marketing emails (newsletters, promotions)
- Any business that sends transactional emails (receipts, password resets)
- Any domain you own — even if you don't send email — to prevent it being spoofed
- Anyone using a third-party email service (Mailchimp, SendGrid, HubSpot, etc.)
What happens if you don't have DMARC
Without a DMARC record, three bad things happen simultaneously:
- Your emails are less trusted — inbox providers treat unauthenticated domains as higher risk, increasing spam filtering rates
- Your domain can be spoofed freely — criminals can impersonate you with zero technical barrier, sending phishing emails to your customers
- You're flying blind — without DMARC reports, you have no visibility into who is sending email using your domain or whether your authentication is working
If a criminal sends a fake invoice from "[email protected]" and you don't have DMARC set up, that email might actually land in your customer's inbox. If you do have these protocols in place, that fake email gets blocked before your customer ever sees it.
How to set up DMARC (step by step)
Make sure your SPF and DKIM records are already set up and working before adding DMARC. DMARC validates the results of SPF and DKIM — if those aren't in place first, DMARC has nothing to work with. Check your current SPF and DKIM status here →
Create your DMARC record
Start with a monitoring-only record. Replace the email address with one you actually check:
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Add it to your DNS
Log into wherever your domain is managed (GoDaddy, Namecheap, Cloudflare, Route 53, etc.) and add the record above as a TXT record. Changes typically take effect within 1–24 hours.
Wait 2–4 weeks and read your reports
DMARC aggregate reports (sent to your rua address) will start arriving daily. They show every source sending email from your domain and whether they're passing authentication. The raw XML is hard to read — use a free parser like Postmark's DMARC report parser.
Move to p=quarantine once you're confident
When your reports show all your legitimate email sources are passing, upgrade your policy:
The pct=25 tag means the policy applies to only 25% of failing emails — a safe way to test before full enforcement. Gradually increase it to 100 over a few weeks.
Graduate to p=reject for maximum protection
Once you've been on quarantine for a few weeks with no legitimate email being caught, move to the strongest policy:
Understanding DMARC reports
One of DMARC's underrated features is its reporting. The rua= tag in your record tells providers where to send aggregate reports — daily summaries of every email sent from your domain, including pass/fail results for each source.
These reports are called DMARC Aggregate Reports and are sent to the email address specified in the domain's DMARC record. They're extremely important because they give administrators the information they need to decide how to adjust DMARC policies — for instance, whether legitimate emails are failing SPF and DKIM, or whether a spammer is trying to send unauthorized emails.
Reports arrive as XML files — not exactly a pleasure to read directly. Use a free tool like Postmark's DMARC report inbox or Google's own Postmaster Tools to see the data in a readable format.
Common DMARC mistakes to avoid
- Setting up DMARC before SPF and DKIM are working — DMARC needs both to function properly. Set up SPF and DKIM first, verify they're passing, then add DMARC.
- Jumping straight to p=reject — you risk blocking your own legitimate email. Always start with p=none.
- Using a dead or full inbox for rua= — if your DMARC reports bounce, you lose all visibility. Use a real, monitored email address.
- Forgetting third-party senders — Mailchimp, SendGrid, your helpdesk, your CRM — any service that sends email using your domain needs to be authenticated in your SPF/DKIM before you enforce DMARC.
- Never increasing pct= past your starting point — setting
pct=25is a starting point, not a destination. Work towardspct=100. - Setting two DMARC records — just like SPF, you can only have one DMARC record at
_dmarc.yourdomain.com. Multiple records cause errors.
Check your current DMARC status for free
Enter your domain and see instantly whether your DMARC is missing, in monitor mode, or fully enforcing — with plain-English guidance on what to do next.
→ Check My DMARC NowThe bottom line
DMARC isn't optional in 2026. Gmail and Yahoo require it, Microsoft expects it, and without it your domain is an open invitation for spammers to impersonate your brand. The good news is that setting it up takes less than 10 minutes — and you don't need a sysadmin to do it.
Start with p=none, read your reports, confirm everything is passing, then work your way to p=reject. Once you're there, your emails are more trusted, your brand is protected, and inbox providers have one more reason to deliver your messages — not filter them.