How to Set Up SPF, DKIM, and DMARC for Email Deliverability (Complete DNS Guide)

If your emails are landing in spam — or getting silently rejected — the first thing to check is your email authentication. SPF, DKIM, and DMARC are the three DNS-based protocols that tell receiving mail servers: "This email legitimately came from us, and it wasn't tampered with."

Without all three configured correctly, Gmail, Yahoo, and Outlook will either dump your emails into spam or block them entirely at the SMTP level. Since 2024, this isn't optional — Google and Yahoo require SPF, DKIM, and DMARC for any sender pushing more than 5,000 emails per day. In 2026, Microsoft followed suit.

I've configured these records on dozens of sending domains — for cold email infrastructure, transactional email, and marketing campaigns running through PowerMTA and MailWizz. This guide is the exact process I follow every time, with real DNS record examples and the validation commands I run to confirm everything works.

1. What Are SPF, DKIM, and DMARC? (Quick Overview)

Before jumping into DNS records, here's what each protocol does in one sentence:

SPF — Who Can Send on Your Behalf

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and servers authorized to send email from your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks your SPF record to see if the sending server's IP is on the list. If not, SPF fails.

DKIM — Proving the Email Wasn't Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic digital signature to the headers of every outgoing email. The receiving server uses a public key published in your DNS to verify this signature. If the email content or headers were modified in transit, the signature won't match and DKIM fails.

DMARC — The Policy That Ties It All Together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do when SPF or DKIM checks fail. It also adds an alignment requirement — meaning the domain in the visible "From" header must match the domain used in SPF or DKIM. DMARC also gives you reporting, so you can see who is sending email using your domain.

How All Three Work Together

Here's what happens when Gmail receives an email from your domain:

1. SPF check: Gmail looks up your SPF record and checks if the sending IP is authorized → Pass or Fail
2. DKIM check: Gmail retrieves your DKIM public key from DNS and verifies the email's cryptographic signature → Pass or Fail
3. DMARC check: Gmail checks if at least one of SPF or DKIM both passed AND aligned with the From domain. Then it reads your DMARC policy to decide what to do with failures.

2. Why Email Authentication Is Mandatory

Google, Yahoo, and Microsoft's Bulk Sender Requirements

As of 2026, all major inbox providers enforce these requirements for bulk senders (5,000+ emails/day to their users):

What Happens If You Don't Set Up Authentication

Without proper authentication, your emails don't just go to spam — in 2026, they're rejected at the SMTP level:

• Gmail: Returns 550-5.7.26 — "This mail is unauthenticated... rejected due to domain's DMARC policy"
• Yahoo: Returns 553 5.7.2 — "Sender domain authentication not aligned"
• Outlook: Silently routes to spam or returns 550 5.7.515 for DMARC failures

Your domain is also vulnerable to spoofing — anyone can send phishing emails pretending to be you, and without DMARC at p=reject, receiving servers have no instruction to block those fakes.

3. Step 1 — Set Up Your SPF Record

How SPF Works

SPF is a single TXT record published at your domain root. When a receiving server gets an email with a Return-Path (envelope sender) of @yourdomain.com, it queries yourdomain.com for TXT records and looks for one starting with v=spf1.

The record lists the authorized sending sources using mechanisms:

Building Your SPF Record (Exact Syntax)

Here's my standard SPF record for a domain sending through a dedicated PowerMTA server:

v=spf1 ip4:198.51.100.25 -all

Translation: "Only the server at 198.51.100.25 is authorized to send email for this domain. Reject everything else."

SPF Record Examples for Common Setups

Google Workspace only:

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

Google Workspace + SendGrid:

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

Dedicated SMTP server (PowerMTA) + Google Workspace:

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

Multiple dedicated IPs + Mailchimp + HubSpot:

v=spf1 ip4:198.51.100.25 ip4:198.51.100.26 include:servers.mcsv.net include:_spf.hubspot.com include:_spf.google.com -all

The SPF 10 DNS Lookup Limit (and How to Fix It)

This trips up almost everyone who uses multiple email services. The SPF specification (RFC 7208) limits SPF records to a maximum of 10 DNS lookups. Each include, a, mx, and redirect mechanism counts as one lookup — and nested includes count too.

If your SPF record exceeds 10 lookups, the entire SPF check returns a permanent error (permerror) — which means SPF fails for every email.

How to check your lookup count:

# Use MXToolbox SPF checker:
# https://mxtoolbox.com/spf.aspx

# Or count manually — each of these = 1 lookup:
include:_spf.google.com        # 1 (but _spf.google.com itself has nested includes)
include:sendgrid.net           # 1
include:servers.mcsv.net       # 1
include:_spf.hubspot.com       # 1
a                              # 1
mx                             # 1

How to fix it when you exceed 10 lookups:

1. Remove services you no longer use — audit your SPF record quarterly
2. Replace include with ip4 — if a service has stable IPs, use direct IP entries instead (these don't count toward the limit)
3. Use subdomains for different services — send marketing email from marketing.yourdomain.com with its own SPF record, transactional from mail.yourdomain.com
4. Remove a and mx mechanisms — unless your web server or MX server actually sends email, you don't need these

Validating Your SPF Record

# Check your SPF record from the command line:
dig TXT yourdomain.com +short | grep spf

# Expected output:
"v=spf1 ip4:198.51.100.25 include:_spf.google.com -all"

# Or use nslookup (Windows):
nslookup -type=txt yourdomain.com

Confirm using MXToolbox SPF Checker — it will show you the full lookup chain and flag any errors.

4. Step 2 — Set Up DKIM Signing

How DKIM Works

DKIM uses public-key cryptography. Your mail server signs every outgoing email with a private key. The receiving server looks up the corresponding public key in your DNS (at selector._domainkey.yourdomain.com) and uses it to verify the signature.

If the email body or certain headers were modified after signing (by a relay, forwarding service, or attacker), the signature won't match and DKIM fails.

Generating DKIM Keys

Generate a 2048-bit RSA key pair:

# Generate the private key
openssl genrsa -out dkim_private.key 2048

# Extract the public key
openssl rsa -in dkim_private.key -pubout -out dkim_public.key

# View the public key (you'll need this for DNS)
cat dkim_public.key

The public key output looks like this (headers removed for DNS):

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u
phCdbO0l3W3aTOiyOBQDG3P1WT2R... (continues)

Publishing the DKIM DNS Record

Create a TXT record at selector._domainkey.yourdomain.com. The "selector" is a label you choose — it identifies which key pair to use (useful when rotating keys).

I use a date-based selector format for easy tracking:

# DNS Record:
# Host:  s2026._domainkey.yourdomain.com
# Type:  TXT
# Value:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2uphCdbO0l3W3aTOiyOBQDG3P1WT2R...

Record breakdown:

• v=DKIM1 — DKIM version (always DKIM1)
• k=rsa — key type (RSA is standard)
• p=MII... — your public key (the full base64-encoded key, no line breaks)

Configuring DKIM Signing in PowerMTA

If you run PowerMTA, here's the actual config I use in /etc/pmta/config:

# ── DKIM Signing Configuration ──
domain-key s2026, yourdomain.com, /etc/pmta/keys/yourdomain.com/dkim_private.key


  dkim-sign yes
  dkim-identity @yourdomain.com
  dkim-selector s2026
  dkim-key /etc/pmta/keys/yourdomain.com/dkim_private.key
  dkim-headers from:to:subject:date:message-id:content-type:mime-version

What each directive does:

• dkim-sign yes — enables signing for this domain
• dkim-identity — the d= domain in the DKIM signature (must match your From domain for DMARC alignment)
• dkim-selector — maps to the DNS record at s2026._domainkey.yourdomain.com
• dkim-headers — which headers to include in the signature (always include from)

After updating the config, restart PowerMTA:

sudo pmta reload

Validating Your DKIM Signature

# Check your DKIM DNS record:
dig TXT s2026._domainkey.yourdomain.com +short

# Expected output:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

# Send a test email to a Gmail address, then check the email headers.
# Look for:
# dkim=pass header.d=yourdomain.com header.s=s2026

Or send an email to mail-tester.com — it will tell you if DKIM passes and show you the exact signature details.

5. Step 3 — Set Up Your DMARC Policy

How DMARC Works

DMARC is a TXT record published at _dmarc.yourdomain.com. It does three things:

1. Requires alignment — at least one of SPF or DKIM must pass AND align with the From domain
2. Sets a policy — tells receiving servers what to do with emails that fail authentication
3. Enables reporting — sends you aggregate and forensic reports about authentication results

DMARC Policy Options: none vs quarantine vs reject

Building Your DMARC Record

Here's my standard DMARC record:

# DNS Record:
# Host:  _dmarc.yourdomain.com
# Type:  TXT
# Value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=r; aspf=r; pct=100; fo=1

Tag breakdown:

My Recommended DMARC Rollout Strategy

Don't jump straight to p=reject. Here's the safe progression I follow:

1. Week 1-4: p=none — Monitor reports, identify all legitimate sending sources, fix any alignment issues
2. Week 5-8: p=quarantine; pct=25 — Quarantine 25% of failing emails, watch for false positives
3. Week 9-10: p=quarantine; pct=100 — Full quarantine
4. Week 11+: p=reject — Full protection. Unauthorized emails are blocked completely.

Understanding DMARC Reports (rua and ruf)

Aggregate reports (rua) are daily XML files sent by receiving servers. They contain:

• Which IP addresses sent email using your domain
• SPF and DKIM pass/fail results for each source
• DMARC alignment results
• Volume of emails per sending source

Parsing raw XML is painful. Use a free DMARC report analyzer:

• dmarcian.com (free tier)
• Postmark DMARC Digests (free weekly summaries)
• EasyDMARC (free tier with dashboards)

Focus on two things in your reports:

1. Unauthorized senders — IPs sending email from your domain that aren't yours (potential spoofing)
2. Legitimate sources failing alignment — your own services that are passing SPF/DKIM but failing DMARC because the domains don't align

6. SPF vs DKIM vs DMARC — Quick Comparison

7. Understanding Alignment (The #1 Reason "Everything Looks Right But It Still Fails")

This is where most email authentication guides stop — and where most deliverability problems actually begin.

Alignment means the domain in the visible From header must match the domain used in SPF or DKIM. DMARC requires at least one of these alignments to pass.

What Is SPF Alignment?

SPF alignment compares:

• From header domain (what the recipient sees): you@yourdomain.com
• Return-Path domain (envelope sender, often hidden): bounce@yourdomain.com

If both are yourdomain.com (or subdomains in relaxed mode), SPF alignment passes.

Common failure: Many ESPs set the Return-Path to their own domain (e.g., bounce.sendgrid.net). SPF passes for SendGrid's domain, but it doesn't align with your From domain — so DMARC sees an SPF alignment failure.

What Is DKIM Alignment?

DKIM alignment compares:

• From header domain: you@yourdomain.com
• DKIM d= domain (in the DKIM signature): d=yourdomain.com

If both match (or are subdomains in relaxed mode), DKIM alignment passes.

This is why DKIM alignment is often your lifeline. Even if SPF alignment fails (because the ESP uses their own Return-Path), DKIM alignment can still pass if the ESP signs with your domain's key.

Relaxed vs Strict Alignment

My recommendation: Start with relaxed alignment (adkim=r; aspf=r). Only move to strict if you have a specific security requirement that demands it. Relaxed mode allows subdomains to align, which is necessary for many legitimate sending configurations.

How to Diagnose and Fix Alignment Failures

Send a test email to a Gmail address, then view the original message headers. Look for these three lines:

Return-Path: <bounce@yourdomain.com>           ← SPF checks this domain
From: you@yourdomain.com                        ← DMARC compares against this
DKIM-Signature: ... d=yourdomain.com; s=s2026;  ← DKIM checks this domain

If SPF alignment fails (Return-Path domain ≠ From domain):

• Configure your ESP to use a custom Return-Path on your domain
• Or rely on DKIM alignment instead (if the ESP signs with your domain key)

If DKIM alignment fails (d= domain ≠ From domain):

• Configure your ESP/mail server to sign with your domain, not theirs
• In PowerMTA, verify the dkim-identity matches your From domain

8. Multi-Domain and Subdomain Authentication

Setting Up Auth for Outreach Domains

If you use separate domains for cold outreach (which you should — never send cold email from your primary brand domain), each domain needs its own complete authentication:

• Separate SPF record at each domain root
• Separate DKIM key pair and DNS record per domain
• Separate DMARC record at _dmarc.outreachdomain.com

I typically register 3-5 outreach domains per brand (e.g., trybrand.com, getbrand.io, brandmail.co) and configure each with identical authentication. For more on this setup, see my email warmup guide.

Subdomain Inheritance Rules

This catches people by surprise:

• SPF does NOT inherit. If you send from mail.yourdomain.com, you need an SPF record at mail.yourdomain.com — not just at yourdomain.com.
• DMARC cascades to subdomains. A DMARC record at _dmarc.yourdomain.com applies to all subdomains unless overridden. You can use the sp= tag to set a different policy for subdomains: sp=reject.
• DKIM is selector-specific. The selector DNS record determines which key to use. You can have different selectors for different subdomains.

9. Post-Setup Maintenance (What Nobody Tells You)

Setting up authentication once isn't enough. Your DNS records need ongoing maintenance — and most guides completely ignore this.

DKIM Key Rotation Schedule

Rotate your DKIM keys every 6 to 12 months. Here's my process:

1. Generate a new key pair with a new selector (e.g., s2026b)
2. Publish the new public key in DNS at the new selector
3. Update your mail server config to sign with the new key
4. Keep the old selector active in DNS for 72 hours — emails in transit still need to validate against the old key
5. Remove the old selector after 72 hours

SPF Record Auditing

Every time you add or remove an email service (new ESP, CRM, helpdesk tool), update your SPF record. I audit SPF records quarterly using this checklist:

• Are all include mechanisms still needed?
• Have any services changed their SPF domains?
• Am I still under the 10-lookup limit?
• Are there any IP addresses that should be added or removed?

Ongoing DMARC Report Monitoring

Review your DMARC aggregate reports at least monthly. Watch for:

• New unauthorized sending sources (potential spoofing attempts)
• Legitimate services that started failing (often after the service updates their infrastructure)
• Spikes in authentication failures that correlate with deliverability drops

10. Validation and Testing Checklist

Command-Line Validation

# ── Check SPF ──
dig TXT yourdomain.com +short | grep spf
# Expected: "v=spf1 ip4:198.51.100.25 ... -all"

# ── Check DKIM ──
dig TXT s2026._domainkey.yourdomain.com +short
# Expected: "v=DKIM1; k=rsa; p=MIIBIj..."

# ── Check DMARC ──
dig TXT _dmarc.yourdomain.com +short
# Expected: "v=DMARC1; p=none; rua=mailto:..."

# ── Windows users (use nslookup instead of dig) ──
nslookup -type=txt yourdomain.com
nslookup -type=txt s2026._domainkey.yourdomain.com
nslookup -type=txt _dmarc.yourdomain.com

Online Validation Tools

Sending a Test Email and Reading the Headers

Send an email to a Gmail address. Open the email → click the three dots → "Show original." Look for these authentication results:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of bounce@yourdomain.com designates 198.51.100.25 as permitted sender)
  dkim=pass header.d=yourdomain.com header.s=s2026
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

All three should show pass. If any shows fail or softfail, check the specific error message — it will tell you exactly what went wrong.

11. Common Mistakes and Troubleshooting

Frequently Asked Questions

What to Do Next

Once your SPF, DKIM, and DMARC records are live and validated:

1. Monitor your DMARC reports for 2-4 weeks at p=none to catch any alignment issues
2. Warm up your sending IPs and domains — follow my 6-week email warmup schedule to build reputation gradually
3. Set up Google Postmaster Tools to track your domain reputation and spam complaint rates
4. Progress your DMARC policy from none → quarantine → reject as you verify all sources pass
5. If you get blacklisted, follow my domain blacklist recovery guide to restore your reputation

Email authentication isn't a set-it-and-forget-it task. Audit your SPF record every time you add or remove a sending service. Rotate your DKIM keys on a schedule. And check your DMARC reports regularly to catch unauthorized use of your domain.

If you're building a complete email sending infrastructure from scratch, start with my PowerMTA configuration guide — it covers server setup, Virtual MTAs, IP rotation, and MailWizz integration. This guide (SPF/DKIM/DMARC) is the authentication layer that sits on top of that infrastructure.