Email Authentication¶
Understanding how SPF, DKIM, and DMARC work together to secure email.
Overview¶
Email authentication is a collection of techniques designed to prove that emails are genuinely from who they claim to be. It protects against:
- Phishing - Fraudulent emails impersonating trusted senders
- Spoofing - Forging sender addresses
- Spam - Unsolicited bulk email
- Business Email Compromise (BEC) - Impersonating executives or vendors
The three core protocols - SPF, DKIM, and DMARC - work together to provide comprehensive email security.
The Email Security Triad¶
graph TB
A[Email Authentication] --> B[SPF]
A --> C[DKIM]
A --> D[DMARC]
B --> E[Validates<br/>Sending Server]
C --> F[Validates<br/>Message Integrity]
D --> G[Enforces Policy &<br/>Provides Reports]
E --> H[Complete<br/>Email Security]
F --> H
G --> H
SPF (Sender Policy Framework)¶
What it does: Verifies the sending mail server is authorized
How it works: DNS TXT record lists authorized IP addresses
Example:
Learn more: SPF Deep Dive
DKIM (DomainKeys Identified Mail)¶
What it does: Cryptographically signs emails to prove authenticity
How it works: Private key signs email, public key in DNS verifies signature
Example:
Learn more: DKIM Deep Dive
DMARC (Domain-based Message Authentication, Reporting & Conformance)¶
What it does: Enforces SPF/DKIM policies and provides reporting
How it works: DNS TXT record tells receivers what to do with failed authentication
Example:
Learn more: DMARC Deep Dive
How They Work Together¶
The Complete Authentication Flow¶
sequenceDiagram
participant Sender as Sending Server
participant DNS as DNS Servers
participant Receiver as Receiving Server
participant User as End User
Note over Sender: 1. Email Preparation
Sender->>Sender: Create email
Sender->>Sender: Sign with DKIM<br/>(private key)
Note over Sender,Receiver: 2. Email Transmission
Sender->>Receiver: Send email via SMTP
Note over Sender,Receiver: From: user@example.com
Note over Receiver,DNS: 3. SPF Verification
Receiver->>DNS: Query SPF record<br/>example.com TXT
DNS->>Receiver: v=spf1 ip4:192.0.2.1 -all
Receiver->>Receiver: Check sender IP<br/>192.0.2.1 matches? ✓ SPF PASS
Note over Receiver,DNS: 4. DKIM Verification
Receiver->>DNS: Query DKIM key<br/>selector._domainkey.example.com
DNS->>Receiver: v=DKIM1; k=rsa; p=PUBLIC_KEY
Receiver->>Receiver: Verify signature<br/>with public key ✓ DKIM PASS
Note over Receiver,DNS: 5. DMARC Policy Check
Receiver->>DNS: Query DMARC policy<br/>_dmarc.example.com
DNS->>Receiver: v=DMARC1; p=reject
Receiver->>Receiver: Check alignment:<br/>SPF domain = From domain ✓<br/>DKIM domain = From domain ✓<br/>✓ DMARC PASS
Note over Receiver,User: 6. Delivery Decision
Receiver->>User: Deliver to inbox
Note over Receiver,Sender: 7. Reporting
Receiver->>Sender: Send DMARC report<br/>(aggregate/forensic)
Authentication Decision Tree¶
graph TD
A[Email Arrives] --> B{SPF Check}
B -->|Pass| C{SPF Aligned?}
B -->|Fail| D{DKIM Check}
C -->|Yes| E[SPF Aligned ✓]
C -->|No| D
D -->|Pass| F{DKIM Aligned?}
D -->|Fail| G[Both Failed]
F -->|Yes| H[DKIM Aligned ✓]
F -->|No| G
E --> I{DMARC Policy}
H --> I
G --> I
I -->|Pass + p=any| J[Deliver to Inbox]
I -->|Fail + p=none| K[Deliver + Report]
I -->|Fail + p=quarantine| L[Send to Spam]
I -->|Fail + p=reject| M[Reject Email]
Why All Three Are Needed¶
SPF Alone is Not Enough¶
Problem 1: No integrity checking
Attacker modifies email subject/body in transit
SPF: PASS (came from authorized server)
Result: Tampered email delivered ❌
Problem 2: Envelope vs Header mismatch
MAIL FROM: legitimate@example.com (SPF checks this)
From: attacker@evil.com (User sees this)
Result: SPF passes but user sees fake sender ❌
Problem 3: No policy enforcement
SPF: FAIL
Receiver: "SPF failed, but what should I do?" 🤷
Result: Inconsistent handling across receivers
DKIM Alone is Not Enough¶
Problem 1: Domain mismatch allowed
From: victim@example.com
DKIM d=: attacker.com (signs with own domain)
Result: DKIM passes but domains don't match ❌
Problem 2: No sending server validation
Email comes from unauthorized server
DKIM: PASS (signature valid)
Result: Phishing email with valid signature ❌
Problem 3: No policy guidance
DMARC Ties It All Together¶
Solution 1: Alignment requirement
From: user@example.com
SPF domain: example.com ✓ Aligned
DKIM d=: example.com ✓ Aligned
Result: Both must match From header
Solution 2: Policy enforcement
Solution 3: Visibility
DMARC aggregate reports show:
- Who's sending email for your domain
- Authentication pass/fail rates
- Which receivers are applying policy
Result: Complete visibility ✓
Real-World Scenarios¶
Scenario 1: Legitimate Email (All Pass)¶
Email Details:
From: support@example.com
MAIL FROM: bounce@mail.example.com
Sending IP: 192.0.2.1
DNS Configuration:
SPF: v=spf1 ip4:192.0.2.0/24 -all
DKIM: selector._domainkey.example.com (2048-bit key)
DMARC: v=DMARC1; p=reject
Authentication Results:
✓ SPF PASS (IP matches)
✓ SPF Aligned (mail.example.com → example.com)
✓ DKIM PASS (signature valid)
✓ DKIM Aligned (d=example.com)
✓ DMARC PASS
Action: Deliver to inbox
Scenario 2: Phishing Attempt (All Fail)¶
Email Details:
From: ceo@yourcompany.com (spoofed)
MAIL FROM: attacker@evil.com
Sending IP: 203.0.113.1 (attacker's server)
DNS Configuration (yourcompany.com):
SPF: v=spf1 include:_spf.google.com -all
DKIM: google._domainkey.yourcompany.com
DMARC: v=DMARC1; p=reject
Authentication Results:
✗ SPF FAIL (IP not authorized)
✗ SPF NOT Aligned (evil.com ≠ yourcompany.com)
✗ DKIM FAIL (no signature or invalid)
✗ DMARC FAIL
Action: Reject email (p=reject)
Report: Send aggregate report to yourcompany.com
Scenario 3: Mailing List (Forwarding Challenge)¶
Original Email:
From: user@example.com
MAIL FROM: user@example.com
Sending IP: 192.0.2.1
After Mailing List Forward:
From: user@example.com (unchanged)
MAIL FROM: list@mailinglist.com (changed by list)
Sending IP: 198.51.100.1 (mailing list server)
Subject: [List] Original subject (modified)
Authentication Results:
✗ SPF FAIL (new IP not in example.com SPF)
✗ SPF NOT Aligned (list domain ≠ example.com)
✓ DKIM PASS (signature survives if body not modified)
✓ DKIM Aligned (d=example.com)
✓ DMARC PASS (DKIM alignment sufficient!)
Action: Deliver to inbox
Note: DKIM saves forwarded emails
Scenario 4: Legitimate Third-Party Service¶
Email Details:
From: newsletter@company.com
MAIL FROM: bounce@sendgrid.net
Sending IP: 198.51.100.1 (SendGrid)
DKIM: d=company.com (SendGrid signs with customer domain)
DNS Configuration (company.com):
SPF: v=spf1 include:_spf.google.com include:sendgrid.net -all
DKIM: em123._domainkey.company.com (SendGrid key)
DMARC: v=DMARC1; p=quarantine
Authentication Results:
✓ SPF PASS (SendGrid in SPF include)
✗ SPF NOT Aligned (sendgrid.net ≠ company.com)
✓ DKIM PASS (valid SendGrid signature)
✓ DKIM Aligned (d=company.com)
✓ DMARC PASS (DKIM alignment sufficient)
Action: Deliver to inbox
Alignment: The Key Concept¶
Alignment is what makes DMARC powerful - it ensures the authenticated domain matches what users see.
Why Alignment Matters¶
Without alignment:
From: victim@bank.com (what user sees)
SPF domain: attacker.com (passes SPF)
DKIM domain: attacker.com (passes DKIM)
Problem: Authentication passes but domains don't match!
With alignment:
From: victim@bank.com
SPF domain: must be bank.com or *.bank.com
DKIM domain: must be bank.com or *.bank.com
Result: At least one must align with From header
Relaxed vs Strict Alignment¶
Relaxed Alignment (Default)¶
Organizational domains match:
From: user@example.com
SPF: mail.example.com → ✓ Aligned
DKIM d=: email.example.com → ✓ Aligned
Rule: example.com = example.com (base domain matches)
Configuration:
Strict Alignment¶
Exact domains match:
From: user@example.com
SPF: mail.example.com → ✗ NOT Aligned
DKIM d=: example.com → ✓ Aligned
Rule: example.com ≠ mail.example.com (exact match required)
Configuration:
Recommendation: Use relaxed (default) for better compatibility with email services.
Progressive Implementation Strategy¶
Phase 1: Foundation (Week 1-2)¶
Goal: Establish basic authentication
Steps: 1. Configure SPF
-
Generate and publish DKIM keys
-
Add DMARC in monitoring mode
-
Validate with ReputeAPI
Expected score: 55-65 (Fair)
Phase 2: Monitoring (Week 3-4)¶
Goal: Gather data and identify issues
Steps: 1. Review DMARC aggregate reports - Identify all legitimate sending sources - Check authentication pass rates - Look for unauthorized senders
- Fix any issues found
- Add missing IPs to SPF
- Configure DKIM for all services
-
Update third-party service settings
-
Achieve 100% pass rate
- All legitimate email passes SPF or DKIM
- No false positives
Expected score: Still 55-65 (p=none gives no enforcement points)
Phase 3: Enforcement - Quarantine (Week 5-6)¶
Goal: Begin policy enforcement safely
Steps: 1. Upgrade to quarantine policy
- Monitor for issues
- Check spam folders for legitimate email
- Review user complaints
-
Monitor DMARC reports
-
Adjust if needed
- Add missed sources to SPF
- Fix DKIM signatures
- Temporary rollback if critical issues
Expected score: 70-80 (Good)
Phase 4: Maximum Protection (Week 7+)¶
Goal: Achieve full protection
Steps: 1. Upgrade to reject policy
-
Optional: Gradual rollout
-
Continuous monitoring
- Weekly report review
- Monthly configuration audit
- Investigate all failures
Expected score: 90-100 (Excellent)
Email Authentication for Different Use Cases¶
Small Business (Google Workspace)¶
Configuration:
# SPF
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
# DKIM (configured in Google Admin Console)
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=KEY..."
# DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Timeline: 2-3 weeks to full deployment
Enterprise (Multiple Email Services)¶
Configuration:
# SPF - Multiple providers
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com -all"
# DKIM - Multiple selectors
google._domainkey.example.com. IN TXT "v=DKIM1; p=KEY1..."
em123._domainkey.example.com. IN TXT "v=DKIM1; p=KEY2..."
salesforce._domainkey.example.com. IN TXT "v=DKIM1; p=KEY3..."
# DMARC - Comprehensive reporting
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:reports@dmarcanalyzer.com; ruf=mailto:forensic@example.com"
Timeline: 6-8 weeks with extensive testing
E-commerce (High Volume Transactional)¶
Configuration:
# SPF - Transactional ESP
example.com. IN TXT "v=spf1 include:sendgrid.net -all"
# DKIM - Dedicated selector
transactions._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=KEY..."
# DMARC - Strict policy
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; adkim=s; rua=mailto:dmarc@example.com"
# Subdomain for marketing
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
Timeline: 4-6 weeks with phased rollout
No Email Sent (Domain Parking)¶
Configuration:
# SPF - Reject all
example.com. IN TXT "v=spf1 -all"
# DMARC - Reject policy
_dmarc.example.com. IN TXT "v=DMARC1; p=reject"
Timeline: Immediate deployment
Common Challenges and Solutions¶
Challenge 1: Email Forwarding¶
Problem: Forwarded emails fail SPF alignment
Solution: - Use DKIM (survives forwarding better) - Implement ARC (Authenticated Received Chain) - Use relaxed alignment (default)
Example:
Challenge 2: Mailing Lists¶
Problem: Lists modify emails, breaking signatures
Solution: - Configure list to preserve DKIM - List adds its own DKIM signature - ARC support preserves original authentication
Best practice:
List should:
1. Not modify From header
2. Add own DKIM signature
3. Support ARC
4. Use VERP for bounces
Challenge 3: Third-Party Services¶
Problem: Marketing/transactional email services need authentication
Solution:
- Add to SPF with include:
- Delegate DKIM to service
- Verify alignment regularly
Example (SendGrid):
# SPF
example.com. IN TXT "v=spf1 include:sendgrid.net -all"
# DKIM (provided by SendGrid)
em123._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=KEY..."
# DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=reject"
Challenge 4: SPF 10 Lookup Limit¶
Problem: Too many includes exceed DNS lookup limit
Solution: - Use IP addresses instead of includes - SPF flattening service - Separate subdomains for different services
Example:
# Instead of many includes
v=spf1 include:provider1 include:provider2 include:provider3 -all
# Use IP ranges
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 -all
# Or subdomains
marketing.example.com. → separate SPF
transactional.example.com. → separate SPF
Challenge 5: Multiple Domains¶
Problem: Managing authentication for many domains
Solution: - Infrastructure as Code (Terraform) - Centralized monitoring - Automated testing
Example Terraform:
# domains.tf
locals {
domains = ["example1.com", "example2.com", "example3.com"]
}
resource "cloudflare_record" "spf" {
for_each = toset(local.domains)
zone_id = var.zone_ids[each.key]
name = "@"
type = "TXT"
value = "v=spf1 include:_spf.google.com -all"
}
Monitoring and Maintenance¶
Daily Monitoring¶
Automated checks:
import requests
def daily_check(domain):
"""Daily email security check"""
response = requests.get(
f"https://api.reputeapi.com/api/v1/check",
params={"domain": domain, "refresh": True},
headers={"X-API-Key": "your-api-key"}
)
result = response.json()
# Alert on score drop
if result['score'] < 90:
send_alert(f"Email security score: {result['score']}")
# Alert on critical issues
critical = [i for i in result['issues'] if i['severity'] == 'critical']
if critical:
send_alert(f"Critical issues: {critical}")
Weekly Tasks¶
- [ ] Review DMARC aggregate reports
- [ ] Check for new unauthorized senders
- [ ] Verify authentication pass rates
- [ ] Investigate failures
Monthly Tasks¶
- [ ] Audit complete configuration
- [ ] Review SPF includes for changes
- [ ] Test DKIM signatures
- [ ] Update documentation
Quarterly Tasks¶
- [ ] Rotate DKIM keys (if policy requires)
- [ ] Security audit
- [ ] Compliance review
- [ ] Update disaster recovery plan
Testing Your Configuration¶
Comprehensive Test¶
#!/bin/bash
DOMAIN="example.com"
API_KEY="your-api-key"
echo "==================================="
echo "Email Authentication Test"
echo "Domain: $DOMAIN"
echo "==================================="
# 1. ReputeAPI validation
echo -e "\n1. Running ReputeAPI check..."
curl -s "https://api.reputeapi.com/api/v1/check?domain=$DOMAIN" \
-H "X-API-Key: $API_KEY" | jq '{score, spf, dkim, dmarc, issues}'
# 2. DNS queries
echo -e "\n2. Checking DNS records..."
echo "SPF:"
dig +short $DOMAIN TXT | grep spf
echo -e "\nDKIM (google selector):"
dig +short google._domainkey.$DOMAIN TXT
echo -e "\nDMARC:"
dig +short _dmarc.$DOMAIN TXT
# 3. Send test email
echo -e "\n3. Send test email to: test@mail-tester.com"
echo "Then check score at: https://www.mail-tester.com"
echo -e "\n==================================="
echo "Test complete!"
Validation Checklist¶
SPF Validation¶
- [ ] Record exists at root domain
- [ ] Only ONE SPF record
- [ ] All sending sources included
- [ ] Ends with
-all(hard fail) - [ ] Less than 10 DNS lookups
- [ ] No syntax errors
DKIM Validation¶
- [ ] Keys published for all selectors
- [ ] Key size ≥ 2048 bits
- [ ] Mail server signing emails
- [ ] Signatures include From header
- [ ] Public key matches private key
- [ ] No syntax errors
DMARC Validation¶
- [ ] Record exists at _dmarc subdomain
- [ ] Policy set (p=none/quarantine/reject)
- [ ] Aggregate reports configured (rua=)
- [ ] Percentage at 100% (pct=100)
- [ ] Alignment mode appropriate
- [ ] No syntax errors
Measuring Success¶
Key Performance Indicators¶
Authentication Pass Rate¶
Email Deliverability¶
Security Score¶
Spoofing Prevention¶
ReputeAPI Monitoring¶
import requests
from datetime import datetime, timedelta
def track_score_trend(domain, days=30):
"""Track email security score over time"""
response = requests.get(
"https://api.reputeapi.com/api/v1/history",
params={"domain": domain, "days": days},
headers={"X-API-Key": "your-api-key"}
)
history = response.json()
print(f"Score trend for {domain} (last {days} days):\n")
print(f"{'Date':<12} {'Score':<6} {'Grade':<10}")
print("-" * 30)
for snapshot in history['snapshots']:
date = datetime.fromisoformat(snapshot['timestamp']).strftime('%Y-%m-%d')
score = snapshot['score']
grade = snapshot['grade']
print(f"{date:<12} {score:<6} {grade:<10}")
# Calculate improvement
if len(history['snapshots']) >= 2:
first = history['snapshots'][0]['score']
last = history['snapshots'][-1]['score']
improvement = last - first
print(f"\nImprovement: {improvement:+d} points")
Best Practices Summary¶
✅ Do's¶
- Start with p=none - Monitor before enforcing
- Use both SPF and DKIM - Redundancy is critical
- Enable DMARC reports - Essential for visibility
- Set pct=100 - Full protection, not partial
- Use -all for SPF - Hard fail for security
- 2048-bit DKIM keys - Minimum key size
- Regular monitoring - Check reports weekly
- Document everything - Configuration and changes
- Test thoroughly - Before production deployment
- Automate - Use IaC and monitoring tools
❌ Don'ts¶
- Don't skip monitoring - p=none phase is critical
- Don't use +all or ?all - Provides no protection
- Don't exceed 10 SPF lookups - Causes PermError
- Don't forget subdomains - Protect all domains
- Don't ignore reports - They contain critical data
- Don't use weak DKIM keys - <2048 bits is insecure
- Don't make uncoordinated changes - Test first
- Don't set and forget - Requires ongoing maintenance
- Don't rely on SPF alone - Forwarding breaks it
- Don't rush to p=reject - Follow progressive rollout
Getting Help¶
ReputeAPI Resources¶
- API Documentation - Complete API reference
- Quick Start Guide - Get started in 5 minutes
- Integration Examples - Code samples
External Resources¶
Standards & RFCs: - RFC 7208 - SPF - RFC 6376 - DKIM - RFC 7489 - DMARC
Testing Tools: - MXToolbox - Mail Tester - Google Admin Toolbox
DMARC Report Analyzers: - DMARC Analyzer - Postmark DMARC - EasyDMARC
Related Documentation¶
Core Concepts¶
- SPF Explained - Deep dive into SPF
- DKIM Explained - Deep dive into DKIM
- DMARC Explained - Deep dive into DMARC
- DNS Configuration - Provider-specific DNS setup
- Mailflow Security Score - Understanding the scoring system
Getting Started¶
- Quick Start - 5-minute setup
- Authentication Guide - API keys
- Common Errors - Troubleshooting
API Reference¶
- GET /api/v1/check - Comprehensive validation
- POST /api/v1/recommendations - Get recommendations
- GET /api/v1/history - Historical trends
Summary¶
Email authentication with SPF, DKIM, and DMARC provides comprehensive protection against phishing, spoofing, and email fraud. By working together, these protocols:
- ✅ Verify sender identity (SPF)
- ✅ Ensure message integrity (DKIM)
- ✅ Enforce security policies (DMARC)
- ✅ Provide visibility (DMARC reports)
- ✅ Build sender reputation (all three)
Implementation timeline: 2-8 weeks depending on complexity
Maintenance: Ongoing monitoring and regular audits
ReputeAPI helps with validation, scoring, recommendations, and monitoring throughout your email authentication journey.
Ready to improve your email security? Get started with ReputeAPI today.