What is DMARC?
Definition
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that protects your domain from unauthorized use. It tells receiving mail servers how to handle emails that fail authentication checks, helping prevent phishing attacks and email spoofing that could damage your brand.
Think of DMARC as a security policy you publish to the world. When someone tries to send an email pretending to be from your domain, DMARC gives receiving servers clear instructions: let it through, quarantine it, or reject it outright.
How DMARC works
DMARC builds on two existing authentication methods: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). For an email to pass DMARC, it must pass at least one of these checks and align with your domain.
Here's the authentication flow:
- You publish a DMARC record in your domain's DNS settings
- Someone sends an email claiming to be from your domain
- The receiving server checks SPF and DKIM authentication
- If the email fails both checks, the server follows your DMARC policy
- You receive reports showing who's sending email using your domain
The "alignment" piece matters. Even if an email passes SPF or DKIM, DMARC requires the authenticated domain to match the "From" address that recipients see. This closes a loophole that attackers previously exploited.
Why DMARC matters for email deliverability
Google and Yahoo now require DMARC for anyone sending more than 5,000 emails daily. Without it, your messages may land in spam or get rejected entirely.
Beyond meeting requirements, DMARC directly improves your sender reputation. When inbox providers see you've implemented authentication, they trust your emails more. Your legitimate messages reach inboxes while fraudulent ones get blocked.
DMARC also protects your customers. If attackers can't spoof your domain, they can't trick your audience into clicking malicious links or sharing sensitive information. That protection builds trust in every email you send.
For a deeper look at authentication requirements, see our guide to Google and Yahoo authentication changes.
Understanding DMARC policies
Your DMARC record includes a policy tag (p=) that tells receiving servers what to do with failing emails. You have three options:
p=none monitors without taking action. Emails still get delivered, but you receive reports showing authentication results. Start here to understand your email ecosystem before enforcing stricter rules.
p=quarantine sends failing emails to spam folders. Recipients can still find them, but they're flagged as suspicious. This middle ground catches threats while giving legitimate emails a safety net.
p=reject blocks failing emails completely. They never reach the recipient. This offers maximum protection but requires confidence that all your legitimate sending sources are properly authenticated.
Most organizations should progress through these policies over time. Jumping straight to reject can block legitimate emails from third-party services you've authorized to send on your behalf.
What a DMARC record looks like
A DMARC record is a DNS TXT entry published at _dmarc.yourdomain.com. Here's an example:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100
Breaking down each component:
- v=DMARC1 identifies this as a DMARC record
- p=quarantine sets your policy for failing emails
- rua=mailto: specifies where to send aggregate reports
- pct=100 applies the policy to all failing emails (you can start lower during testing)
Optional tags let you fine-tune your setup. The adkim and aspf tags control alignment strictness. The sp tag sets a separate policy for subdomains. The ruf tag requests detailed forensic reports for individual failures.
How to implement DMARC
Before creating your DMARC record, ensure you have SPF and DKIM configured. Use ActiveCampaign's DKIM and SPF checker to verify your current setup.
Step 1: Audit your sending sources. List every service that sends email from your domain, including your email platform, CRM, support desk, transactional email provider, and any other tools. Each needs proper authentication.
Step 2: Start with monitoring. Publish a DMARC record with p=none. This won't affect delivery but will generate reports showing all email activity from your domain.
Step 3: Analyze your reports. DMARC aggregate reports arrive as XML files. They reveal which IP addresses send email using your domain and whether those emails pass authentication. Look for legitimate services that need SPF or DKIM fixes.
Step 4: Fix authentication gaps. Update SPF records to include all authorized senders, and configure DKIM signing for services that support it. This process often takes several weeks as you discover forgotten sending sources.
Step 5: Gradually enforce. Once reports show consistent authentication passes, move to p=quarantine. Monitor for delivery issues, and when confident, advance to p=reject for full protection.
Common DMARC mistakes to avoid
Rushing to a reject policy causes the most problems. Organizations often forget about legacy systems, marketing tools, or partner integrations that send email on their behalf. Those legitimate emails get blocked, creating business disruptions.
Ignoring DMARC reports wastes the protocol's visibility benefits. The reports tell you exactly what's happening with your domain, so review them regularly, especially after changing email infrastructure.
Overlooking subdomains leaves security gaps. Attackers can spoof subdomains you've never used, so set an explicit subdomain policy (sp=reject) or ensure your main policy covers them.
Using overly permissive SPF records undermines DMARC's protection. If your SPF includes broad IP ranges or too many third-party services, attackers may find authorized infrastructure to exploit.
Ready to strengthen your email authentication? Check your current DKIM and SPF setup to see where you stand.
DMARC, SPF, and DKIM: how they work together
These three protocols form a complete authentication system, with each handling a different piece of the puzzle.
SPF verifies the sending server. It checks whether the IP address sending your email is authorized in your DNS records. SPF alone can't verify the "From" address recipients see.
DKIM verifies message integrity. It attaches a cryptographic signature proving the email hasn't been altered since leaving your server. DKIM alone doesn't tell receivers what to do with unsigned messages.
DMARC ties everything together. It requires alignment between authentication results and the visible "From" address, then provides clear instructions for handling failures. Without DMARC, SPF and DKIM results go unused.
For reliable email deliverability, you need all three working in harmony.
FAQs
Do I need DMARC if I only send a few hundred emails?
Yes. While Google and Yahoo's strict requirements target high-volume senders, DMARC protects your domain regardless of volume. Attackers don't care how many emails you send; they'll spoof any unprotected domain.
How long does DMARC take to implement?
Publishing a basic monitoring record takes minutes. Full implementation with a reject policy typically takes 2-3 months, with most of that time spent discovering all legitimate sending sources and fixing authentication issues.
Will DMARC stop all phishing attacks?
No. DMARC prevents exact domain spoofing, but attackers can still use lookalike domains (like "yourdoma1n.com") or compromise legitimate accounts. DMARC is one layer in a comprehensive security approach.
What happens to emails that fail DMARC?
That depends on your policy. With p=none, nothing changes. With p=quarantine, they go to spam. With p=reject, they're blocked entirely. Receiving servers may also apply their own judgment based on other signals.
Can DMARC affect my legitimate email delivery?
Only if you enforce a policy before properly authenticating all your sending sources. Start with monitoring, fix issues revealed in reports, then gradually increase enforcement.
Want to ensure your emails reach the inbox? Start your free ActiveCampaign trial.
