SPF, DKIM, DMARC Setup
How to Set Up SPF, DKIM, and DMARC: Complete Email Authentication Guide
Why Email Authentication Matters
Email authentication is the technical foundation of email deliverability. These protocols prove to receiving servers that your emails are legitimately from you and have not been tampered with or forged by malicious actors.
Without proper authentication, even legitimate emails face immediate suspicion. Email providers cannot distinguish you from spammers or phishers who might be pretending to be your domain. The result is increased spam filtering, lower inbox placement, and vulnerability to email spoofing attacks.
The Three Authentication Protocols
- SPF (Sender Policy Framework): Lists which servers are authorized to send email for your domain
- DKIM (DomainKeys Identified Mail): Adds a cryptographic signature proving the email came from you and was not modified
- DMARC (Domain-based Message Authentication, Reporting and Conformance): Tells receivers what to do when SPF or DKIM fail, and provides reporting
The Business Case for Authentication
- Deliverability: Gmail, Microsoft, and Yahoo all require authentication for bulk senders as of 2024
- Brand protection: Prevents spoofing attacks where criminals send email pretending to be you
- Trust signals: Authenticated emails receive preferential treatment from spam filters
- Compliance: Many industries require email authentication for regulatory compliance
Understanding SPF
SPF (Sender Policy Framework) is a DNS record that lists all servers and IP addresses authorized to send email on behalf of your domain. When someone receives an email claiming to be from @yourdomain.com, their server looks up your SPF record to verify the sending server is on your approved list.
How SPF Verification Works
- You send an email from sales@yourdomain.com
- The receiving server notes the sending IP address
- It queries DNS for yourdomain.com's SPF record
- Compares the sending IP against your authorized list
- If found, SPF passes. If not found, SPF fails.
SPF Record Syntax
An SPF record is a TXT record in DNS with specific syntax:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.1 ~all
Breaking down the components:
- v=spf1: Version identifier (always required)
- include: Authorizes all IPs listed in another domain's SPF record
- ip4: Authorizes a specific IPv4 address
- ip6: Authorizes a specific IPv6 address
- a: Authorizes IP addresses in the domain's A record
- mx: Authorizes servers in the domain's MX records
- ~all: Soft fail for unauthorized (recommended default)
- -all: Hard fail for unauthorized (strictest)
- ?all: Neutral (offers no protection)
Setting Up SPF Records
Step 1: Identify All Sending Sources
Before creating your SPF record, list every service that sends email using your domain:
- Your primary email provider (Google Workspace, Microsoft 365, etc.)
- Marketing platforms (Mailchimp, HubSpot, etc.)
- Transactional email services (SendGrid, Mailgun, etc.)
- CRM systems that send email (Salesforce, Pipedrive, etc.)
- Support platforms (Zendesk, Intercom, etc.)
- Any other application sending email as your domain
Step 2: Build Your SPF Record
For Google Workspace:
v=spf1 include:_spf.google.com ~all
For Microsoft 365:
v=spf1 include:spf.protection.outlook.com ~all
For multiple services (example):
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all
Step 3: Add the Record to DNS
- Log into your domain registrar or DNS host (GoDaddy, Cloudflare, Namecheap, etc.)
- Navigate to DNS settings for your domain
- Add a new TXT record
- Set the host/name to @ (or your domain name)
- Paste your SPF record as the value
- Save and wait for propagation (usually minutes, up to 48 hours)
SPF Limitations and Rules
- One SPF record per domain: Multiple SPF records cause failures. Combine all authorizations into one record.
- Maximum 10 DNS lookups: Each include: counts as a lookup. Too many causes failures.
- 255 character limit per string: Long records need to be split (handled automatically by most DNS providers)
Understanding DKIM
DKIM (DomainKeys Identified Mail) uses public-key cryptography to prove emails were sent by you and have not been modified in transit. Each email is signed with a private key, and receivers verify the signature using your public key in DNS.
How DKIM Works
- You generate a public/private key pair
- The private key stays secure on your mail server
- The public key is published as a DNS TXT record
- When sending, your server creates a hash of email headers and body, then signs it with the private key
- The signature is added to email headers
- Receiving servers retrieve your public key from DNS and verify the signature
DKIM Provides
- Authentication: Proves the email genuinely came from your domain
- Integrity: Any modification to the email after signing invalidates the signature
- Non-repudiation: You cannot deny sending a signed email
Setting Up DKIM
DKIM setup varies by email provider because each provider generates and manages the keys differently.
DKIM for Google Workspace
- Go to Google Admin Console (admin.google.com)
- Navigate to Apps > Google Workspace > Gmail
- Click Authenticate email
- Select your domain
- Click Generate new record
- Choose key length (2048-bit recommended)
- Copy the generated DKIM record
- Add as TXT record in your DNS at google._domainkey.yourdomain.com
- Return to Google Admin and click Start authentication
DKIM for Microsoft 365
- Go to Microsoft 365 Defender portal
- Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings
- Select DKIM tab
- Select your domain
- Toggle Enable to create DKIM signatures
- Copy the CNAME records provided
- Add both CNAME records to your DNS
- Return to Microsoft and verify
DKIM for Other Services
Most email services provide DKIM setup instructions. Common pattern:
- Find DKIM settings in the service's admin panel
- Generate or retrieve the DKIM public key
- Add as TXT or CNAME record at the specified selector._domainkey.yourdomain.com
- Verify in the service's settings
Multiple DKIM Keys
Each email service needs its own DKIM key. The selector mechanism allows multiple keys per domain:
- google._domainkey.yourdomain.com (for Google Workspace)
- s1._domainkey.yourdomain.com (for SendGrid)
- k1._domainkey.yourdomain.com (for Mailchimp)
Understanding DMARC
DMARC builds on SPF and DKIM by adding a policy layer and reporting mechanism. It tells receiving servers what to do when authentication fails and sends you reports about authentication results.
What DMARC Does
- Policy enforcement: Specifies how to handle emails failing authentication
- Alignment requirements: Requires SPF or DKIM domains to align with the visible From address
- Reporting: Sends aggregate and forensic reports about authentication results
DMARC Alignment
DMARC adds an important concept: alignment. It is not enough for SPF or DKIM to pass; the authenticated domain must also match (align with) the visible From address domain.
- SPF alignment: The Return-Path domain must match the From domain
- DKIM alignment: The DKIM signing domain (d=) must match the From domain
DMARC Policies
- p=none: Monitor only. Take no action on failures, just send reports.
- p=quarantine: Send failing emails to spam/junk folder.
- p=reject: Block failing emails entirely.
Setting Up DMARC
Step 1: Start with Monitoring Policy
Always begin with p=none to monitor before enforcing:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Step 2: Add DMARC Record to DNS
- Log into your DNS management
- Add a TXT record
- Set host/name to _dmarc (resulting in _dmarc.yourdomain.com)
- Add your DMARC policy as the value
- Save and wait for propagation
Step 3: Monitor DMARC Reports
DMARC aggregate reports arrive as XML files to the email specified in rua=. Use a DMARC report analyzer to make sense of the data:
- DMARC Analyzer
- dmarcian
- Postmark DMARC
- Valimail
Review reports for 2-4 weeks to identify:
- Legitimate email sources failing authentication (fix these first)
- Unauthorized senders attempting to spoof your domain
- Configuration errors in SPF or DKIM
Step 4: Progress to Enforcement
After confirming legitimate email is passing authentication:
Move to quarantine (recommended intermediate step):
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com
The pct=25 applies the policy to only 25% of failing mail initially. Increase gradually.
Move to full reject (maximum protection):
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com
Testing Your Authentication
After setting up SPF, DKIM, and DMARC, verify everything is working correctly.
Quick Test with Mail-Tester
- Go to mail-tester.com
- Note the unique email address provided
- Send a test email to that address
- Return to the site for a detailed authentication report
Check Individual Records
SPF Check:
- Use MXToolbox SPF lookup
- Enter your domain
- Verify the record shows valid and includes all expected sources
DKIM Check:
- Use MXToolbox DKIM lookup
- Enter your domain and selector
- Verify the public key is found and valid
DMARC Check:
- Use MXToolbox DMARC lookup
- Enter your domain
- Verify the policy is correctly formatted
Send Test Emails
Send test emails to addresses at Gmail, Outlook, and Yahoo. Check the email headers to verify:
- SPF: PASS
- DKIM: PASS
- DMARC: PASS
In Gmail, click the three dots > Show original to view full headers including authentication results.
Troubleshooting Common Issues
SPF Failures
Too many DNS lookups: SPF has a 10-lookup limit. Each include: counts as one. Solution: Use SPF flattening tools or ip4: mechanisms where possible.
Missing sending source: Emails from services not in your SPF record will fail. Audit all email sources and add them.
Multiple SPF records: Only one SPF record allowed per domain. Combine all authorizations into a single record.
DKIM Failures
Selector not found: The DNS record is not at the correct location. Verify selector._domainkey.yourdomain.com is correct.
Signature verification failed: Can indicate email modification in transit or key mismatch. Re-generate keys if persistent.
DNS propagation: New DKIM records may take up to 48 hours to propagate. Wait and retest.
DMARC Failures
Alignment failures: SPF or DKIM passes but domains do not align with From address. Common with third-party senders. Solution: Ensure services sign with your domain via DKIM.
Not receiving reports: Reports go to the email in rua=. Check spam folders. Ensure email address is valid and monitored.
Advanced Configuration
Subdomain Policies
DMARC allows separate policies for subdomains using sp= tag:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:reports@yourdomain.com
Percentage Rollout
Use pct= to apply policy to only a percentage of failing mail:
v=DMARC1; p=quarantine; pct=50; rua=mailto:reports@yourdomain.com
BIMI (Brand Indicators for Message Identification)
BIMI allows displaying your logo in email clients. Requires DMARC with p=quarantine or p=reject. Add a DNS record:
default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg"
Ongoing Maintenance
Regular Review Tasks
- Monthly: Review DMARC aggregate reports for anomalies
- Quarterly: Audit email sending sources and update SPF if needed
- When adding services: Update SPF and configure DKIM before enabling email sending
- Annually: Consider rotating DKIM keys
Documentation
Maintain documentation of:
- All authorized email sending sources
- SPF record components and why each is included
- DKIM selectors for each service
- DMARC policy history and any incidents
WarmySender and Authentication
WarmySender requires proper email authentication for optimal deliverability. During mailbox connection, the system checks for SPF, DKIM, and DMARC configuration and provides guidance if improvements are needed. Proper authentication combined with WarmySender's warmup ensures the best possible inbox placement rates. All included in the $49 one-time lifetime plan.
Frequently Asked Questions
Do I need all three (SPF, DKIM, DMARC)?
Yes, all three work together for complete email authentication. SPF verifies the sending server is authorized. DKIM cryptographically proves the email is genuinely from you and unmodified. DMARC ties them together with policy enforcement and reporting. Gmail and Yahoo now require all three for bulk senders. Missing any one significantly weakens your authentication and deliverability.
What order should I set up SPF, DKIM, and DMARC?
Set up in this order: SPF first (usually simplest, one DNS record), then DKIM (requires key generation for each email service), then DMARC (last, as it depends on SPF and DKIM). Start DMARC with p=none policy for monitoring, review reports for 2-4 weeks, then progress to enforcement.
What happens if SPF fails?
SPF failure alone usually does not cause immediate rejection. The result depends on your DMARC policy: with p=none nothing happens, with p=quarantine the email may go to spam, with p=reject it may be blocked. SPF failures contribute to reputation damage over time. Common causes include missing include: statements for email services or exceeding the 10-lookup limit.
How do I fix SPF too many DNS lookups?
The SPF 10-lookup limit is a common issue. Solutions: 1) Replace include: with ip4: where IPs are static, 2) Use an SPF flattening service that converts includes to IP addresses, 3) Remove unused services from your SPF, 4) Consider a subdomain for some email categories with its own simpler SPF.
Why is DKIM failing even though I added the DNS record?
Common causes: 1) DNS propagation delay (wait 24-48 hours), 2) Wrong selector in the DNS record name, 3) Typo in the key value, 4) The email service is not enabled to sign with DKIM, 5) You are testing from a service not covered by that DKIM key. Use DKIM lookup tools to verify the record exists and is valid.
Should I start DMARC with p=reject?
No, always start with p=none for monitoring. DMARC reject policy blocks failing emails, including potentially legitimate mail from misconfigured sources you may not know about. Monitor with p=none for 2-4 weeks, fix any issues revealed in reports, then progress to p=quarantine with pct=25, gradually increasing to p=reject.
How do I read DMARC aggregate reports?
DMARC aggregate reports are XML files sent daily to the email in your rua= tag. They show authentication results for all emails claiming to be from your domain. Use DMARC analyzer tools like dmarcian, DMARC Analyzer, or Postmark DMARC to parse and visualize the data. Look for legitimate sources failing authentication (fix them) and unauthorized sources (your policy should block them).
Do I need to update authentication when adding new email services?
Yes. Before enabling email sending from any new service: 1) Add their sending servers to your SPF record with the appropriate include: statement, 2) Configure DKIM in the service and add the DKIM DNS record, 3) Test authentication before sending to real recipients. Failing to update authentication causes delivery failures from the new service.
Put This Knowledge Into Action
Start warming up your inbox today and see better deliverability results.
Get Started Free