SPF, DKIM, and DMARC: The Complete Email Authentication Guide

Your emails are going to spam. Or worse — they're being rejected outright. Before you blame your email provider, check your DNS records. Missing or misconfigured SPF, DKIM, and DMARC records are the number one cause of email deliverability problems.

This guide explains what each record does, how to set them up, and how to verify they're working.

Email was designed in an era when trust was assumed. Anyone can send an email claiming to be from any domain — there's no built-in verification. SPF, DKIM, and DMARC are DNS-based standards that fix this by letting receiving mail servers verify that an email actually came from who it claims to be from.

Without them:

• Your emails are more likely to land in spam
• Your domain can be spoofed by phishers
• Major providers (Gmail, Outlook) may reject your messages entirely

SPF is a TXT record that lists which mail servers are authorized to send email on behalf of your domain.

How it works: When a receiving server gets an email from your domain, it checks your DNS for an SPF record and verifies the sending server's IP is on the approved list.

Basic SPF record format:

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

Breaking this down:

• v=spf1 — declares this is an SPF record
• include:_spf.google.com — authorizes Google's mail servers (for Google Workspace)
• ~all — soft fail for anything not listed (mark as suspicious but don't reject)

Common all mechanisms:

• ~all — soft fail (recommended while testing)
• -all — hard fail (reject unauthorized senders — use once you're confident)
• ?all — neutral (no policy — not recommended)

For common providers:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Mailchimp: include:servers.mcsv.net

You can only have one SPF record per domain. If you use multiple sending services, combine them: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

DKIM adds a cryptographic signature to outgoing emails. The receiving server uses a public key published in your DNS to verify the signature, confirming the email wasn't tampered with in transit.

How it works: Your mail server signs each outgoing email with a private key. The corresponding public key is published as a TXT record in your DNS at selector._domainkey.yourdomain.com.

Finding your DKIM record: Your email provider generates the key pair and gives you the TXT record to add to DNS. The "selector" is a label chosen by your provider (e.g., google, mail, s1).

Example DKIM record location:

google._domainkey.yourdomain.com

Example DKIM record value:

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

You don't need to generate this yourself — your email provider (Google Workspace, Microsoft 365, etc.) provides the exact record to add. Look in their admin console under "Email authentication" or "DKIM setup."

DMARC builds on SPF and DKIM by telling receiving servers what to do when authentication fails — and sending you reports about what's happening.

DMARC record location: _dmarc.yourdomain.com (TXT record)

Basic DMARC record:

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

Policy options (p=):

• none — monitor only, take no action (start here)
• quarantine — send failing emails to spam
• reject — reject failing emails entirely

Recommended rollout:

1. Start with p=none and collect reports for 2–4 weeks
2. Review reports to identify legitimate sending sources you may have missed
3. Move to p=quarantine once you're confident
4. Move to p=reject for maximum protection

DMARC reporting tags:

• rua= — aggregate reports (daily summary, sent to this email)
• ruf= — forensic reports (individual failure reports)
• pct= — percentage of messages to apply policy to (useful for gradual rollout)

After adding all three records, verify them with a DNS lookup:

1. SPF: Look up TXT records for yourdomain.com — find the record starting with v=spf1
2. DKIM: Look up TXT records for selector._domainkey.yourdomain.com
3. DMARC: Look up TXT records for _dmarc.yourdomain.com

You can also send a test email to mail-tester.com — it gives you a score and flags any authentication issues.

Multiple SPF records — You can only have one. Merge all includes into a single record.

Wrong DKIM selector — The selector must match what your mail provider uses. Check their documentation.

Jumping straight to p=reject — Always start with p=none and review reports first. Jumping to reject can block legitimate emails if your SPF/DKIM isn't perfectly configured.

Forgetting subdomains — DMARC applies to the domain it's set on. If you send from mail.yourdomain.com, you may need separate records or use the sp= tag to set subdomain policy.

• SPF lists authorized sending servers — add it as a TXT record on your root domain
• DKIM adds a cryptographic signature — your email provider gives you the record to add
• DMARC sets the policy for failures and sends you reports — start with p=none
• All three work together; having only one or two provides incomplete protection
• Verify all three records are present and valid before considering your setup complete

Properly configured email authentication is one of the highest-impact DNS changes you can make. It protects your domain's reputation, improves deliverability, and stops phishers from impersonating you.