Email Security Best Practices: SPF, DKIM, and DMARC Explained
Email authentication protocols protect your business from spoofing and phishing. Learn how SPF, DKIM, and DMARC work and why they're essential for email security.
Why Email Authentication Matters
Email's fundamental design flaw is that anyone can claim to send from any address. Without authentication, attackers easily impersonate your business to scam customers, vendors, or employees. Three email authentication protocols—SPF, DKIM, and DMARC—work together to prove that emails claiming to be from your domain are actually legitimate.
Beyond security, these protocols improve email deliverability. Major email providers increasingly reject or filter unauthenticated emails, meaning messages from your business may never reach recipients without proper authentication.
The Three Pillars of Email Authentication
Think of email authentication like verifying someone's identity with multiple forms of ID:
- SPF (Sender Policy Framework): Verifies the sender's IP address against an approved list
- DKIM (DomainKeys Identified Mail): Provides a cryptographic signature proving the email wasn't modified
- DMARC (Domain-based Message Authentication, Reporting and Conformance): Tells receiving servers what to do if SPF or DKIM checks fail, and provides reporting
All three work together to provide comprehensive email authentication.
SPF: Sender Policy Framework
What SPF Does
SPF allows you to publish a list of IP addresses and servers authorized to send email on behalf of your domain. When someone receives an email claiming to be from your domain, their email server checks whether it came from an approved source.
How SPF Works
- You publish an SPF record in your domain's DNS
- The SPF record lists all servers/IPs authorized to send email for your domain
- When receiving servers get email from your domain, they check the sender's IP against your SPF record
- Emails from unauthorized IPs can be rejected or flagged as suspicious
Creating an SPF Record
An SPF record is a TXT record in your DNS that looks like this:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
Breaking this down:
v=spf1: This is an SPF version 1 recordinclude:_spf.google.com: Authorizes Google Workspace to send email for your domaininclude:spf.protection.outlook.com: Authorizes Microsoft 365 to send email-all: Reject emails from any other source (alternative:~allfor soft fail)
Common SPF Mechanisms
ip4:192.0.2.0/24: Authorize a specific IP address or rangeinclude:domain.com: Include another domain's SPF policya: Authorize the domain's A record IPmx: Authorize IPs of the domain's MX records
SPF Best Practices
Be Comprehensive: Include all legitimate email sources:
- Email service provider (Google, Microsoft, etc.)
- Marketing platforms (Mailchimp, Constant Contact, etc.)
- CRM systems (Salesforce, HubSpot, etc.)
- Ticketing systems (Zendesk, Freshdesk, etc.)
- Any other service that sends email as your domain
Don't Exceed DNS Lookup Limits: SPF has a 10 DNS lookup limit. Too many include: statements can break your SPF record.
Use -all for Strict Policy: The -all mechanism tells receiving servers to reject emails from unauthorized sources. Use ~all (soft fail) only during initial testing.
Monitor and Update: When adding new email services, update your SPF record immediately.
Testing Your SPF Record
Use online tools to validate:
- MXToolbox SPF Checker
- dmarcian SPF Inspector
- Google Admin Toolbox Messageheader
DKIM: DomainKeys Identified Mail
What DKIM Does
DKIM adds a digital signature to every email sent from your domain. This signature proves:
- The email actually came from your domain
- The message wasn't altered in transit
How DKIM Works
- Your email server generates a public/private key pair
- The private key signs outgoing emails
- The public key is published in your DNS
- Receiving servers use the public key to verify the signature
- If the signature matches, the email is authentic and unmodified
Setting Up DKIM
DKIM setup is typically handled by your email provider:
Google Workspace:
- Generate DKIM key in Google Admin Console
- Add provided TXT record to your DNS
- Enable DKIM signing in Google Admin
Microsoft 365:
- Enable DKIM signing in Microsoft 365 Admin Center
- Copy provided CNAME records
- Add CNAME records to your DNS
Other Providers: Follow provider-specific instructions for key generation and DNS record creation.
DKIM Record Example
A DKIM DNS record looks like:
default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
Where:
default._domainkey: The selector (can be customized)v=DKIM1: DKIM versionk=rsa: Key type (RSA)p=...: The public key
DKIM Best Practices
Use 2048-bit Keys: Provides strong cryptographic protection (1024-bit is becoming deprecated)
Rotate Keys Periodically: Change DKIM keys annually for security
Use Multiple Selectors: Different keys for different mail streams enable granular troubleshooting
Sign All Outgoing Email: Ensure DKIM signing is enabled for all email types
Testing DKIM
Send test emails to:
- Gmail account (check original message headers)
- Mail-tester.com
- DKIM validator tools
Look for DKIM=PASS in authentication results.
DMARC: Bringing It All Together
What DMARC Does
DMARC builds on SPF and DKIM to:
- Specify what receiving servers should do with emails that fail authentication
- Provide reports showing who's sending email using your domain
- Prevent domain spoofing in phishing attacks
How DMARC Works
- You publish a DMARC policy in your DNS
- The policy specifies actions for failed authentication (none, quarantine, reject)
- Receiving servers check SPF and DKIM
- If checks fail, they follow your DMARC policy
- Receiving servers send reports about email authentication results
Creating a DMARC Record
A DMARC record is a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; aspf=s; adkim=s
Breaking this down:
v=DMARC1: DMARC versionp=reject: Policy for failed authentication (none, quarantine, reject)pct=100: Percentage of emails to apply policy to (100%)rua=mailto:...: Address for aggregate reportsruf=mailto:...: Address for forensic reportsaspf=s: Strict SPF alignmentadkim=s: Strict DKIM alignment
DMARC Policies Explained
p=none (Monitor Only)
- No action taken on failed emails
- Use during initial setup to monitor impact
- Still receive reports to identify issues
p=quarantine
- Failed emails sent to spam/junk folder
- Intermediate policy during rollout
- Balances security with deliverability risk
p=reject
- Failed emails completely rejected
- Strongest protection against spoofing
- Final goal for mature DMARC implementation
DMARC Alignment
DMARC requires "alignment" between authenticated domain and "From" address:
Relaxed Alignment: Subdomains match (default)
- Email from
news.example.compasses forexample.comdomain
Strict Alignment: Exact match required
- Only
example.compasses forexample.com - More secure but requires careful configuration
DMARC Reports
DMARC generates two types of reports:
Aggregate Reports (RUA)
- Daily XML reports summarizing authentication results
- Show all sources sending email as your domain
- Help identify legitimate services needing SPF/DKIM setup
- Identify spoofing attempts
Forensic Reports (RUF)
- Real-time reports of individual authentication failures
- Include email headers and sometimes content
- Privacy concerns limit adoption
- Useful for troubleshooting specific issues
Processing DMARC Reports
Raw XML reports are difficult to read. Use services to parse and visualize:
- Free Options: Postmark DMARC Digests, dmarcian (limited free tier)
- Paid Services: dmarcian, Valimail, Agari
- Self-Hosted: parsedmarc (open-source reporting tool)
Implementation Roadmap
Phase 1: SPF Setup (Week 1)
- Inventory email sources: List all services sending email as your domain
- Create SPF record: Include all authorized sources
- Publish to DNS: Add TXT record to your domain
- Verify: Use SPF checking tools to confirm proper configuration
- Monitor: Watch for delivery issues, update as needed
Phase 2: DKIM Setup (Week 2)
- Enable DKIM in your email provider
- Generate keys: Create 2048-bit keys if not automatic
- Publish public key: Add provided DNS records
- Enable signing: Activate DKIM signing for outbound email
- Test: Send emails and verify DKIM signatures pass
- Enable for all services: Configure DKIM for marketing platforms, etc.
Phase 3: DMARC Monitoring (Weeks 3-6)
- Start with p=none: Monitor without impacting delivery
- Set up report processing: Use a DMARC report analyzer
- Publish DMARC record: Add to DNS with p=none policy
- Collect reports: Wait 1-2 weeks for report accumulation
- Analyze results: Identify all legitimate mail sources
- Fix failures: Update SPF/DKIM for failing legitimate sources
Phase 4: DMARC Enforcement (Weeks 7-12)
- Move to p=quarantine: Start with pct=10-25%
- Monitor impact: Watch for delivery issues
- Gradually increase: Raise percentage as confidence grows
- Reach p=quarantine at 100%: Maintain for 2-4 weeks
- Move to p=reject: Final enforcement policy
- Ongoing monitoring: Continue watching reports
Troubleshooting Common Issues
Email Delivery Problems After SPF Implementation
Symptom: Legitimate emails being rejected
Solutions:
- Check SPF record includes all email sources
- Verify DNS propagation (can take 24-48 hours)
- Look for SPF syntax errors
- Check for DNS lookup limit violations (10 max)
DKIM Signature Failures
Symptom: DKIM verification failing
Solutions:
- Verify DNS record published correctly
- Check for whitespace in DNS TXT record
- Ensure key length matches (2048-bit)
- Confirm DKIM signing enabled in email provider
- Check if email was forwarded (breaks DKIM)
DMARC Report Overload
Symptom: Too many reports to process manually
Solutions:
- Use DMARC report processing services
- Set up automated report parsing
- Focus on aggregate reports, not forensic
- Filter reports for new sources only
Subdomain Spoofing
Symptom: Attackers using subdomains not explicitly protected
Solutions:
- Add DMARC record to
_dmarcof each subdomain, or - Use
sp=rejectin parent domain DMARC to apply policy to subdomains
Advanced Considerations
BIMI: Brand Indicators for Message Identification
BIMI displays your company logo next to authenticated emails in supporting email clients:
Requirements:
- DMARC policy at p=quarantine or p=reject
- Verified Mark Certificate (VMC) from authorized provider
- Published BIMI DNS record
Benefits:
- Brand visibility in inbox
- Visual authentication for recipients
- Phishing protection through brand recognition
Email Forwarding Challenges
Email forwarding can break SPF and DKIM:
SPF: Forwarded email comes from forwarding server (unauthorized IP) DKIM: Some forwards modify content, breaking signature
Solutions:
- ARC (Authenticated Received Chain) for forwarders
- Use relaxed DMARC alignment
- Consider p=quarantine instead of p=reject if forwarding is common
Third-Party Senders
Marketing platforms and other services sending on your behalf need special handling:
Option 1: Subdomain delegation
- Use
marketing.yourdomain.comfor third-party sending - Separate DMARC policy for subdomain
Option 2: Include in SPF/DKIM
- Add third-party IPs to SPF
- Configure DKIM with third-party
Monitoring and Maintenance
Monthly Tasks
- Review DMARC reports for new sources
- Check DMARC compliance percentage
- Verify SPF/DKIM still passing
Quarterly Tasks
- Audit all authorized email sources
- Review and remove unused services from SPF
- Check for email delivery issues
Annual Tasks
- Rotate DKIM keys
- Comprehensive email security audit
- Review DMARC policy enforcement level
The Bottom Line
SPF, DKIM, and DMARC form the foundation of email security. These protocols:
- Prevent attackers from spoofing your domain in phishing attacks
- Improve email deliverability to customers and partners
- Provide visibility into who's sending email as your domain
- Demonstrate security maturity to partners and clients
Implementation requires initial effort but minimal ongoing maintenance. The protection against domain spoofing and improved email deliverability provide immediate value that far exceeds the setup cost.
Every business sending email should implement these protocols. Your domain's reputation and your customers' security depend on it.
Need help implementing SPF, DKIM, and DMARC for your domain? Get expert guidance from SimplCyber with step-by-step implementation support.