domaindetails.com
Knowledge Base/Domain Management/Understanding DMARC, SPF, and DKIM for Email Authentication (2025)
Domain Management

Understanding DMARC, SPF, and DKIM for Email Authentication (2025)

Complete guide to email authentication protocols: SPF, DKIM, and DMARC. Learn how to set up email security, prevent spoofing, and improve deliverability with step-by-step instructions.

18 min
Published 2025-12-01
Updated 2025-12-01
By DomainDetails Team

Quick Answer

SPF, DKIM, and DMARC are three email authentication protocols that work together to prevent email spoofing and improve deliverability. SPF specifies which mail servers can send email for your domain, DKIM adds a digital signature to verify message integrity, and DMARC defines what happens when authentication fails and provides reporting. Implementing all three protocols is essential for professional email delivery, protecting your domain from phishing attacks, and maintaining sender reputation with major email providers like Gmail and Outlook.

Table of Contents

Introduction to Email Authentication

Email authentication is a critical component of modern email infrastructure. Without proper authentication, your domain is vulnerable to spoofing, phishing attacks, and poor email deliverability.

Why Email Authentication Matters

Email was designed in an era when security wasn't a primary concern. The Simple Mail Transfer Protocol (SMTP) allows anyone to send email claiming to be from any domain. This vulnerability has been exploited for decades by spammers and phishers who forge sender addresses to trick recipients.

Email authentication protocols solve this problem by enabling receiving mail servers to verify that messages actually come from authorized sources.

The Business Impact

Poor email authentication affects your business in multiple ways:

Deliverability Issues: Major email providers (Gmail, Outlook, Yahoo) increasingly require proper authentication. Messages from unauthenticated domains are more likely to land in spam or be rejected entirely.

Brand Protection: Without authentication, attackers can send phishing emails that appear to come from your domain, damaging your reputation and potentially harming your customers.

Legal Compliance: Many industries require proper email security measures. Authentication protocols help demonstrate due diligence in protecting communications.

Sender Reputation: Email providers track sender reputation. Properly authenticated emails build trust and improve long-term deliverability.

The Three Pillars of Email Authentication

Modern email authentication relies on three complementary protocols:

  1. SPF (Sender Policy Framework): Validates that email comes from authorized servers
  2. DKIM (DomainKeys Identified Mail): Cryptographically signs messages to verify authenticity
  3. DMARC (Domain-based Message Authentication, Reporting & Conformance): Defines policies for handling authentication failures

Together, these protocols create a comprehensive defense against email spoofing while providing visibility into who's sending email on your behalf.

Who Needs Email Authentication?

Everyone sending email should implement authentication, including:

  • Businesses sending transactional emails (receipts, notifications, password resets)
  • Marketing teams running email campaigns
  • Organizations using custom domain email (Google Workspace, Microsoft 365)
  • Domain investors protecting their portfolio from spoofing
  • Personal brands using custom domain email addresses

Even if you don't send high volumes of email, authentication protects your domain's reputation and ensures important messages reach recipients.

What is SPF (Sender Policy Framework)?

SPF is the foundational email authentication protocol. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain.

How SPF Works

When you send an email, the receiving mail server performs an SPF check:

  1. Receiving server extracts the sender's domain from the "envelope from" address
  2. Server queries DNS for the domain's SPF record (a TXT record)
  3. SPF record lists authorized mail server IP addresses or includes
  4. Server compares the sending server's IP to the authorized list
  5. If the IP matches: SPF passes; if not: SPF fails

This simple check prevents attackers from forging your domain as the sender, since their mail servers won't be listed in your SPF record.

SPF Record Structure

An SPF record is a DNS TXT record with specific syntax:

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

SPF Record Components:

  • v=spf1: Version identifier (always v=spf1)

  • Mechanisms: Define authorized senders

    • ip4: IPv4 address or CIDR range
    • ip6: IPv6 address or CIDR range
    • include: Include another domain's SPF policy
    • a: Authorize IPs from domain's A record
    • mx: Authorize IPs from domain's MX record
    • all: Default action for unlisted senders

  • Qualifiers: Define how to handle matches

    • + (Pass): Authorized - +ip4:192.0.2.1 (+ is default, usually omitted)
    • - (Fail): Not authorized, reject - -all
    • ~ (Soft Fail): Not authorized, accept but mark - ~all
    • ? (Neutral): No policy - ?all

SPF Examples

Basic SPF (Company with Single Mail Server):

example.com.    TXT    "v=spf1 mx -all"

Authorizes only the servers listed in MX records. Strict policy rejects everything else.

Google Workspace SPF:

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

Authorizes Google's mail servers. Soft fail on others (accept but flag as suspicious).

Multiple Services (Google Workspace + SendGrid):

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Authorizes both Google and SendGrid mail servers.

Specific IP Address + Service:

example.com.    TXT    "v=spf1 ip4:203.0.113.1 ip4:203.0.113.2 include:_spf.google.com -all"

Authorizes specific IP addresses plus Google's mail servers.

All Mail Servers on Network:

example.com.    TXT    "v=spf1 ip4:192.0.2.0/24 -all"

Authorizes an entire subnet using CIDR notation.

SPF Limitations and Considerations

10 DNS Lookup Limit:

SPF records are limited to 10 DNS lookups during validation. Each include:, a:, mx:, and ptr: mechanism counts as a lookup. Exceeding this limit causes SPF to fail.

Example of Too Many Lookups:

v=spf1 include:service1.com include:service2.com include:service3.com include:service4.com include:service5.com include:service6.com include:service7.com include:service8.com include:service9.com include:service10.com include:service11.com -all

This will fail because it exceeds 10 lookups.

Solutions for SPF Lookup Limits:

  1. Use IP addresses instead of includes when possible
  2. Consolidate services: Choose email providers that group services under one include
  3. Create nested SPF records: Use subdomains to split lookups
  4. Remove unused services: Clean up old email service providers

SPF Doesn't Protect "From" Address:

SPF validates the "envelope from" (MAIL FROM) address, not the "header from" address users see. Attackers can forge the visible from address while passing SPF. This is why DMARC is essential—it ensures SPF and DKIM align with the header from address.

SPF Breaks with Email Forwarding:

When email is forwarded, the forwarding server sends the message, but SPF checks against the original domain's policy. This can cause legitimate forwarded email to fail SPF checks. DKIM handles forwarding better since the signature travels with the message.

SPF Qualifiers Explained

The qualifier determines what receiving servers should do with SPF results:

Strict Policy (-all):

v=spf1 include:_spf.google.com -all
  • Recommended for maximum security
  • Tells receivers to reject email that fails SPF
  • Use when you're confident all legitimate sources are listed

Soft Fail (~all):

v=spf1 include:_spf.google.com ~all
  • Recommended during initial deployment
  • Allows email through but marks it as suspicious
  • Good for testing before enforcing strict policy

Neutral (?all):

v=spf1 include:_spf.google.com ?all
  • Provides no guidance on handling failures
  • Not recommended for production use
  • Only useful during testing

Pass (+all):

v=spf1 +all
  • Never use this!
  • Allows anyone to send email as your domain
  • Defeats the entire purpose of SPF

Multiple SPF Records

You cannot have multiple SPF records for the same domain. DNS allows multiple TXT records, but only one SPF record is permitted. If multiple SPF records exist, the behavior is undefined—some receivers use the first, others use the last, and some consider all SPF checks failed.

Incorrect (Multiple SPF Records):

example.com.    TXT    "v=spf1 include:_spf.google.com -all"
example.com.    TXT    "v=spf1 include:sendgrid.net -all"

Correct (Single SPF Record):

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Understanding DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to email headers, allowing receiving servers to verify that messages haven't been tampered with and actually came from the claimed sender.

How DKIM Works

DKIM uses public-key cryptography:

  1. Sending server generates a private/public key pair
  2. Public key is published in DNS as a TXT record
  3. Private key is kept secret on the sending mail server
  4. When sending email, server signs specific headers and body with private key
  5. Signature is added to email headers as DKIM-Signature
  6. Receiving server retrieves public key from DNS
  7. Verifies signature using public key
  8. If signature matches: DKIM passes; if not: DKIM fails

This cryptographic proof ensures the message wasn't modified in transit and originated from a server with access to the private key.

DKIM Record Structure

DKIM records are published at a specific subdomain using a selector:

selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

DKIM Record Components:

  • Selector: Identifier for the key (selector._domainkey.domain.com)
  • v=DKIM1: DKIM version
  • k=rsa: Key type (almost always RSA)
  • p=: Public key in base64 encoding
  • t=s: (Optional) Test mode
  • t=y: (Optional) Domain testing DKIM
  • h=: (Optional) Acceptable hash algorithms
  • s=: (Optional) Service types

DKIM Selectors Explained

The selector allows multiple DKIM keys for one domain. This enables:

Key Rotation: Generate new keys without disrupting existing signatures

2024._domainkey.example.com
2025._domainkey.example.com

Service-Specific Keys: Different keys for different email services

google._domainkey.example.com
mailchimp._domainkey.example.com
sendgrid._domainkey.example.com

Subdomain Keys: Separate keys for subdomains

default._domainkey.example.com
default._domainkey.mail.example.com

The sending server specifies which selector to use in the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
    h=from:to:subject:date; bh=abc123...; b=def456...

The s=google tells receiving servers to look up the public key at google._domainkey.example.com.

DKIM Signature Headers

A DKIM signature appears in the email headers:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=20240101;
    c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn0BCrFOBFMhY=;
    b=ABC123DEF456...

Signature Components:

  • v=1: DKIM version
  • a=rsa-sha256: Algorithm used (RSA with SHA-256)
  • d=example.com: Signing domain
  • s=20240101: Selector name
  • c=relaxed/relaxed: Canonicalization algorithm
  • h=: List of signed headers
  • bh=: Body hash (hash of message body)
  • b=: Signature (encrypted hash)
  • t=: Timestamp when signed
  • x=: Signature expiration time

What DKIM Signs

DKIM can sign specific email headers and the message body:

Commonly Signed Headers:

  • From (required for DMARC alignment)
  • To
  • Subject
  • Date
  • Message-ID
  • Reply-To
  • Content-Type

Why Not All Headers?

Some headers are added or modified during transmission (like Received headers). DKIM only signs headers that should remain unchanged. The h= tag lists which headers were included in the signature.

DKIM Key Lengths

DKIM keys come in different lengths:

1024-bit Keys:

  • Minimum recommended length
  • Smaller DNS records
  • Adequate for most use cases
  • Some providers are phasing out 1024-bit

2048-bit Keys:

  • Current standard
  • Better security
  • Larger DNS records (may require special handling)
  • Recommended for long-term use

4096-bit Keys:

  • Maximum security
  • Very large DNS records (often require splitting)
  • Slower to process
  • Overkill for most situations

Most email services now use 2048-bit keys as the default.

DKIM and Email Forwarding

DKIM handles email forwarding better than SPF because the signature travels with the message. However, forwarding can still break DKIM if:

Message Modification: Forwarding server modifies content (disclaimer footers, formatting changes)

Original message: DKIM passes
Forwarded with footer: DKIM fails (body hash mismatch)

Header Changes: Required headers are added or modified

Subject: Original subject (signed)
Subject: [Fwd] Original subject (signature fails)

Solution: ARC (Authenticated Received Chain) preserves authentication results through forwarding, but adoption is still growing.

Multiple DKIM Records

Unlike SPF, you can and should have multiple DKIM records using different selectors:

google._domainkey.example.com.       TXT    "v=DKIM1; k=rsa; p=MIGfMA0..."
sendgrid._domainkey.example.com.     TXT    "v=DKIM1; k=rsa; p=MIHbMA0..."
mailchimp._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGaMA0..."

Each email service uses its own selector and key pair. This provides:

  • Independent key management per service
  • No conflicts between providers
  • Easy service addition/removal
  • Simplified key rotation

DMARC Explained (Domain-based Message Authentication)

DMARC builds on SPF and DKIM by defining what receiving servers should do when authentication fails and providing feedback on email authentication results.

How DMARC Works

DMARC ties together SPF and DKIM authentication:

  1. Email arrives at receiving server
  2. SPF check performed on envelope from address
  3. DKIM check performed on signature
  4. DMARC check verifies alignment:
    • Does SPF pass AND align with header from domain?
    • Does DKIM pass AND align with header from domain?
  5. DMARC policy determines action if alignment fails
  6. Report sent to domain owner about authentication results

DMARC ensures that SPF and DKIM authenticate the domain users actually see (the "From" header), not just technical envelope addresses.

DMARC Record Structure

DMARC records are published at _dmarc.domain.com:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r"

DMARC Tags:

Required Tags:

  • v=DMARC1: Version (required)
  • p=: Policy for domain (none, quarantine, reject)

Optional Tags:

  • sp=: Subdomain policy (none, quarantine, reject)
  • rua=: Aggregate report email address
  • ruf=: Forensic report email address
  • pct=: Percentage of messages to filter (1-100)
  • adkim=: DKIM alignment mode (r=relaxed, s=strict)
  • aspf=: SPF alignment mode (r=relaxed, s=strict)
  • fo=: Forensic reporting options
  • rf=: Forensic report format
  • ri=: Report interval (seconds)

DMARC Policies

DMARC offers three policy levels:

p=none (Monitor Mode):

_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]"
  • No action taken on failed messages
  • Reports sent to monitor authentication
  • Use when first implementing DMARC
  • Collects data without risking email delivery

p=quarantine (Spam Folder):

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"
  • Failed messages moved to spam/junk folder
  • Good middle ground for enforcement
  • pct=10 applies policy to only 10% of messages (gradual rollout)
  • Use after analyzing reports from p=none

p=reject (Block Delivery):

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"
  • Failed messages rejected entirely
  • Strongest protection against spoofing
  • Use after successful quarantine testing
  • Recommended goal for all domains

DMARC Alignment

DMARC requires that SPF and/or DKIM "align" with the From header domain. This prevents attackers from passing authentication while displaying a different domain to users.

SPF Alignment:

The domain in the envelope from must match the domain in the From header.

Relaxed Alignment (aspf=r):

Envelope From: [email protected]
Header From:   [email protected]
Result: ✅ Aligned (organizational domain matches)

Strict Alignment (aspf=s):

Envelope From: [email protected]
Header From:   [email protected]
Result: ❌ Not aligned (exact domain must match)

DKIM Alignment:

The domain in the DKIM signature (d= tag) must match the From header domain.

Relaxed Alignment (adkim=r):

DKIM d=subdomain.example.com
Header From: [email protected]
Result: ✅ Aligned (organizational domain matches)

Strict Alignment (adkim=s):

DKIM d=subdomain.example.com
Header From: [email protected]
Result: ❌ Not aligned (exact domain must match)

Relaxed vs. Strict:

Most organizations use relaxed alignment (r) because:

  • Allows legitimate subdomains to send email
  • Works with common email infrastructure patterns
  • Sufficient for most security needs

Use strict alignment (s) only if:

  • You never send email from subdomains
  • Maximum security is required
  • You can test thoroughly before deploying

DMARC Pass Criteria

For DMARC to pass, at least one of these must be true:

  1. SPF passes AND aligns with From header domain
  2. DKIM passes AND aligns with From header domain

You don't need both SPF and DKIM to pass—either one is sufficient. This provides redundancy:

SPF: Pass + Aligned = ✅ DMARC Pass
DKIM: Fail
Overall: ✅ DMARC Pass

SPF: Fail
DKIM: Pass + Aligned = ✅ DMARC Pass
Overall: ✅ DMARC Pass

SPF: Pass but not aligned
DKIM: Pass but not aligned
Overall: ❌ DMARC Fail

DMARC Reports

DMARC provides two types of reports:

Aggregate Reports (RUA):

  • Daily XML reports summarizing authentication results
  • Show authentication pass/fail rates
  • List sources sending email for your domain
  • Identify legitimate senders missing from SPF/DKIM
  • Essential for monitoring and troubleshooting

Forensic Reports (RUF):

  • Real-time reports of individual failures
  • Include message headers and content samples
  • Help diagnose specific authentication issues
  • Privacy concerns (may contain sensitive data)
  • Many providers don't send forensic reports anymore

Example DMARC with Reports:

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Report Tags:

  • rua=mailto:[email protected]: Where to send aggregate reports
  • ruf=mailto:[email protected]: Where to send forensic reports
  • fo=0: Generate forensic report if all mechanisms fail (default)
  • fo=1: Generate forensic report if any mechanism fails
  • fo=d: Generate forensic report if DKIM fails
  • fo=s: Generate forensic report if SPF fails

Subdomain DMARC Policy

The sp= tag defines policy for subdomains:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; sp=quarantine"
  • p=reject: Apply reject policy to main domain
  • sp=quarantine: Apply quarantine policy to subdomains

If sp= is omitted, subdomains inherit the main domain policy.

Subdomain-Specific DMARC:

You can publish separate DMARC records for specific subdomains:

_dmarc.marketing.example.com.    TXT    "v=DMARC1; p=none"
_dmarc.example.com.              TXT    "v=DMARC1; p=reject"

This allows different policies for different subdomains.

DMARC Implementation Stages

Stage 1: Monitoring (p=none)

_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]"
  • Deploy for 2-4 weeks
  • Collect and analyze reports
  • Identify all legitimate email sources
  • Fix SPF and DKIM issues

Stage 2: Soft Enforcement (p=quarantine)

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"
  • Start with low percentage (pct=10)
  • Gradually increase to 100% over weeks
  • Monitor reports for delivery issues
  • Ensure legitimate email isn't quarantined

Stage 3: Full Enforcement (p=reject)

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"
  • Deploy after successful quarantine testing
  • Provides maximum protection
  • Blocks spoofed email entirely
  • Continue monitoring reports

Timeline: Plan 4-12 weeks for full implementation, depending on email volume and complexity.

How SPF, DKIM, and DMARC Work Together

These three protocols complement each other to create comprehensive email authentication.

The Authentication Stack

┌──────────────────────────────────────┐
│ DMARC (Policy & Reporting)           │
│ - Defines what to do with failures   │
│ - Requires alignment                 │
│ - Provides visibility                │
└──────────────┬───────────────────────┘
               │ Checks alignment with
               ▼
┌──────────────────────────────────────┐
│ SPF (Sender Validation)              │
│ - Validates mail server              │
│ - Checks envelope from               │
│ - Prevents unauthorized senders      │
└──────────────────────────────────────┘

┌──────────────────────────────────────┐
│ DKIM (Cryptographic Signature)       │
│ - Verifies message integrity         │
│ - Proves sender authentication       │
│ - Survives forwarding better         │
└──────────────────────────────────────┘

Authentication Flow Example

Scenario: [email protected] sends email via Google Workspace to [email protected]

Step 1: Email Sent

Step 2: Gmail Receives Email

  • Extracts sending server IP: 209.85.220.41

Step 3: SPF Check

  • Queries DNS: example.com TXT
  • Finds: v=spf1 include:_spf.google.com -all
  • Resolves Google's SPF: includes 209.85.220.41
  • Result: SPF Pass
  • Alignment Check: envelope from (example.com) matches header from (example.com)
  • Result: SPF Aligned

Step 4: DKIM Check

  • Extracts selector from DKIM-Signature: s=google
  • Queries DNS: google._domainkey.example.com TXT
  • Retrieves public key
  • Verifies signature against email headers and body
  • Result: DKIM Pass
  • Alignment Check: DKIM domain (d=example.com) matches header from (example.com)
  • Result: DKIM Aligned

Step 5: DMARC Check

  • Queries DNS: _dmarc.example.com TXT
  • Finds: v=DMARC1; p=reject; rua=mailto:[email protected]
  • Checks if SPF or DKIM passed with alignment
  • SPF: Pass + Aligned ✅
  • DKIM: Pass + Aligned ✅
  • Result: DMARC Pass

Step 6: Delivery Decision

  • DMARC passes: deliver to inbox
  • Applies domain reputation
  • Email reaches recipient's inbox

Step 7: Reporting

  • Gmail generates aggregate report
  • Sends to [email protected] (rua address)
  • Report shows: 1 message passed DMARC

What Happens When Authentication Fails

Scenario: Attacker tries to spoof example.com

Attack Setup:

  • Attacker controls spammer.evil.com
  • Sends email claiming: From: [email protected]
  • Sends via their own mail server (IP: 198.51.100.50)

SPF Check:

  • Gmail queries: example.com TXT
  • Finds: v=spf1 include:_spf.google.com -all
  • Checks if 198.51.100.50 is authorized
  • Result: SPF Fail (IP not in SPF record)

DKIM Check:

  • Attacker doesn't have private key for example.com
  • Either no DKIM signature, or signature from different domain
  • Result: DKIM Fail

DMARC Check:

  • Queries: _dmarc.example.com TXT
  • Finds: v=DMARC1; p=reject
  • Checks alignment: Both SPF and DKIM failed
  • Result: DMARC Fail

Action Based on Policy:

  • Policy is p=reject
  • Gmail rejects the message entirely
  • Sender receives bounce notification
  • Email never reaches intended victim
  • Forensic report sent to example.com (if ruf configured)

Why All Three Are Necessary

SPF Alone:

  • ✅ Prevents unauthorized mail servers
  • ❌ Doesn't verify message content
  • ❌ Breaks with email forwarding
  • ❌ Doesn't protect visible "From" address

DKIM Alone:

  • ✅ Verifies message integrity
  • ✅ Survives forwarding
  • ❌ Can sign messages from any domain
  • ❌ Doesn't verify sender authorization

DMARC Ties It Together:

  • ✅ Requires alignment with visible From address
  • ✅ Defines enforcement policy
  • ✅ Provides visibility through reports
  • ✅ Protects brand from spoofing

Best Practice: Implement all three protocols for complete email security.

Setting Up SPF Records

Step-by-step guide to creating and publishing SPF records.

Step 1: Identify Your Email Sources

Before creating an SPF record, list all services that send email for your domain:

Common Email Sources:

  • Email hosting: Google Workspace, Microsoft 365, custom mail server
  • Marketing platforms: Mailchimp, SendGrid, Constant Contact
  • Transactional email: Sendgrid, Mailgun, Amazon SES
  • Website contact forms: Web hosting server
  • Help desk software: Zendesk, Freshdesk, Intercom
  • CRM systems: Salesforce, HubSpot
  • E-commerce: Shopify, WooCommerce
  • Notification systems: Application servers, monitoring tools

How to Find Email Sources:

  1. Review all services connected to your domain
  2. Check which services send email notifications
  3. Analyze email headers from sent messages
  4. Ask team members about email tools they use

Step 2: Gather SPF Information

For each email source, find its SPF include statement or IP addresses:

Google Workspace:

include:_spf.google.com

Microsoft 365:

include:spf.protection.outlook.com

SendGrid:

include:sendgrid.net

Mailchimp:

include:servers.mcsv.net

Custom Mail Server:

ip4:203.0.113.1

Most email services provide SPF information in their documentation under "Email Authentication," "DNS Settings," or "Domain Setup."

Step 3: Build Your SPF Record

Combine all sources into a single SPF record:

Template:

v=spf1 [mechanisms] [qualifier]

Example (Google Workspace + SendGrid):

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

Example (Multiple Services):

v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.salesforce.com ip4:203.0.113.1 -all

Step 4: Validate SPF Record

Before publishing, validate your SPF record:

Check SPF Syntax:

Verify Lookup Count:

  • Ensure total lookups ≤ 10
  • Each include:, a:, mx:, ptr: counts as one lookup
  • Includes cascade (includes within includes count)

Example Lookup Count:

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

Direct lookups: 2 (google + sendgrid)
Google's includes: 3 (internal includes)
SendGrid's includes: 1
Total: 6 lookups ✅

Step 5: Publish SPF Record

Add your SPF record as a TXT record in DNS:

DNS Record Details:

  • Type: TXT
  • Name: @ (or your domain name)
  • Value: v=spf1 include:_spf.google.com -all
  • TTL: 3600 (1 hour) or your DNS provider's default

Common DNS Providers:

Cloudflare:

  1. Log into Cloudflare dashboard
  2. Select your domain
  3. Click "DNS"
  4. Click "Add record"
  5. Type: TXT, Name: @, Content: your SPF record
  6. Click "Save"

GoDaddy:

  1. Log into GoDaddy Domain Manager
  2. Select your domain
  3. Click "DNS"
  4. Click "Add" → "TXT"
  5. Name: @, Value: your SPF record
  6. Click "Save"

Namecheap:

  1. Log into Namecheap account
  2. Domain List → Manage
  3. Advanced DNS tab
  4. Add New Record → TXT Record
  5. Host: @, Value: your SPF record
  6. Click green checkmark

Google Domains:

  1. Log into Google Domains
  2. Click your domain
  3. DNS → Custom records
  4. Create new record → TXT
  5. Host name: @, Data: your SPF record
  6. Click "Add"

Step 6: Wait for DNS Propagation

DNS changes take time to propagate:

Step 7: Test SPF Record

After propagation, verify your SPF record is working:

Command Line Test (Mac/Linux):

dig example.com TXT

Command Line Test (Windows):

nslookup -type=TXT example.com

Online Tools:

Send Test Email:

  1. Send email from your domain to Gmail
  2. Open the email in Gmail
  3. Click "Show original"
  4. Look for: spf=pass

SPF Record Maintenance

Quarterly Review:

  • Audit all email sending sources
  • Remove unused services from SPF
  • Verify lookup count remains under 10
  • Test deliverability after changes

When to Update SPF:

  • Adding new email service
  • Removing old email service
  • Changing mail servers
  • Migrating email providers
  • IP address changes

Version Control: Before updating SPF:

  1. Document current SPF record
  2. Note reason for change
  3. Test new SPF syntax
  4. Update DNS
  5. Monitor for delivery issues

Configuring DKIM Records

DKIM setup requires generating keys and publishing public keys in DNS.

Step 1: Generate DKIM Keys

DKIM requires a public/private key pair. How you generate keys depends on your email provider.

Google Workspace DKIM:

  1. Log into Google Admin console
  2. Go to Apps → Google Workspace → Gmail → Authenticate email
  3. Click "Generate New Record" for your domain
  4. Select 2048-bit key
  5. Google generates keys and provides DNS record

Microsoft 365 DKIM:

  1. Log into Microsoft 365 Admin Center
  2. Go to Settings → Domains
  3. Select your domain
  4. Click "Enable DKIM"
  5. Microsoft provides two CNAME records to add to DNS

Custom Mail Server (Postfix/OpenDKIM):

# Generate 2048-bit key
opendkim-genkey -b 2048 -d example.com -s 20250101

# Creates two files:
# 20250101.private (keep secret on mail server)
# 20250101.txt (publish in DNS)

SendGrid DKIM:

  1. Log into SendGrid
  2. Settings → Sender Authentication
  3. Domain Authentication → Authenticate Your Domain
  4. Follow wizard, SendGrid provides DNS records

Mailchimp DKIM:

  1. Log into Mailchimp
  2. Account → Settings → Domains
  3. Add and verify domain
  4. Mailchimp provides DKIM records

Step 2: Understand Your DKIM Record

DKIM records have three parts:

1. Selector Subdomain:

selector._domainkey.example.com
  • selector: Unique identifier (google, 20250101, default, etc.)
  • _domainkey: Standard DKIM prefix
  • example.com: Your domain

2. Record Type:

  • Always TXT record (some providers use CNAME to point to TXT)

3. Record Value:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Step 3: Publish DKIM Record in DNS

Add the DKIM TXT record to your DNS:

Standard TXT Record:

DNS Record Details:

  • Type: TXT
  • Name: selector._domainkey (e.g., google._domainkey)
  • Value: v=DKIM1; k=rsa; p=MIGf...
  • TTL: 3600

CNAME Method (Microsoft 365):

Microsoft 365 uses CNAMEs instead of direct TXT records:

Record 1:

  • Type: CNAME
  • Name: selector1._domainkey
  • Value: selector1-example-com._domainkey.example.onmicrosoft.com
  • TTL: 3600

Record 2:

  • Type: CNAME
  • Name: selector2._domainkey
  • Value: selector2-example-com._domainkey.example.onmicrosoft.com
  • TTL: 3600

Step 4: Handle Long DKIM Records

2048-bit DKIM keys produce long TXT records that may exceed DNS limits.

DNS TXT String Limits:

  • Single string: 255 characters max
  • Total record: Up to 4096 characters (concatenated strings)

String Splitting:

If your DKIM key is longer than 255 characters, split it:

Original (too long):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... [500 characters]

Split into Multiple Strings:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC" "rest of key here..."

How to Split:

Most DNS providers automatically split long records. If manual splitting required:

"v=DKIM1; k=rsa; p=[first 220 characters]" "[next 220 characters]" "[remaining characters]"

DNS automatically concatenates quoted strings when resolving.

Step 5: Multiple DKIM Keys

If you use multiple email services, add DKIM records for each:

google._domainkey.example.com.       TXT    "v=DKIM1; k=rsa; p=MIGfMA0..."
sendgrid._domainkey.example.com.     TXT    "v=DKIM1; k=rsa; p=MIHbMA0..."
mailchimp._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGaMA0..."

Each service uses its own selector, preventing conflicts.

Step 6: Wait for DNS Propagation

DKIM records propagate like other DNS changes:

Step 7: Test DKIM

Command Line Test:

dig google._domainkey.example.com TXT

Online DKIM Validator:

Email Test:

  1. Send email from your domain
  2. Send to Gmail or another major provider
  3. View email source/headers
  4. Look for: dkim=pass

Gmail Header Example:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass [email protected] header.s=google header.b=abc123;
       dmarc=pass

Step 8: Enable DKIM Signing

After DNS records are published, enable DKIM signing:

Google Workspace:

  1. Google Admin → Apps → Gmail → Authenticate email
  2. Click "Start Authentication" for your domain
  3. Status changes to "Authenticating email"

Microsoft 365:

  1. After adding CNAME records
  2. Return to Microsoft 365 Admin → Domains
  3. Click "Enable" for DKIM
  4. Status changes to "Enabled"

Custom Mail Server:

  1. Configure OpenDKIM or mail server to use private key
  2. Specify selector in configuration
  3. Restart mail service
  4. Test by sending email

DKIM Key Rotation

Rotate DKIM keys annually for security:

Rotation Process:

  1. Generate new key pair with new selector (e.g., 2026._domainkey)
  2. Publish new public key in DNS
  3. Wait for DNS propagation
  4. Configure mail server to sign with new private key
  5. Wait 48 hours (old signatures still valid)
  6. Remove old DKIM DNS record
  7. Delete old private key from server

No Downtime:

Using new selectors allows seamless rotation:

  • Old key remains active during transition
  • Receivers verify existing emails with old key
  • New emails signed with new key
  • Remove old key only after transition complete

Implementing DMARC Policy

DMARC ties SPF and DKIM together with reporting and policy enforcement.

Step 1: Ensure SPF and DKIM Are Working

Before implementing DMARC:

  • ✅ SPF record published and passing
  • ✅ DKIM keys generated and signing
  • ✅ Both tested with real emails
  • ✅ All legitimate email sources included

Verify Prerequisites:

Send test emails and check headers for:

Authentication-Results:
    spf=pass
    dkim=pass

If either fails, fix SPF or DKIM before proceeding.

Step 2: Set Up DMARC Reporting Email

DMARC sends reports to specified email addresses. You need an email address that can receive potentially high volumes:

Options:

1. Use Your Domain:

[email protected]
  • Simple to set up
  • May receive many reports (hundreds daily for large domains)
  • Requires parsing XML

2. Use DMARC Analysis Service:

rua=mailto:[email protected]

Popular services:

These services parse reports and provide dashboards.

3. Use Multiple Report Addresses:

rua=mailto:[email protected],mailto:[email protected]

Send reports to both your email and a service.

Step 3: Create Initial DMARC Record (p=none)

Start with monitoring-only policy:

_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Tag Breakdown:

  • v=DMARC1: Required version tag
  • p=none: No action taken (monitoring only)
  • rua=mailto:[email protected]: Aggregate reports destination
  • ruf=mailto:[email protected]: Forensic reports destination (optional)
  • fo=1: Generate forensic report if any mechanism fails

Minimal DMARC (No Forensic Reports):

_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]"

Step 4: Publish DMARC Record

Add DMARC TXT record to DNS:

DNS Record Details:

Note: The name is _dmarc (subdomain), not your main domain.

Step 5: Monitor Reports (2-4 Weeks)

After publishing DMARC, collect and analyze reports:

What Reports Tell You:

Aggregate Reports (Daily):

  • Total email volume from your domain
  • Authentication pass/fail rates
  • Sources sending email (IP addresses, services)
  • Alignment results (SPF and DKIM)
  • Which emails would be affected by enforcement

Forensic Reports (Real-time):

  • Individual authentication failures
  • Email headers of failed messages
  • Helps diagnose specific issues

Report Analysis:

Look for:

✅ Good Signs:

  • High SPF pass rates (>95%)
  • High DKIM pass rates (>95%)
  • High DMARC alignment rates
  • Only known sources sending email

⚠️ Warning Signs:

  • Unknown IP addresses sending email
  • Low authentication pass rates
  • Legitimate services failing SPF/DKIM
  • Missing email sources from SPF

Action Items:

  1. Add missing sources to SPF: If legitimate services fail SPF
  2. Enable DKIM for services: If services lack DKIM signatures
  3. Investigate unknown sources: Unknown IPs may indicate spoofing
  4. Fix alignment issues: Ensure From addresses match authenticated domains

Step 6: Gradual Policy Enforcement

After monitoring and fixing issues, gradually enforce policy:

Phase 1: Quarantine 10% (2 weeks):

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"
  • Applies quarantine to 10% of failing messages
  • Monitor reports for delivery issues
  • If no problems, continue

Phase 2: Quarantine 25% (2 weeks):

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

Phase 3: Quarantine 50% (2 weeks):

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]"

Phase 4: Quarantine 100% (2-4 weeks):

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"

Phase 5: Reject Policy (Final):

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

Step 7: Test DMARC

Command Line Test:

dig _dmarc.example.com TXT

Online DMARC Checker:

Email Authentication Test:

  1. Send email from your domain to [email protected]
  2. Receive automated response with authentication results
  3. Verify SPF, DKIM, and DMARC all pass

Gmail Header Check:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass [email protected];
       dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=example.com

Step 8: Configure Subdomain Policy

Protect subdomains with subdomain policy:

Option 1: Inherit Main Domain Policy

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

All subdomains inherit p=reject

Option 2: Separate Subdomain Policy

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"
  • Main domain: reject
  • Subdomains: quarantine

Option 3: Subdomain-Specific DMARC

_dmarc.marketing.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]"

Specific subdomain has own policy

Step 9: Ongoing Monitoring

DMARC implementation isn't "set and forget":

Weekly:

  • Review aggregate reports
  • Check for new unknown sources
  • Monitor authentication pass rates

Monthly:

  • Analyze trends in email volume
  • Review forensic reports (if enabled)
  • Update SPF for new services

Quarterly:

  • Audit all email sources
  • Rotate DKIM keys
  • Review and update policies
  • Test authentication

Testing Email Authentication

Verify your authentication setup is working correctly.

Testing Tools

1. Mail-Tester (https://www.mail-tester.com)

Comprehensive email authentication test:

  1. Visit https://www.mail-tester.com
  2. Copy provided email address
  3. Send test email from your domain
  4. View detailed report on SPF, DKIM, DMARC, and deliverability
  5. Receive score out of 10

2. MXToolbox (https://mxtoolbox.com)

Individual protocol testing:

3. Google Admin Toolbox (https://toolbox.googleapps.com/apps/checkmx/)

Google's DNS and email configuration checker:

  • Enter domain
  • View SPF, DKIM, DMARC, MX records
  • Check for configuration issues

4. DMARC Analyzer (https://www.dmarcanalyzer.com)

Free DMARC testing and reporting:

  • DMARC Record Check
  • SPF Record Check
  • DKIM Record Check
  • Free DMARC reporting service

5. Port25 Authentication Test ([email protected])

Automated email authentication verification:

  1. Send email to [email protected]
  2. Receive detailed authentication report via reply email
  3. Review SPF, DKIM, and DMARC results

Reading Email Headers

Email headers reveal authentication results:

Gmail:

  1. Open email
  2. Click three dots (⋮) → Show original
  3. Look for Authentication-Results

Example Passing Authentication:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender) smtp.mailfrom=example.com;
       dkim=pass [email protected] header.s=google header.b=abc123xyz;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Outlook:

  1. Open email
  2. File → Properties
  3. Internet headers section
  4. Look for Authentication-Results

Apple Mail:

  1. Open email
  2. View → Message → All Headers
  3. Look for Authentication-Results

Manual DNS Queries

Test DNS records directly:

Check SPF:

dig example.com TXT | grep spf
nslookup -type=TXT example.com

Check DKIM:

dig selector._domainkey.example.com TXT
nslookup -type=TXT selector._domainkey.example.com

Check DMARC:

dig _dmarc.example.com TXT
nslookup -type=TXT _dmarc.example.com

Common Test Failures

SPF Fails:

  • Sending server IP not in SPF record
  • SPF record exceeds 10 DNS lookups
  • SPF syntax error
  • No SPF record published

DKIM Fails:

  • Private key doesn't match public key
  • DKIM record not published in DNS
  • Selector mismatch
  • Message modified in transit

DMARC Fails:

  • SPF and DKIM both fail
  • Authentication passes but alignment fails
  • DMARC record syntax error
  • No DMARC record published

Common Email Providers SPF and DKIM Settings

Quick reference for popular email services.

Google Workspace (Gmail)

SPF Record:

v=spf1 include:_spf.google.com ~all

DKIM Setup:

  1. Google Admin → Apps → Gmail → Authenticate email
  2. Generate New Record → Select 2048-bit
  3. Add provided TXT record to DNS: 
    google._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGf..."
  4. Click "Start Authentication"

DMARC Recommendation:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

Documentation: https://support.google.com/a/topic/2759254

Microsoft 365 (Outlook/Exchange Online)

SPF Record:

v=spf1 include:spf.protection.outlook.com ~all

DKIM Setup:

  1. Microsoft 365 Admin → Settings → Domains
  2. Select domain → Enable DKIM
  3. Add two CNAME records: 
    selector1._domainkey.example.com    CNAME    selector1-example-com._domainkey.example.onmicrosoft.com
selector2._domainkey.example.com    CNAME    selector2-example-com._domainkey.example.onmicrosoft.com
  4. Return to admin panel and enable DKIM

DMARC Recommendation:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

Documentation: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-about

SendGrid

SPF Record:

v=spf1 include:sendgrid.net ~all

If using multiple services:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM Setup:

  1. SendGrid → Settings → Sender Authentication
  2. Domain Authentication → Authenticate Your Domain
  3. Add three DNS records provided: 
    s1._domainkey.example.com    CNAME    s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.example.com    CNAME    s2.domainkey.u12345.wl.sendgrid.net
example.com                  CNAME    u12345.wl.sendgrid.net

Documentation: https://docs.sendgrid.com/ui/account-and-settings/how-to-set-up-domain-authentication

Mailchimp

SPF Record:

v=spf1 include:servers.mcsv.net ~all

DKIM Setup:

  1. Mailchimp → Account → Settings → Domains
  2. Add and verify domain
  3. Enable DKIM authentication
  4. Add three CNAME records: 
    k1._domainkey.example.com    CNAME    dkim.mcsv.net
k2._domainkey.example.com    CNAME    dkim2.mcsv.net
k3._domainkey.example.com    CNAME    dkim3.mcsv.net

Documentation: https://mailchimp.com/help/set-up-email-domain-authentication/

Mailgun

SPF Record:

v=spf1 include:mailgun.org ~all

DKIM Setup:

  1. Mailgun → Sending → Domains → Add New Domain
  2. Add DNS records provided: 
    pic._domainkey.example.com    TXT    "k=rsa; p=MIGfMA0GCSqGSIb..."

DMARC: Mailgun provides DMARC record suggestion during setup.

Documentation: https://documentation.mailgun.com/en/latest/user_manual.html#verifying-your-domain

Amazon SES

SPF Record:

v=spf1 include:amazonses.com ~all

DKIM Setup:

  1. SES Console → Verified Identities → Create Identity
  2. Choose domain verification
  3. Add three CNAME records: 
    abc123._domainkey.example.com    CNAME    abc123.dkim.amazonses.com
def456._domainkey.example.com    CNAME    def456.dkim.amazonses.com
ghi789._domainkey.example.com    CNAME    ghi789.dkim.amazonses.com

DMARC Recommendation:

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Documentation: https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication.html

Zoho Mail

SPF Record:

v=spf1 include:zoho.com ~all

DKIM Setup:

  1. Zoho Mail Admin → Email Configuration → DKIM
  2. Add TXT record: 
    zoho._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=MIGfMA0..."

Documentation: https://www.zoho.com/mail/help/adminconsole/spf-configuration.html

Troubleshooting Authentication Issues

Common problems and solutions.

SPF Issues

Problem: SPF Hard Fail

Symptoms:

  • Email rejected or marked as spam
  • Headers show: spf=fail or spf=hardfail

Causes:

  1. Sending server IP not in SPF record
  2. SPF record uses -all (hard fail) and sender isn't authorized
  3. Incorrectly configured SPF record

Solutions:

  1. Add missing IP to SPF: Include IP address or service
  2. Use soft fail during testing: Change -all to ~all
  3. Verify SPF syntax: Use MXToolbox SPF checker

Problem: Too Many DNS Lookups

Symptoms:

  • SPF validation fails
  • Error: "PermError" or "SPF lookup limit exceeded"

Causes:

  • SPF record includes more than 10 DNS lookups
  • Nested includes count toward limit

Solutions:

  1. Replace includes with IPs: Use ip4: instead of include: where possible
  2. Flatten SPF record: Resolve includes to IPs manually
  3. Remove unused services: Clean up old email providers
  4. Use SPF flattening service: Automate IP resolution

Problem: Multiple SPF Records

Symptoms:

  • Inconsistent SPF results
  • Some servers pass, others fail

Causes:

  • Multiple TXT records with v=spf1
  • DNS misconfiguration

Solutions:

  1. Consolidate to single SPF record: Merge all mechanisms into one
  2. Remove duplicate records: Keep only one SPF TXT record

DKIM Issues

Problem: DKIM Signature Not Found

Symptoms:

  • Headers show: dkim=neutral (no sig) or missing DKIM result
  • DKIM signature not in email headers

Causes:

  1. DKIM signing not enabled
  2. Mail server not configured to sign
  3. Service hasn't enabled DKIM for domain

Solutions:

  1. Enable DKIM signing: In email service settings
  2. Configure mail server: Set up OpenDKIM or equivalent
  3. Verify DNS records: Ensure public key published

Problem: DKIM Verification Failed

Symptoms:

  • Headers show: dkim=fail
  • Authentication fails despite DKIM signature present

Causes:

  1. Public key doesn't match private key
  2. Message modified in transit
  3. DNS record incorrect or missing
  4. Selector mismatch

Solutions:

  1. Verify DNS record: Check selector._domainkey.domain.com
  2. Regenerate keys: Create new key pair and republish
  3. Check selector: Ensure selector in signature matches DNS
  4. Test with fresh email: Send new message after fixes

Problem: DKIM Record Not Found

Symptoms:

  • Headers show: dkim=neutral (no key) or dkim=temperror
  • DNS query fails for DKIM record

Causes:

  1. DKIM record not published in DNS
  2. Incorrect selector or domain
  3. DNS propagation incomplete

Solutions:

  1. Publish DKIM record: Add TXT record to DNS
  2. Verify selector: Check exact selector used by mail server
  3. Wait for propagation: Allow 24-48 hours for DNS updates
  4. Test DNS: Query selector._domainkey.domain.com directly

DMARC Issues

Problem: DMARC Alignment Failure

Symptoms:

  • SPF passes but DMARC fails
  • DKIM passes but DMARC fails
  • Headers show: dmarc=fail (alignment failure)

Causes:

  1. SPF authenticated domain doesn't match From domain
  2. DKIM signature domain doesn't match From domain
  3. Using subdomain in one but not others

Solutions:

  1. Check From address: Ensure matches authenticated domain
  2. Use relaxed alignment: Add aspf=r and adkim=r to DMARC
  3. Fix envelope from: Align MAIL FROM with From header
  4. Update DKIM domain: Ensure d= matches From domain

Problem: No DMARC Reports Received

Symptoms:

  • DMARC published for weeks
  • No aggregate or forensic reports received

Causes:

  1. RUA email address incorrect
  2. Reports blocked by spam filter
  3. Low email volume (some providers batch reports)
  4. Receiving server doesn't support DMARC reporting

Solutions:

  1. Verify email address: Test rua=mailto:address is correct
  2. Check spam folder: Look for reports in junk
  3. Use DMARC service: Sign up for Dmarcian or similar
  4. Wait longer: Some providers send weekly reports
  5. Add multiple RUA addresses: Use reporting service + own email

Problem: DMARC Policy Too Strict

Symptoms:

  • Legitimate email blocked or quarantined
  • Partners complain of delivery issues
  • DMARC reports show high failure rate

Causes:

  1. Moved to p=reject or p=quarantine too quickly
  2. Missing email sources in SPF/DKIM
  3. Forwarding services failing authentication

Solutions:

  1. Rollback to p=none: Return to monitoring mode
  2. Analyze reports: Identify failing sources
  3. Add missing sources to SPF: Update SPF record
  4. Enable DKIM for all sources: Ensure signing enabled
  5. Gradual rollout: Use pct= to apply policy to percentage

Email Forwarding Issues

Problem: Forwarded Email Fails Authentication

Symptoms:

  • Email forwarded to Gmail fails DMARC
  • Direct email passes, forwarded email fails
  • Mailing list forwards fail authentication

Causes:

  1. Forwarding server sends with original From address
  2. SPF checks fail (forwarding server not in SPF)
  3. DKIM signature breaks if forwarder modifies message

Solutions:

  1. Use List-ID header: Mailing lists should use List-ID
  2. Enable DKIM signing: Ensure all sources use DKIM (survives forwarding)
  3. Use SRS (Sender Rewriting Scheme): Forwarding services rewrite envelope from
  4. Check for ARC: ARC preserves authentication through forwarders
  5. Use p=quarantine instead of p=reject: Less strict for forwarding scenarios

Best Practices for Email Authentication

SPF Best Practices

1. Start with Restrictive Policy

Use hard fail (-all) after testing:

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

Reject email from unauthorized sources by default.

2. Keep SPF Record Simple

  • Minimize DNS lookups (stay under 10)
  • Use IP ranges instead of individual IPs when possible
  • Document each include statement

3. Audit Regularly

Quarterly SPF review:

  • Remove unused email services
  • Update for new services before first send
  • Verify IP addresses haven't changed

4. Use Include, Not Redirect

Prefer include: over redirect::

✅ v=spf1 include:_spf.google.com -all
❌ v=spf1 redirect=_spf.google.com

Redirect prevents additional mechanisms.

5. Document Your SPF

Maintain documentation:

SPF Record for example.com:
- include:_spf.google.com (Google Workspace email)
- include:sendgrid.net (SendGrid transactional email)
- ip4:203.0.113.1 (Legacy mail server)
- -all (Reject all other sources)

DKIM Best Practices

1. Use 2048-bit Keys

2048-bit is current standard:

opendkim-genkey -b 2048 -d example.com -s 20250101

Provides adequate security and performance.

2. Rotate Keys Annually

Regular key rotation:

  • Generate new key with new selector
  • Publish new public key
  • Switch signing to new key
  • Remove old public key after 48 hours

3. Sign All Outbound Email

Enable DKIM signing for:

  • Primary email service
  • Transactional email platforms
  • Marketing platforms
  • Any service sending email

4. Use Service-Specific Selectors

Organize keys by service:

google._domainkey.example.com
sendgrid._domainkey.example.com
mailchimp._domainkey.example.com

Makes management and troubleshooting easier.

5. Monitor DKIM Pass Rates

Track DKIM authentication:

  • Review DMARC reports for DKIM failures
  • Investigate failing signatures
  • Verify DNS records remain published

DMARC Best Practices

1. Start with p=none

Always begin with monitoring:

v=DMARC1; p=none; rua=mailto:[email protected]

Collect baseline data before enforcement.

2. Use Aggregate Reporting

Enable rua reporting:

rua=mailto:[email protected]

Essential for visibility and troubleshooting.

3. Gradual Policy Enforcement

Rollout timeline:

  • p=none for 2-4 weeks (collect data)
  • p=quarantine with pct=10 for 2 weeks
  • Increase pct= gradually to 100%
  • p=reject after successful quarantine

4. Protect Subdomains

Use sp= tag or subdomain-specific DMARC:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Prevents subdomain spoofing.

5. Monitor Reports Continuously

Ongoing DMARC monitoring:

  • Review reports weekly
  • Investigate unknown sources
  • Track authentication pass rates
  • Update SPF/DKIM as needed

General Best Practices

1. Implement All Three Protocols

Complete email authentication requires:

  • ✅ SPF (sender validation)
  • ✅ DKIM (cryptographic signature)
  • ✅ DMARC (policy and reporting)

Don't skip any component.

2. Test Before Enforcing

Testing checklist:

  • Verify SPF syntax
  • Confirm DKIM signing works
  • Start DMARC with p=none
  • Send test emails to multiple providers
  • Review authentication headers

3. Document Everything

Maintain documentation:

  • Current SPF record and all includes
  • DKIM selectors and rotation schedule
  • DMARC policy and implementation timeline
  • Email services and their authentication
  • Contact information for troubleshooting

4. Use Monitoring Tools

Recommended tools:

  • DMARC reporting service (Dmarcian, DMARC Analyzer)
  • MXToolbox for DNS checks
  • Mail-Tester for comprehensive tests
  • Google Postmaster Tools for Gmail deliverability

5. Educate Your Team

Team awareness:

  • Train IT on email authentication
  • Document procedures for adding email services
  • Create runbooks for common issues
  • Establish review schedule

6. Plan for Growth

Scalable implementation:

  • Use SPF includes that scale (not individual IPs)
  • Implement DKIM for all services from the start
  • Monitor DMARC reports for new legitimate sources
  • Review quarterly as business evolves

Frequently Asked Questions

Do I need all three: SPF, DKIM, and DMARC?

Yes, you should implement all three for complete email authentication. SPF validates sender servers, DKIM signs messages cryptographically, and DMARC ties them together with policy enforcement and reporting. Major email providers (Gmail, Outlook) increasingly require all three for optimal deliverability. Implementing only one or two leaves gaps that spammers can exploit.

How long does it take to implement email authentication?

SPF and DKIM can be set up in 1-2 hours, but DMARC implementation takes 4-12 weeks for safe rollout. You need 2-4 weeks in p=none (monitoring) mode to collect baseline data, then gradual enforcement using pct= over several more weeks. Rushing to p=reject without proper testing can block legitimate email.

Will email authentication prevent all spam and phishing?

No, email authentication prevents spoofing of YOUR domain but doesn't stop all spam. Authentication ensures emails claiming to be from your domain actually come from your authorized servers. It doesn't prevent attackers from using different domains or analyze email content for phishing. Think of it as protecting your brand, not filtering all malicious email.

What happens if I don't implement email authentication?

Without authentication, your domain is vulnerable to spoofing (attackers sending phishing emails appearing to be from you), poor deliverability (major providers may route your email to spam), brand damage (customers receive spoofed emails damaging your reputation), and compliance issues (some industries require email security measures). By 2025, proper authentication is essentially mandatory for professional email.

Can SPF records break email forwarding?

Yes, SPF checks can fail with email forwarding because the forwarding server sends the message, but SPF validates against the original domain. This is why DKIM is important—signatures survive forwarding. Solutions include SRS (Sender Rewriting Scheme) on forwarding servers and ARC (Authenticated Received Chain) to preserve authentication results through forwarding.

How do I know if my email authentication is working?

Send a test email from your domain to Gmail or another major provider, view the message source/headers, and look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header. You can also use online tools like Mail-Tester.com or send to [email protected] for automated testing.

What's the difference between hard fail (-all) and soft fail (~all) in SPF?

Hard fail (-all) tells receiving servers to reject email from unauthorized sources. Soft fail (~all) accepts the email but marks it as potentially suspicious. Use soft fail (~all) during initial testing and transition to hard fail (-all) once you're confident all legitimate sources are in your SPF record. Hard fail provides better security but requires careful testing.

Do I need different DKIM keys for each email service?

Yes, each email service should have its own DKIM key using a unique selector. This allows independent key management, prevents conflicts between services, and makes it easy to add or remove services. For example, Google Workspace might use google._domainkey, while SendGrid uses sendgrid._domainkey.

How often should I rotate DKIM keys?

Rotate DKIM keys annually for security best practices. Generate a new key pair with a new selector, publish the public key in DNS, switch your mail server to sign with the new key, wait 48 hours for existing signatures to age out, then remove the old public key. Using different selectors allows seamless rotation without downtime.

What should my DMARC policy be: none, quarantine, or reject?

Start with p=none for monitoring (2-4 weeks), progress to p=quarantine with gradual rollout (4-8 weeks), and ultimately reach p=reject for maximum protection. The p=reject policy is the goal—it provides the strongest protection by blocking spoofed email entirely. However, jumping straight to reject without testing can block legitimate email.

Key Takeaways

  • Email authentication prevents spoofing by verifying sender identity and message integrity
  • SPF specifies authorized mail servers that can send email for your domain
  • DKIM cryptographically signs messages to prove authenticity and detect tampering
  • DMARC ties SPF and DKIM together with policy enforcement and reporting
  • All three protocols are necessary for complete email security and deliverability
  • DMARC requires alignment between authenticated domains and the visible From address
  • Gradual DMARC rollout is essential starting with p=none, then quarantine, finally reject
  • DMARC reports provide visibility into who's sending email for your domain
  • Email authentication improves deliverability with Gmail, Outlook, and other major providers
  • Regular monitoring and maintenance ensure authentication continues working as infrastructure changes
  • Testing is critical before enforcing strict policies to avoid blocking legitimate email
  • Document your configuration including SPF includes, DKIM selectors, and DMARC policy evolution

Next Steps

Implement Email Authentication

  1. Audit Your Email Infrastructure

    • List all services that send email for your domain
    • Gather SPF includes and IP addresses
    • Determine which services support DKIM
    • Set up email address for DMARC reports

  2. Deploy SPF Record

    • Create SPF record including all email sources
    • Validate syntax and DNS lookup count
    • Publish as TXT record in DNS
    • Test with MXToolbox and send test emails

  3. Configure DKIM Signing

    • Generate key pairs for each email service
    • Publish public keys in DNS using unique selectors
    • Enable DKIM signing in each service
    • Verify signatures in test email headers

  4. Implement DMARC Gradually

    • Publish DMARC with p=none and reporting enabled
    • Monitor reports for 2-4 weeks
    • Fix any SPF/DKIM issues identified
    • Gradually enforce with quarantine then reject policy

Monitor Your Domain with DomainDetails Pro

Upgrade to DomainDetails Pro for advanced email and DNS monitoring:

  • Automatic DNS monitoring - Track SPF, DKIM, and DMARC record changes
  • Email authentication tracking - Monitor authentication status over time
  • Change history - See when authentication records were modified
  • Email alerts - Get notified immediately of DNS or authentication issues
  • Bulk domain checks - Monitor authentication across your entire domain portfolio
  • Export reports - Download authentication data for compliance and analysis

Start Your Free Trial →

Research Sources

  1. RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
  2. RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
  3. RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  4. RFC 8617 - The Authenticated Received Chain (ARC) Protocol
  5. Google Email Sender Guidelines - https://support.google.com/mail/answer/81126
  6. Microsoft 365 Email Authentication - https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-about
  7. DMARC.org - Implementation Resources - https://dmarc.org/overview/
  8. M3AAWG Email Authentication Recommended Best Practices - https://www.m3aawg.org/
  9. Dmarcian Domain Security Guides - https://dmarcian.com/
  10. Internet Society Deploy360 - Email Security - https://www.internetsociety.org/deploy360/