SPF & DKIM Email Authentication: DNS Configuration, Key Generation, and Validation

SPF & DKIM Email Authentication: Complete Implementation Guide

Email has become critical infrastructure for modern organizations, yet email security remains alarmingly weak. In 2024-2025, email-based attacks account for 96% of all phishing attempts and 82% of data breaches start with compromised email accounts. This comprehensive guide provides step-by-step implementation of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), the foundational email authentication technologies that protect your organization from spoofing, phishing, and impersonation attacks. By implementing these standards correctly, you'll significantly improve email deliverability while preventing attackers from impersonating your domain.

Introduction

The Email Authentication Crisis

Email remains the primary attack vector for cybercriminals because authentication has historically been optional. Traditional SMTP (Simple Mail Transfer Protocol) contains no authentication mechanism—anyone can claim to be anyone else. This fundamental weakness enables:

Phishing and Impersonation: Attackers craft emails appearing to come from trusted senders (executives, banks, vendors) with spoofed From addresses. Users cannot distinguish legitimate emails from forgeries.

Business Email Compromise (BEC): Compromised executive accounts are used to initiate fraudulent wire transfers, often worth hundreds of thousands of dollars. The average BEC incident costs $130,000.

Spam and Bulk Email: Spammers abuse unprotected domains to send millions of unsolicited emails, damaging the legitimate domain's reputation.

Malware Distribution: Forged emails from trusted vendors deliver malware to unsuspecting recipients.

2025 Email Authentication Mandate

Google, Yahoo Mail, and Microsoft have implemented strict requirements for bulk senders (5,000+ emails/day) effective February 2025:

• SPF and DKIM alignment (required for 100% of traffic)
• DMARC policy at minimum quarantine level
• One-click unsubscribe for marketing emails
• TLS encryption for message delivery
• Sender identity verification and reputation management

Senders failing to comply face permanent rejection of their emails.

Why SPF and DKIM Matter

SPF (Sender Policy Framework) publishes authorized mail servers for your domain via DNS TXT records. When an email arrives, the receiving server checks if the sending IP is authorized. SPF prevents basic spoofing but has limitations (only checks envelope sender, doesn't survive forwarding).

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify emails haven't been modified in transit. The sending mail server signs each email with a private key; receiving servers verify the signature using the corresponding public key published in DNS. DKIM survives email forwarding because the signature is cryptographic.

Together, SPF and DKIM form the foundation of email authentication, with DMARC (next section) enforcing policies based on SPF/DKIM results.

Stage 1: Email Infrastructure Assessment (Week 1: 3-5 hours)

Before implementing SPF and DKIM, you must audit your current email infrastructure to understand what needs authentication.

Step 1.1: Authentication Baseline Check

Use the Email Authentication Validator to assess your current status:

1. Navigate to /tools/security/email-auth-validator
2. Enter your primary domain (e.g., example.com)
3. Review the authentication report:
   • SPF Record: Check if SPF record exists; count DNS lookups (10 maximum)
   • DKIM Selectors: Identify all active DKIM selectors
   • DMARC Policy: Document current DMARC enforcement level (none/quarantine/reject)
   • Alignment: Check if SPF/DKIM align with From domain
   • Security Grade: Overall rating (A-F scale)
   • Issues: Document all red flags

Key Metrics to Record:

• Current SPF pass rate (percentage of legitimate emails passing SPF)
• Number of DKIM selectors in use
• DMARC alignment mode (relaxed vs strict)
• Immediate blockers (e.g., SPF over 10 lookups)

Step 1.2: DNS Infrastructure Audit

Conduct a comprehensive DNS audit to understand your current infrastructure:

1. Use DNS Lookup tool (/tools/network/dns-lookup) to query your domain
2. Document these record types:

MX Records:

• List all mail servers with priority values
• Verify redundancy (multiple MX records)
• Check if backup mail servers exist
• Document mail server IPs (you'll need these for SPF)

TXT Records:

• Current SPF record (if any)
• Existing DKIM selectors and public keys
• DMARC policy (if any)
• Domain verification records (Google, Microsoft, etc.)

Additional Records:

• A/AAAA records for mail server hostnames
• PTR (reverse DNS) records for sending IPs
• NS (nameserver) records and TTL values
• SOA (Start of Authority) record for timing information

Step 1.3: Email Sending Source Inventory

Create a comprehensive list of every system that sends email from your domain:

In-Scope Categories:

• Primary mail server: Exchange Server, Gmail Workspace, Office 365, Zimbra (on-premise)
• Transactional email services: Amazon SES, Postmark, Mandrill, SendGrid
• Marketing platforms: Mailchimp, HubSpot, Klaviyo, ActiveCampaign, Salesforce Marketing Cloud
• Internal systems: ERP systems (SAP, NetSuite), CRM (Salesforce, Microsoft Dynamics), monitoring tools (Nagios, Zabbix, Datadog)
• Support/Help desk: Zendesk, Freshdesk, Jira Service Management, Help Scout
• Billing systems: Stripe, Square, PayPal (payment notifications)
• Alerting services: PagerDuty, Opsgenie, monitoring alerting systems
• Document management: SharePoint, OneDrive, Box
• E-signature: DocuSign, Ironclad, SignNow
• Custom applications: Web applications sending transactional emails

For each sending source, document:

• Service name and URL
• Sending IP addresses (static or CIDR range)
• DKIM selector (if available)
• Priority and priority order
• Whether it requires SPF/DKIM configuration

Step 1.4: Sending IP Inventory

Compile a definitive list of all IPs that send email from your domain:

For each mail server/service:

1. Query DNS to find mail server IP: nslookup mail.example.com
2. For cloud services, consult their documentation for IP ranges:
   • Google Workspace: https://support.google.com/a/answer/60764
   • Microsoft 365: https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges
   • SendGrid: https://docs.sendgrid.com/for-developers/parsing-webhook-events/understanding-webhook-security/
   • Amazon SES: https://docs.aws.amazon.com/ses/latest/dg/dkim.html

Create a spreadsheet with:

• IP address (IPv4 and IPv6 if applicable)
• CIDR notation (if range)
• Service/system name
• Priority (critical, high, medium, low)
• DNS lookup count (for SPF)

Step 1.5: Sender Reputation Baseline

Establish baseline metrics before you implement changes, enabling you to measure improvement:

Google Postmaster Tools (Gmail Deliverability):

1. Visit https://postmaster.google.com
2. Add your sending domain
3. Record these metrics:
   • Domain reputation (High/Medium/Low/Bad)
   • IP reputation (per sending IP)
   • Spam rate (percentage, target: <0.1%)
   • Authentication pass rate (SPF, DKIM, DMARC)

Microsoft SNDS (Outlook/Hotmail Deliverability):

1. Visit https://sender.microsoft.com/
2. Register sending IPs
3. Document:
   • IP reputation score (Green/Yellow/Red)
   • Complaint rate (target: <0.3%)
   • Spam trap hits

Current Pass Rates:

• Collect sample emails delivered in past week
• Check Authentication-Results header for SPF/DKIM status
• Calculate percentage passing each mechanism

Stage 2: SPF Record Implementation & Optimization (Weeks 2-3: 4-8 hours)

Step 2.1: SPF Record Design

SPF records authorize mail servers by IP address or include third-party services.

SPF Syntax Overview:

v=spf1 [mechanism] [mechanism] -all

SPF Mechanisms:

SPF Lookup Limit (CRITICAL):

SPF has a hard limit of 10 DNS lookups per evaluation. Exceeding this limit causes permanent failure (PermError). Count lookups for:

• a mechanism = 1 lookup
• mx mechanism = 1 lookup
• ptr mechanism = Multiple lookups (AVOID)
• include: mechanism = 1 lookup each
• exists: mechanism = 1 lookup

ip4:, ip6:, and qualifier flags do NOT count toward the 10-lookup limit.

Step 2.2: SPF Record Generation

Use the SPF Record Generator (/tools/security/spf-generator) to build your SPF record:

Basic SPF Example (Small Organization):

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:sendgrid.net -all

This example:

• Authorizes static IP 203.0.113.5 (your mail server)
• Includes Google Workspace SPF record (1 lookup)
• Includes SendGrid SPF record (1 lookup)
• Rejects all other senders (hardfail with -all)
• Total lookups: 2 (well under 10-lookup limit)

Optimized SPF Example (Large Organization):

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 a:mail.example.com include:_spf.google.com include:sendgrid.net include:amazonses.com ~all

This example adds:

• CIDR ranges for multiple mail servers (no additional lookups)
• Reference to domain's own A record (1 lookup)
• Softfail for unknown senders (they're accepted but flagged)

Step 2.3: SPF Lookup Optimization (Critical for Large Organizations)

If your SPF record approaches or exceeds the 10-lookup limit, use these optimization techniques:

Technique 1: Replace Includes with IP Ranges

If a third-party service publishes its IP ranges, use direct IP addresses instead of includes:

# Instead of (uses 1 lookup):
include:mail.service.com

# Use (uses 0 lookups):
ip4:192.0.2.0/24
ip4:198.51.100.0/24

Technique 2: Remove Redundant Services

Audit your sending sources to eliminate discontinued or unused services. For example, if you migrated from Mailchimp to SendGrid 6 months ago, remove Mailchimp's include.

Technique 3: Consolidate IP Ranges

Instead of:

ip4:192.0.2.1
ip4:192.0.2.2
ip4:192.0.2.3

Use CIDR notation:

ip4:192.0.2.0/30

Technique 4: SPF Flattening (Advanced)

For complex infrastructures, use SPF flattening services that recursively expand all includes into a flat list of IP ranges:

• Valimail Instant SPF
• PowerDMARC PowerSPF
• AutoSPF
• DMARCLY SPF Flattening

Warning: Manual SPF flattening requires maintenance whenever any third-party service changes IPs. Automated flattening services handle this automatically.

Test Lookup Count:

Before publishing your SPF record, test the lookup count:

# Linux/Mac
dig txt example.com | grep "v=spf1"

# Count include statements (each uses 1 lookup)
dig txt example.com | grep -o "include:" | wc -l

Step 2.4: Subdomain SPF Strategy

For high-volume organizations, segment SPF into separate subdomains to maximize lookup budget:

Example Subdomain SPF Configuration:

# Main domain: Restrictive SPF
# _dmarc.example.com → p=reject, adkim=s, aspf=s (strict)
v=spf1 a mx -all

# Marketing subdomain: More permissive
# marketing.example.com → For marketing campaigns
v=spf1 include:sendgrid.net include:mailchimp.com -all

# Transactional subdomain: Restricted to key services
# transactional.example.com → For order confirmations, receipts
v=spf1 include:amazonses.com include:postmark.com -all

# No-reply subdomain: Most restrictive
# noreply.example.com → For system notifications
v=spf1 a -all

Benefits:

• Each subdomain has its own 10-lookup budget
• Isolated reputation management (marketing emails don't affect transactional reputation)
• Granular DMARC policies per subdomain
• Easier troubleshooting (identify which subdomain has issues)

Step 2.5: SPF Deployment & Testing

Publish SPF Record to DNS:

1. Access your DNS provider (GoDaddy, Route 53, Cloudflare, etc.)

2. Add a TXT record:

   • Name: @ (root domain) or example.com
   • Type: TXT
   • Value: Your SPF record
   • TTL: 300 seconds (5 minutes) for testing, 3600 (1 hour) after stabilization

3. Verify propagation:

   dig TXT example.com @8.8.8.8
   dig TXT example.com @1.1.1.1
   

   Copy

Validation Testing:

1. Use Email Authentication Validator (/tools/security/email-auth-validator):

   • Enter your domain
   • Verify SPF record appears correctly
   • Confirm lookup count is valid
   • Test SPF syntax (RFC 7208 compliance)

2. Send test emails from all authorized sources:

   • From primary mail server
   • From each third-party service (Gmail, SendGrid, etc.)
   • Check email headers for SPF results

3. Analyze SPF results in email headers:

   Authentication-Results: mx.google.com;
        spf=pass (google.com: domain of user@example.com designates 203.0.113.5 as permitted sender) smtp.mailfrom=user@example.com;
   

   Copy

Common SPF Results:

• Pass: Email comes from authorized IP; SPF check successful
• Fail: Email from unauthorized IP; should be rejected
• SoftFail (~all): Email from unauthorized IP, but accept with flag
• Neutral: SPF record doesn't make statement about IP
• None: No SPF record for domain
• TempError: Temporary DNS failure (retry later)
• PermError: Permanent SPF error (syntax invalid, lookup limit exceeded)

PermError Debugging:

If you see PermError in SPF results:

1. Check SPF syntax (missing "v=spf1" prefix?)
2. Count DNS lookups (over 10?)
3. Use MxToolbox SPF validator to identify specific error
4. Fix issue in DNS provider
5. Wait for DNS propagation (5-48 hours depending on TTL)

Stage 3: DKIM Setup & Key Rotation (Weeks 3-5: 5-10 hours)

DKIM provides cryptographic email authentication, surviving forwarding and modifications that break SPF.

Step 3.1: DKIM Key Generation

DKIM requires cryptographic key pairs (private key to sign, public key to verify).

Key Requirements (2025 Standards):

• Key size: 2048-bit RSA minimum (1024-bit deprecated in 2025)
• Algorithm: RSA (ECDSA support emerging in 2025)
• Selector naming: Unique identifier for key (allows multiple keys)
• Key rotation: Every 6 months for 2048-bit keys

Service-Specific DKIM Setup:

Google Workspace:

1. Admin Console → Apps → Gmail → Authenticate email
2. Click "Generate new DKIM key"
3. Review DKIM DNS records to add
4. Copy public key and DNS selector name
5. Add TXT records to DNS

Microsoft 365:

1. Security & Compliance Center → Threat Management → Policy → DKIM
2. Select domain → Enable DKIM signing
3. Microsoft generates key pair (cannot export private key)
4. Publish provided DNS records
5. Microsoft signs all outbound emails automatically

Amazon SES:

1. SES Console → Verified Identities → Select domain
2. Authentication → DKIM Settings → Generate DKIM Tokens
3. Copy CNAME records provided
4. Add to DNS (SES generates tokens that CNAME to AWS infrastructure)
5. Enable DKIM signing in email sending code

SendGrid:

1. Settings → Sender Authentication → Domain Authentication
2. Enter domain to authenticate
3. Verify domain with DNS TXT record
4. SendGrid generates DKIM key automatically
5. Add provided DNS records

Postmark:

1. Servers → [Your Server] → Settings → DKIM
2. Click "Activate DKIM for this domain"
3. Add provided DNS records
4. Postmark manages key rotation automatically

On-Premise Mail Servers:

Postfix:

# Generate DKIM keys
opendkim-genkey -b 2048 -d example.com -s default -D /etc/opendkim/keys

# Output files:
# - default.private (private key, keep secure)
# - default.txt (public key for DNS)

# Edit Postfix config
nano /etc/postfix/main.cf

# Add:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:12301
non_smtpd_milters = inet:127.0.0.1:12301

Exim:

# Generate DKIM keys
openssl genrsa -out /etc/exim/dkim/example.private 2048
openssl rsa -in /etc/exim/dkim/example.private -pubout -out /etc/exim/dkim/example.public

# Edit Exim config (exim.conf)
dkim_domain = example.com
dkim_selector = default
dkim_private_key = /etc/exim/dkim/example.private
dkim_signing_domains = *

Exchange Server (On-Premise):

# Generate DKIM key
New-DkimSigningConfig -DomainName example.com -Enabled $true

# Retrieve DNS records to publish
Get-DkimSigningConfig -Identity example.com | Select-Object *Record

# Exchange automatically signs all outbound emails

Step 3.2: Multi-Selector DKIM Architecture

Implement separate DKIM selectors for different sending sources. This isolates key rotation and enables granular troubleshooting.

Example Multi-Selector Configuration:

# Google Workspace emails
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

# SendGrid marketing emails
sendgrid._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

# Amazon SES transactional emails
ses._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

# On-premise mail server
server1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

# Backup mail server
server2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Benefits:

• Isolated Rotation: Rotate one service's DKIM key without affecting others
• Service-Specific Troubleshooting: If DKIM fails from SendGrid, you know SendGrid is the issue
• Independent Security Policies: Different key rotation schedules per service
• Failure Isolation: If one selector has issues, others continue working
• Emergency Key Revocation: Revoke a compromised key without affecting legitimate senders

Selector Naming Convention:

Choose descriptive selector names:

• Service-based: google, sendgrid, ses, mailchimp
• Location-based: us-east, eu-west, asia-pacific
• Function-based: marketing, transactional, notifications, alerts
• Date-based: dkim202501, dkim202502 (for rotation)

Step 3.3: DKIM Signature Verification

Each DKIM-signed email includes a signature header containing key metadata:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=google; h=from:to:subject:date:message-id:from:from; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=dGVzdCBzaWduYXR1cmU=

DKIM Signature Components:

Canonicalization Modes:

• Simple: Exact header/body preservation (strict but fragile)
• Relaxed: Ignore whitespace differences (tolerates formatting changes)

Use relaxed/relaxed for maximum compatibility; simple mode fails if emails are reformatted.

Step 3.4: DKIM Testing & Validation

Step 1: Publish DKIM Public Keys to DNS

For each DKIM selector, publish TXT record:

# Format:
{selector}._domainkey.{domain} TXT "{public_key}"

# Example:
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2a2rwplBCHnlvr..."

Step 2: Verify DNS Records

# Query DKIM record
dig TXT google._domainkey.example.com

# Or using nslookup
nslookup -type=TXT google._domainkey.example.com

Step 3: Send Test Emails

Send test emails from each configured source and check headers for DKIM signature:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google header.b=abc123...
       dkim=pass header.i=@example.com header.s=sendgrid header.b=xyz789...

Step 4: Use Email Authentication Validator

1. Navigate to /tools/security/email-auth-validator
2. Enter your domain and sending subdomain
3. Review DKIM results:
   • DKIM Record Found: Public key accessible in DNS
   • Key Valid: Public key format correct
   • Signature Valid: DKIM signature verifies correctly
   • Alignment: Domain in DKIM signature matches From header

Step 5: Use Email Header Analyzer

For deeper DKIM analysis:

1. Forward a test email to /tools/security/email-header-analyzer
2. Review Authentication-Results header for DKIM details
3. Check for signature failures:
   • fail (signature verification failed) - Key mismatch or invalid signature
   • fail (key not found) - DKIM selector doesn't exist in DNS
   • fail (body hash mismatch) - Email body modified in transit
   • tempError - Temporary DNS failure (retry email receipt)
   • permError - Permanent DKIM error (fix configuration)

Step 3.5: DKIM Key Rotation Strategy

Implement scheduled key rotation to minimize risk if a key is compromised.

Rotation Frequency (2025 Standard):

• 2048-bit RSA keys: Every 6 months (standard)
• 4096-bit RSA keys: Every 12 months (provides additional security margin)
• High-risk organizations (financial institutions, government): Every 1-3 months
• Incident response: Immediately if key compromised

Zero-Downtime Rotation Process:

Phase 1: Parallel Keys (Days 1-3)

1. Generate new DKIM key pair with new selector

   # New selector: google2 (for Google Workspace key rotation)
   openssl genrsa -out google2.private 2048
   openssl rsa -in google2.private -pubout -out google2.public
   

   Copy

2. Publish new public key to DNS with new selector

   google2._domainkey.example.com TXT "v=DKIM1; k=rsa; p={new_public_key}"
   

   Copy

3. Wait 24-48 hours for DNS propagation

4. Verify new key is accessible:

   dig TXT google2._domainkey.example.com
   

   Copy

Phase 2: Gradual Transition (Days 3-7)

5. Configure email service to sign with new selector (for services that support multiple selectors):

   • Google Workspace: Can only use one selector at a time
   • SendGrid: Configure new DKIM selector in settings
   • Postfix: Update opendkim configuration to use new key

6. For services that don't support multiple selectors, cut over immediately and monitor:

   • Check Authentication-Results headers to verify new selector in use
   • Monitor DMARC reports for DKIM pass rates

Phase 3: Monitor & Clean Up (Days 7-14)

7. Monitor DMARC reports to confirm old selector usage dropped to zero:

   • Log into DMARC analysis tool (dmarcian, PowerDMARC, etc.)
   • Verify reports show 100% signed with new selector
   • Check for any DKIM failures from old selector

8. After 7 days of zero old-selector usage, remove old public key from DNS:

   # Delete old key record (or just remove the TXT record)
   google._domainkey.example.com TXT [DELETE]
   

   Copy

9. Document rotation in change log with:

   • Date rotated
   • Old selector and key fingerprint
   • New selector and key fingerprint
   • Services affected
   • Completion status

Automation Recommendations:

For large organizations with multiple domains, use automated DKIM rotation tools:

• dmarcian: Automated DKIM rotation with monitoring
• Valimail: Enterprise DKIM key management
• PowerDMARC: DKIM rotation scheduling
• Custom automation: Python/Ruby scripts that:
  • Generate new keys on schedule
  • Update DNS records via API
  • Configure mail servers
  • Monitor DMARC reports for success

Stage 4: Common Issues & Troubleshooting

SPF Issues

Problem: SPF PermError (Permanent Failure)

Cause: SPF record syntax error or exceeded 10-lookup limit

Solution:

1. Validate SPF syntax: v=spf1 prefix required
2. Count DNS lookups (each include:, a, mx, exists: = 1 lookup)
3. Use MxToolbox SPF validator to identify specific error
4. Replace includes with IP ranges if possible
5. Use SPF flattening service for complex records

Example:

# WRONG (missing v=spf1)
spf1 ip4:192.0.2.5 -all

# CORRECT
v=spf1 ip4:192.0.2.5 -all

Problem: SPF Fail (Rejection)

Cause: Email sent from unauthorized IP

Solution:

1. Identify sending IP using Email Header Analyzer
2. Verify IP should be authorized
3. Add IP to SPF record:

   v=spf1 ip4:192.0.2.5 include:_spf.google.com -all
   

   Copy
4. Publish updated SPF record to DNS
5. Test again (allow 5-10 minutes for DNS propagation)

Problem: SPF SoftFail (Warnings)

Cause: Email from unauthorized IP, but SPF policy allows (~all)

Solution:

1. If IP should be authorized, add to SPF record
2. If IP is unknown, investigate source
3. After fixing all unauthorized sources, change to -all (hardfail)

DKIM Issues

Problem: DKIM Fail (Key Not Found)

Cause: DKIM public key not in DNS or selector incorrect

Solution:

1. Verify selector name in email header: header.s=google
2. Query DNS for key:

   dig TXT google._domainkey.example.com
   

   Copy
3. If missing, publish key to DNS
4. If present but not found, wait 15-30 minutes for DNS propagation
5. Verify TTL is not cached too long (TTL should be 1-3600)

Problem: DKIM Fail (Signature Verification Failed)

Cause: Email body modified in transit or key mismatch

Solution:

1. Check body canonicalization in DKIM-Signature header
2. If email was forwarded/modified, DKIM will fail (expected)
3. Verify public key in DNS matches private key on mail server
4. Check body for:
   • Added footers or signatures (breaks DKIM)
   • Quoted-printable encoding changes
   • Line-ending modifications (CRLF vs LF)
5. If persistent, regenerate DKIM key pair and republish

Problem: DKIM Pass but DMARC Fail (Alignment Issue)

Cause: Domain in DKIM signature (d=) doesn't match From header domain

Solution:

1. Check email From header: From: user@example.com
2. Check DKIM-Signature d= parameter: d=mail.example.com
3. If subdomains don't match, use DMARC adkim=r (relaxed alignment) instead of adkim=s (strict)
4. Or, configure mail servers to sign with actual From domain

Stage 5: Mail Server Integration

Postfix Configuration

# /etc/postfix/main.cf

# OpenDKIM integration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:12301
non_smtpd_milters = inet:127.0.0.1:12301

# /etc/opendkim.conf
Domains example.com,other.com
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Socket inet:12301@localhost

# /etc/opendkim/KeyTable
google._domainkey.example.com example.com:google:/etc/opendkim/keys/google.private
sendgrid._domainkey.example.com example.com:sendgrid:/etc/opendkim/keys/sendgrid.private

# /etc/opendkim/SigningTable
*@example.com google._domainkey.example.com
*@example.com sendgrid._domainkey.example.com

Exim Configuration

# exim.conf
dkim_domain = example.com
dkim_selector = google
dkim_private_key = /etc/exim/dkim/google.private
dkim_signing_domains = example.com:other.com
dkim_hash = sha256
dkim_sign_headers = from:to:subject:date

AWS SES Configuration

import boto3

ses = boto3.client('ses', region_name='us-east-1')

# Verify domain with DKIM
response = ses.verify_domain_dkim(Domain='example.com')

# Response includes DKIM tokens to add as CNAME records
dkim_tokens = response['DkimTokens']
for token in dkim_tokens:
    print(f"CNAME: {token}._domainkey.example.com")
    print(f"Value: {token}.dkim.amazonses.com")

# Send email (DKIM signing happens automatically)
response = ses.send_email(
    Source='user@example.com',
    Destination={'ToAddresses': ['recipient@example.com']},
    Message={
        'Subject': {'Data': 'Test Email'},
        'Body': {'Text': {'Data': 'This email will be DKIM signed'}}
    }
)

Stage 6: Validation & Testing Procedures

Comprehensive Testing Workflow

Before declaring SPF and DKIM implementation complete, execute this comprehensive validation workflow:

Week 1: Pre-Implementation Baseline

1. Send 10 test emails from each authorized source
2. Check Authentication-Results headers in inbox
3. Record SPF/DKIM status (pass/fail/error)
4. Calculate baseline pass rates for each sender
5. Document baseline in spreadsheet for comparison

Week 2-3: Post-Implementation Testing

1. Send 50 test emails from each source (mix of different times, content)
2. Verify 100% SPF pass rate from authorized sources
3. Verify 100% DKIM pass rate (all signatures valid)
4. Test forwarding (DKIM should survive, SPF may fail - expected)
5. Test from different regions (Americas, Europe, Asia)
6. Test on major providers: Gmail, Outlook, Yahoo, AOL

Week 4: Real-World Validation

1. Monitor production email authentication rates
2. Analyze email headers from actual business emails
3. Check DMARC aggregate reports (if DMARC deployed)
4. Verify no legitimate emails being rejected
5. Monitor bounce rates for changes

Email Header Inspection Guide

When troubleshooting authentication issues, examine email headers carefully:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of sender@example.com designates 203.0.113.5 as permitted sender) smtp.mailfrom=sender@example.com;
       dkim=pass header.i=@example.com header.s=google header.b=abc123xyz...;
       dmarc=pass (p=none sp=none dis=none) header.from=example.com

Interpret SPF Results:

• spf=pass - Sending IP authorized in SPF
• spf=fail - Sending IP NOT in SPF (will be rejected with DMARC p=reject)
• spf=neutral - SPF record present but doesn't assert anything about IP
• spf=softfail - IP not authorized but soft failure (accept but flag)
• spf=none - No SPF record for domain
• spf=temperror - Temporary DNS failure
• spf=permerror - Permanent SPF error (syntax invalid, lookup limit exceeded)

Interpret DKIM Results:

• dkim=pass - DKIM signature valid
• dkim=fail - Signature verification failed
• dkim=neutral - No signature or DKIM record missing
• dkim=temperror - Temporary DNS failure (public key lookup)
• dkim=permerror - Permanent DKIM error (invalid signature, bad key)

DMARC Alignment Analysis:

• header.i=@example.com - Sender identity in DKIM signature
• header.s=google - DKIM selector used
• adkim=r - DMARC using relaxed DKIM alignment
• aspf=r - DMARC using relaxed SPF alignment

Failed Email Debugging Checklist

When emails fail authentication, use this systematic debugging approach:

If SPF Fails:

1. Identify sending IP from email headers: Received: from server (IP)
2. Check SPF record: dig TXT example.com
3. Verify IP is authorized in SPF
4. If not authorized, add IP and republish to DNS
5. Wait for DNS propagation (5-30 minutes)
6. Resend test email and verify SPF pass

If DKIM Fails:

1. Identify DKIM selector: header.s=google from Authentication-Results
2. Query DNS for public key: dig TXT google._domainkey.example.com
3. Verify public key exists and is valid
4. If missing, publish public key to DNS
5. If exists, check if mail server is using correct private key
6. Verify selector name matches between mail server config and DNS
7. Resend test email and verify DKIM pass

If DKIM Pass but Verification Fails:

1. Check email hasn't been modified (forwarding, mailbox rules)
2. Verify body canonicalization (simple vs relaxed)
3. Compare public key in DNS with private key on server
4. If key mismatch, regenerate key pair and republish
5. If signature appears valid, issue may be client-side

Critical Validation Metrics

Track these metrics throughout implementation:

Authentication Pass Rates (Target: 100% for legitimate mail)

SPF Pass Rate: [number passing] / [total] = [percentage]%
DKIM Pass Rate: [number passing] / [total] = [percentage]%
DMARC Pass Rate: [number passing] / [total] = [percentage]%

Deliverability Impact

• Inbox placement rate (target: 95%+)
• Bounce rate (target: <2%)
• Complaint rate (target: <0.1%)
• Spam folder placement (should decrease)

Infrastructure Health

• DNS lookup count (must be <10 for SPF)
• DKIM key validity (should be 2048-bit minimum)
• Selector consistency (same selector for same service)
• TTL values appropriate (300-3600 seconds)

Stage 7: Deployment Timeline & Roadmap

Quick Implementation (2-3 weeks)

For organizations with simple email infrastructure:

Week 1:

• Audit current infrastructure (1-2 hours)
• Generate and publish SPF record (1-2 hours)
• Test SPF from all sources (1-2 hours)

Week 2:

• Generate DKIM keys for all services (1-2 hours)
• Publish DKIM public keys to DNS (1 hour)
• Configure mail servers for DKIM signing (2-3 hours)
• Test DKIM from all sources (1-2 hours)

Week 3:

• Comprehensive validation and testing (2-4 hours)
• Fix any remaining issues (1-3 hours)
• Prepare for DMARC deployment (1 hour)

Phased Implementation (4-6 weeks)

For organizations with complex multi-service infrastructure:

Week 1: Assessment

• Comprehensive infrastructure audit (3-4 hours)
• Identify all sending sources (2-3 hours)
• Establish baseline metrics (1-2 hours)

Week 2: SPF Deployment

• Design optimized SPF record (1-2 hours)
• Publish and test SPF (2-3 hours)
• Monitor for issues (1 hour daily)

Week 3-4: DKIM Setup

• Generate DKIM keys for each service (2-3 hours)
• Publish DKIM records (1-2 hours)
• Configure mail servers (3-5 hours)
• Test and validate (2-3 hours)

Week 5-6: Comprehensive Testing

• Real-world validation (5-10 hours)
• Fix issues as discovered (varies)
• Prepare monitoring and reporting (2-3 hours)
• DMARC record preparation (1-2 hours)

Enterprise Implementation (8-13 weeks)

For large organizations with legacy systems and compliance requirements:

Weeks 1-2: Discovery & Planning

• Audit all sending sources (5-10 hours)
• Map infrastructure dependencies (3-5 hours)
• Identify compliance requirements (2-3 hours)
• Develop implementation plan (2-3 hours)

Weeks 3-4: SPF Deployment

• Design SPF strategy (1-2 hours)
• Implement SPF flattening (2-4 hours if needed)
• Deploy to staging/test domains first (2-3 hours)
• Gradual production rollout by subdomain (2-3 hours)

Weeks 5-7: DKIM Implementation

• Key generation for all services (3-5 hours)
• Multi-selector architecture design (1-2 hours)
• Mail server configuration (5-10 hours)
• Comprehensive testing (5-10 hours)
• Parallel key period (keys overlap, optional)

Weeks 8-13: Validation & DMARC Transition

• Extended real-world testing (5-10 hours)
• Reputation baseline measurement (2-3 hours)
• DMARC record deployment (p=none initially)
• DMARC report analysis (ongoing)
• Gradual DMARC policy tightening (p=quarantine → p=reject)

Conclusion & Next Steps

SPF and DKIM form the foundation of email authentication, protecting your domain from spoofing while improving deliverability. This implementation covers:

1. Infrastructure assessment - Understanding your email ecosystem
2. SPF optimization - Authorizing legitimate senders within DNS constraints
3. DKIM key generation - Cryptographic email signing
4. Multi-selector strategy - Isolating keys for different services
5. Testing and validation - Ensuring authentication works correctly

Next steps:

• Implement DMARC (next article) to enforce SPF/DKIM policies
• Monitor DMARC reports for authentication failures
• Establish 6-month DKIM key rotation schedule
• Work toward p=reject DMARC policy for maximum protection

Tools & Resources

InventiveHQ Tools:

• Email Authentication Validator - Validate SPF/DKIM records
• SPF Record Generator - Build optimized SPF records
• DNS Lookup - Query email DNS records
• Email Validator - Test email address validity

Related Articles:

• Email Deliverability & Anti-Spoofing Campaign