SPF, DKIM, and DMARC Basics

Why Email Authentication Matters

Email was designed without built-in sender verification. Anyone can claim to send "from" any address—this is how phishing and spoofing attacks work. Authentication protocols were developed to fill this gap, allowing receiving servers to verify that you are who you claim to be.

Without authentication, your emails look suspicious to receiving servers. Even legitimate messages may be filtered because the server cannot confirm they actually came from your domain. Authentication is now expected by all major providers—Gmail, Microsoft, Yahoo, and others all prioritize authenticated mail.

Authentication also protects your domain from abuse. Spammers cannot easily spoof your domain to send malicious emails if you have proper authentication with enforcement policies. This protects both your recipients and your domain reputation.

SPF (Sender Policy Framework)

SPF answers a simple question: "Is this server authorized to send mail for this domain?" It works through a DNS TXT record that lists all IP addresses and servers permitted to send email on behalf of your domain.

When a receiving server gets an email claiming to be from your domain, it looks up your SPF record. If the sending server's IP is on the list, SPF passes. If not, SPF fails or produces a soft fail, depending on your policy.

EXAMPLE SPF RECORD:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all

BREAKDOWN:
v=spf1                    → SPF version (required)
include:_spf.google.com   → Authorize Google Workspace servers
include:sendgrid.net      → Authorize SendGrid servers
ip4:203.0.113.0/24        → Authorize specific IP range
-all                      → Reject all other senders (hard fail)

COMMON QUALIFIERS:
-all   → Hard fail: reject unauthorized senders
~all   → Soft fail: accept but mark as suspicious
?all   → Neutral: no assertion (rarely used)

SPF LOOKUP LIMIT:
Maximum 10 DNS lookups per SPF evaluation
Exceeding this limit causes SPF to fail
Use flattening tools if hitting the limit

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each email, proving that the message content has not been modified in transit and that it originated from an authorized sender. Unlike SPF, which verifies the sending server, DKIM verifies the message itself.

DKIM uses public-key cryptography. You generate a key pair: the private key stays on your sending server and signs outgoing emails; the public key is published in DNS so receivers can verify signatures.

When an email is sent, your server creates a hash of specified email headers and body, encrypts this hash with your private key, and adds the signature as a header. The receiving server retrieves your public key from DNS and verifies the signature.

EXAMPLE DKIM DNS RECORD:
selector1._domainkey.yourdomain.com TXT

Record Value:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

BREAKDOWN:
v=DKIM1         → DKIM version
k=rsa           → Key type (RSA is standard)
p=MIGfMA0...    → Public key (base64 encoded)

EMAIL HEADER EXAMPLE:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; 
  s=selector1; c=relaxed/relaxed; 
  h=from:to:subject:date:message-id; 
  bh=abc123...; b=xyz789...

KEY COMPONENTS:
d=    → Signing domain
s=    → Selector (allows multiple keys per domain)
h=    → Headers included in signature
b=    → The actual signature

DMARC (Domain-based Message Authentication)

DMARC builds on SPF and DKIM by specifying what should happen when authentication fails. It also adds alignment requirements and provides reporting on authentication results across all emails sent from your domain.

DMARC policies tell receivers: "If an email claims to be from my domain but fails SPF and DKIM, here's what you should do." Options range from monitoring only (p=none) to quarantine (send to spam) to reject (block entirely).

DMARC also requires alignment—the domain in your From header must match the domain verified by SPF or DKIM. This prevents attackers from passing SPF with one domain while spoofing another in the visible From address.

EXAMPLE DMARC RECORD:
_dmarc.yourdomain.com TXT

Record Value:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

BREAKDOWN:
v=DMARC1            → DMARC version (required)
p=quarantine        → Policy for failed emails
rua=mailto:...      → Address for aggregate reports
pct=100             → Percentage of mail to apply policy

POLICY OPTIONS:
p=none       → Monitor only, take no action (start here)
p=quarantine → Send failed emails to spam
p=reject     → Block failed emails entirely

RECOMMENDED PROGRESSION:
1. p=none      → Monitor for 2-4 weeks, review reports
2. p=quarantine → Enforce gradually, monitor for issues
3. p=reject    → Full enforcement once confident

How the Three Protocols Work Together

Setup Checklist

EMAIL AUTHENTICATION SETUP CHECKLIST:

SPF SETUP:
□ Identify all services that send email for your domain
□ Create TXT record at yourdomain.com with SPF syntax
□ Include all sending services (ESP, CRM, help desk, etc.)
□ End with -all or ~all (prefer -all when confident)
□ Test with MXToolbox or similar tool

DKIM SETUP:
□ Generate DKIM keys in your email service provider
□ Create DNS TXT record at selector._domainkey.yourdomain.com
□ Enable DKIM signing for outgoing mail
□ Test signature with email to mail-tester.com

DMARC SETUP:
□ Start with p=none policy for monitoring
□ Create TXT record at _dmarc.yourdomain.com
□ Set up mailbox to receive aggregate reports
□ Review reports for 2-4 weeks before enforcement
□ Progress to p=quarantine, then p=reject

VERIFICATION:
□ Send test emails and check headers for pass/fail
□ Monitor Google Postmaster Tools for authentication rates
□ Review DMARC reports regularly for failures

Common Mistakes to Avoid

• Forgetting to include all sending services in SPF—every service that sends email for your domain must be listed
• Exceeding the 10 DNS lookup limit in SPF—use flattening or consolidation to stay under the limit
• Using the wrong DKIM selector—each email service has its own selector, and they must match DNS records
• Jumping straight to p=reject without monitoring—this can block legitimate email if configuration is incomplete
• Ignoring DMARC reports—these reports reveal authentication failures you need to address
• Not updating records when adding new sending services—authentication fails for the new service until DNS is updated

Best Practices for Email Authentication

• Implement all three protocols—SPF and DKIM provide verification; DMARC provides policy and reporting
• Start DMARC with p=none and monitor before enforcement—SendroAI helps you interpret reports
• Keep SPF records under 10 lookups—combine or flatten includes if approaching the limit
• Use 2048-bit keys for DKIM when possible—provides stronger cryptographic security
• Set up subdomain policies if needed—DMARC can specify different policies for subdomains
• Review aggregate reports regularly—they reveal misconfigurations and unauthorized sending attempts
• Test after any DNS changes—use tools like MXToolbox, DMARC Analyzer, or Mail Tester
• Progress to full DMARC enforcement within 90 days—p=none provides no protection against spoofing