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

1. You send an email from [email protected]
2. The receiving server notes the sending IP address
3. It queries DNS for yourdomain.com's SPF record
4. Compares the sending IP against your authorized list
5. 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

1. Log into your domain registrar or DNS host (GoDaddy, Cloudflare, Namecheap, etc.)
2. Navigate to DNS settings for your domain
3. Add a new TXT record
4. Set the host/name to @ (or your domain name)
5. Paste your SPF record as the value
6. 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

1. You generate a public/private key pair
2. The private key stays secure on your mail server
3. The public key is published as a DNS TXT record
4. When sending, your server creates a hash of email headers and body, then signs it with the private key
5. The signature is added to email headers
6. 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

1. Go to Google Admin Console (admin.google.com)
2. Navigate to Apps > Google Workspace > Gmail
3. Click Authenticate email
4. Select your domain
5. Click Generate new record
6. Choose key length (2048-bit recommended)
7. Copy the generated DKIM record
8. Add as TXT record in your DNS at google._domainkey.yourdomain.com
9. Return to Google Admin and click Start authentication

DKIM for Microsoft 365

1. Go to Microsoft 365 Defender portal
2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings
3. Select DKIM tab
4. Select your domain
5. Toggle Enable to create DKIM signatures
6. Copy the CNAME records provided
7. Add both CNAME records to your DNS
8. Return to Microsoft and verify

DKIM for Other Services

Most email services provide DKIM setup instructions. Common pattern:

1. Find DKIM settings in the service's admin panel
2. Generate or retrieve the DKIM public key
3. Add as TXT or CNAME record at the specified selector._domainkey.yourdomain.com
4. 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:[email protected]

Step 2: Add DMARC Record to DNS

1. Log into your DNS management
2. Add a TXT record
3. Set host/name to _dmarc (resulting in _dmarc.yourdomain.com)
4. Add your DMARC policy as the value
5. 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:[email protected]

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:[email protected]; ruf=mailto:[email protected]

Testing Your Authentication

After setting up SPF, DKIM, and DMARC, verify everything is working correctly.

Quick Test with Mail-Tester

1. Go to mail-tester.com
2. Note the unique email address provided
3. Send a test email to that address
4. 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:[email protected]

Percentage Rollout

Use pct= to apply policy to only a percentage of failing mail:

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]

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 Pro plan starting at $14.99/month.