Email Authentication Guide
Everything you need to know about DMARC, SPF, and DKIM. From basics to implementation.
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that helps protect your domain from being used in phishing and spoofing attacks.
Why DMARC matters
- Prevents attackers from sending emails that appear to come from your domain
- Improves email deliverability by building sender reputation
- Provides visibility into who is sending email on your behalf
- Required by major email providers (Google, Microsoft) for bulk senders
DMARC builds on two existing authentication mechanisms: SPF and DKIM. It adds a reporting mechanism and tells receiving mail servers what to do when authentication fails.
Example DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100SPF Explained
SPF (Sender Policy Framework) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain.
How SPF works
- You publish an SPF record in your DNS
- When someone receives an email from your domain, their server checks your SPF record
- If the sending server's IP is listed, the email passes SPF
- If not listed, the email fails SPF authentication
Example SPF record:
v=spf1 include:_spf.google.com include:sendgrid.net -allSPF mechanisms
include:
Reference another domain's SPF record
ip4: / ip6:
Authorize specific IP addresses
a / mx
Authorize your A or MX record IPs
-all / ~all
What to do with non-matching senders
Important: 10-lookup limit
SPF has a strict limit of 10 DNS lookups. Each include:, a, mx, ptr, and exists: mechanism counts as one lookup. Exceeding this limit causes SPF to fail.
DKIM Explained
DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. Recipients can verify this signature to confirm the email hasn't been altered and truly came from your domain.
How DKIM works
- Your email server signs outgoing messages with a private key
- You publish the corresponding public key in DNS
- Recipients fetch your public key and verify the signature
- If the signature matches, DKIM passes
Example DKIM record (selector1._domainkey.example.com):
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...DKIM components
Selector
A name that identifies which key to use (e.g., "google", "selector1"). Allows key rotation without breaking existing emails.
Key length
2048-bit keys are recommended. 1024-bit keys are still common but considered less secure.
Signature header
Added to each outgoing email, contains the cryptographic signature.
How They Work Together
DMARC uses SPF and DKIM results to make a final authentication decision. For an email to pass DMARC, it must pass either SPF or DKIM and be aligned with the domain in the "From" header.
DMARC alignment
"Alignment" means the domain in the authentication check matches the domain in the visible "From" header.
SPF alignment
The domain in the "Return-Path" matches the "From" domain
DKIM alignment
The domain in the DKIM signature (d=) matches the "From" domain
| Scenario | DMARC Result |
|---|---|
| SPF pass + aligned | Pass |
| DKIM pass + aligned | Pass |
| SPF pass but not aligned, DKIM pass + aligned | Pass |
| SPF pass but not aligned, DKIM fail | Fail |
| Both SPF and DKIM fail | Fail |
DMARC Policies
The DMARC policy (p=) tells receiving servers what to do when an email fails authentication.
Monitor only
Emails are delivered normally regardless of authentication result. Use this to gather data before enforcing. Reports are still sent.
Quarantine
Failing emails should be treated with suspicion. Usually delivered to spam/junk folder. Good intermediate step.
Reject
Failing emails should be rejected outright. Maximum protection. Only use after confirming all legitimate senders are authenticated.
Recommended approach
Start with p=none, monitor reports for 2-4 weeks, fix any issues, then gradually move to p=quarantine and finally p=reject.
Implementation Guide
Audit your current senders
Before implementing DMARC, identify all services sending email on your behalf:
- - Your mail server (Microsoft 365, Google Workspace, etc.)
- - Marketing tools (Mailchimp, HubSpot, Sendgrid, etc.)
- - Transactional email (your application, CRM, helpdesk)
- - Third-party services (invoicing, HR systems, etc.)
Set up SPF
Add a TXT record at your domain root with all authorized senders:
v=spf1 include:_spf.google.com include:sendgrid.net -allSet up DKIM
Enable DKIM signing in each service that sends email. Each service will give you a DNS record to add. Example for Google Workspace:
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGf..."Add DMARC record
Add a TXT record at _dmarc.yourdomain.com. Start with p=none to collect data:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100Monitor and fix
Review DMARC reports to identify authentication failures. Fix SPF and DKIM issues for each sender. Once all legitimate mail passes, move to p=quarantine, then p=reject.
Common Mistakes
Exceeding SPF lookup limit
SPF allows only 10 DNS lookups. Adding too many includes will cause SPF to fail for all emails. Use IP addresses directly or SPF flattening services if needed.
Jumping to p=reject too quickly
Implementing reject policy before fixing all senders will cause legitimate email to be blocked. Always start with p=none and monitor for at least 2 weeks.
Forgetting third-party senders
Marketing platforms, CRMs, and other services often send email on your behalf. Each one needs proper SPF and DKIM configuration.
Not monitoring reports
DMARC reports are essential for understanding your email ecosystem. Without monitoring, you won't know when something breaks or when attackers try to spoof your domain.
Using weak DKIM keys
1024-bit DKIM keys are technically valid but considered weak. Use 2048-bit keys when possible for better security.
Glossary
Ready to secure your email?
Check your domain's current status with our free tool, or start monitoring with Blankitt DMARC.