SPF, DKIM, and DMARC: The Complete Email Authentication Guide (2026)

If your emails are landing in spam — or worse, someone is sending phishing emails using your domain — the root cause is almost always missing or misconfigured email authentication.

SPF, DKIM, and DMARC are the three DNS-based protocols that prove to every inbox provider (Gmail, Outlook, Yahoo) that your emails are legitimate. As of 2026, all three are mandatory for bulk senders after Google, Yahoo, and Microsoft enforced their updated requirements. Domains without proper authentication are being filtered, junked, or rejected outright.

This guide explains exactly what each protocol does, how to set them up, how to verify your configuration, and how to go from p=none to full enforcement — without accidentally blocking your own email.

What Is Email Authentication and Why Does It Matter?

Email was designed in the 1970s without any identity verification. Anyone could send an email claiming to be from ceo@yourcompany.com. That design flaw is exploited billions of times a day for phishing, spoofing, and spam.

Email authentication solves this by letting you publish cryptographic and DNS-based records that receiving servers can check. When Gmail receives an email claiming to be from your domain, it checks three things:

• SPF — is this email coming from a server I've authorised?
• DKIM — does this email carry a valid cryptographic signature from my domain?
• DMARC — given the above, what should I do with emails that fail, and where should I send reports?

Domains with all three protocols configured correctly are 2.7× more likely to reach the inbox compared to unauthenticated domains. More critically, without DMARC enforcement, anyone can send emails that appear to come from your domain — damaging your brand and your sender reputation before you've sent a single campaign.

Protocol 1: SPF (Sender Policy Framework)

What SPF Does

SPF lets you publish a list of servers and IP addresses that are authorised to send email on behalf of your domain. When a receiving mail server gets an email from newsletter@migomail.com, it checks your DNS for an SPF record and asks: "Is the sending server on the approved list?"

If yes → SPF passes.
If no → SPF fails, and the email is more likely to be filtered.

How to Create Your SPF Record

SPF records are TXT records published in your domain's DNS. The syntax looks like this:

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

Breaking this down:

SPF Setup Steps

1. Log in to your DNS provider (Cloudflare, GoDaddy, Route 53, etc.)
2. Go to your domain's DNS management panel
3. Add a new TXT record:
   • Host/Name: @ (or your domain, depending on the provider)
   • Value: your SPF string (example above)
   • TTL: 3600 (1 hour) or lower for testing
4. Save and wait for DNS propagation (typically 10–30 minutes, up to 48 hours)

Common SPF Mistakes to Avoid

The 10-lookup limit: SPF allows a maximum of 10 DNS lookups to resolve your record. Each include: statement counts as a lookup. If you exceed 10, SPF will fail with a permerror. Use an SPF flattening tool to consolidate records if you're near the limit.

Multiple SPF records: You can only have one SPF TXT record per domain. If you have two, receiving servers will not know which to use and SPF will fail. Merge them into a single record.

Forgetting subdomains: Your SPF record for yourdomain.com does not automatically cover mail.yourdomain.com or newsletter.yourdomain.com. Create separate records for each subdomain that sends email.

Verify Your SPF Record

Use MXToolbox or Google Admin Toolbox to verify:

• Go to toolbox.googleapps.com/apps/checkmx
• Enter your domain
• Check for SPF status → should show "Pass"

Protocol 2: DKIM (DomainKeys Identified Mail)

What DKIM Does

DKIM adds a cryptographic digital signature to every email you send. The sending server signs the email with a private key that only you hold. The public key is published in your DNS. When a receiving server gets the email, it checks the DNS for your public key and uses it to verify the signature.

This proves two things:

1. The email genuinely came from your domain's mail servers
2. The email content was not modified in transit

DKIM is particularly important for deliverability because it survives email forwarding (unlike SPF, which breaks when email is forwarded through a third-party server).

How to Set Up DKIM

DKIM setup is done inside your email sending platform — not just your DNS. The platform generates a key pair, gives you the public key as a DNS record, and handles signing automatically from that point forward.

In Migomail:

1. Go to Settings → Email Authentication → DKIM
2. Click Generate DKIM Keys
3. Copy the TXT record provided (it will look like k1._domainkey.yourdomain.com)
4. Add this TXT record to your DNS
5. Return to Migomail and click Verify DKIM

The DKIM DNS record looks like:

k1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Important: The p= value is your long public key. Copy it exactly as provided — any truncation will cause DKIM to fail.

DKIM Selector

The k1 in k1._domainkey is called a DKIM selector. It lets you have multiple DKIM keys for the same domain (useful if you use multiple sending platforms). Each platform that sends on your behalf should have its own DKIM selector and key pair.

Rotate DKIM Keys Periodically

Security best practice is to rotate DKIM keys every 6–12 months. This involves:

1. Generating a new key pair (using a new selector, e.g., k2._domainkey)
2. Publishing the new public key in DNS
3. Switching your sending platform to use the new private key
4. Keeping the old record active for 48–72 hours to avoid failures on in-transit emails
5. Deleting the old record after the transition

Protocol 3: DMARC (Domain-based Message Authentication, Reporting & Conformance)

What DMARC Does

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receiving servers what to do when an email fails authentication, and where to send reports about authentication results.

DMARC also enforces alignment — it requires that the domain in the From: header matches the domain used in SPF or DKIM. This closes the "display name" spoofing loophole where an attacker passes SPF using a different domain but shows your domain in the From header.

DMARC Policy Options

The Right Progression: Start at none, Move to reject

Never start at p=reject. If you jump straight to rejection before auditing all your sending sources, you risk blocking legitimate emails — transactional receipts, password resets, or emails from a CRM you forgot to authorise.

The correct progression is:

Week 1–2:   p=none (collect reports, understand your email ecosystem)
Week 3–4:   p=quarantine (catch clearly unauthorised senders)
Month 2+:   p=reject (full enforcement, maximum protection)

How to Create Your DMARC Record

Add a TXT record to your DNS at _dmarc.yourdomain.com:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1; adkim=s; aspf=s"

Breaking this down:

Tip: Use adkim=r; aspf=r (relaxed) to start — strict alignment can cause issues with subdomains. Move to strict once you've confirmed everything aligns correctly.

Reading DMARC Reports

DMARC aggregate reports (RUA) arrive as XML files, often zipped. They contain data on every sending source that used your domain, including whether SPF and DKIM passed or failed, and from which IP addresses.

Use a DMARC report reader to make sense of them. Migomail's Hosted DMARC service processes these reports automatically and presents them in a clear dashboard — showing you exactly which senders are passing and which are failing, so you can fix issues before moving to enforcement.

Moving to p=reject

Once your DMARC reports consistently show that all legitimate senders are passing authentication (SPF or DKIM aligned), you're ready to enforce:

1. Change p=quarantine → monitor the spam folder for 1–2 weeks
2. If no legitimate emails are being caught, change to p=reject
3. Keep monitoring reports — new sending tools or configuration changes can re-introduce failures

Step-by-Step: Full Authentication Setup Checklist

Use this checklist to confirm you've implemented all three protocols correctly:

SPF

• Single SPF TXT record published at @ (root domain)
• All email sending platforms listed (Migomail, Google Workspace, Salesforce, etc.)
• Total DNS lookups is 10 or fewer
• Verified via MXToolbox → "SPF Pass"

DKIM

• DKIM keys generated in Migomail and all other sending platforms
• TXT records published in DNS for each selector
• DKIM verification completed inside each platform
• Verified via MXToolbox DKIM Lookup → "Valid"

DMARC

• _dmarc.yourdomain.com TXT record published
• RUA email address set up and monitored
• Currently at p=none and receiving/reviewing reports
• Timeline set for progression to p=quarantine and p=reject

Alignment

• The domain in your From: header matches your SPF/DKIM domain
• Subdomains that send email have their own SPF and DMARC records

Why This Matters More Than Ever in 2026

Google and Yahoo (February 2024)

Both platforms require SPF, DKIM, and DMARC for anyone sending more than 5,000 emails per day to their users. Non-compliant senders face filtering and eventual rejection.

Microsoft Outlook (May 2026)

Microsoft extended the same requirements to Outlook.com, Hotmail.com, and Live.com. Starting May 5, 2026, high-volume senders without proper authentication are being routed to junk or rejected.

Together, Gmail, Outlook, and Yahoo account for over 80% of consumer email addresses globally. Non-compliance means a significant portion of every campaign you send never reaches the inbox.

The Enforcement Shift

Google's updated Postmaster Tools v2 (launched October 2026) no longer shows "High/Medium/Low" reputation — it now shows a binary Compliance Status: Pass or Fail. Partial compliance delivers the same result as no compliance: inbox failure.

Beyond Authentication: MTA-STS and BIMI

Once SPF, DKIM, and DMARC are in place, two additional protocols extend your email security posture:

MTA-STS (Mail Transfer Agent Strict Transport Security) enforces encrypted (TLS) delivery of emails to your domain and prevents downgrade attacks where an attacker intercepts email by negotiating unencrypted delivery. Migomail's MTA-STS service handles publishing and hosting the policy file automatically.

BIMI (Brand Indicators for Message Identification) lets you display your brand logo next to your emails in Gmail and Apple Mail. It requires a verified mark certificate (VMC) and a p=quarantine or p=reject DMARC policy. This is a visible trust signal that improves open rates alongside security.

Frequently Asked Questions

What is the difference between SPF, DKIM, and DMARC?
SPF verifies that the sending server is authorised to send for your domain. DKIM adds a cryptographic signature to verify the email's authenticity and integrity. DMARC is the policy layer that uses the results of SPF and DKIM to decide what to do with failing emails, and generates reports so you can monitor your domain's email activity. All three work together — SPF and DKIM provide the data, DMARC enforces the policy.

Do I need all three, or can I start with just SPF?
You need all three for full protection and compliance with current mailbox provider requirements. SPF alone provides no protection against display-name spoofing. DKIM alone has no enforcement mechanism. DMARC requires both SPF and DKIM to be in place to function correctly. Implementing only one or two leaves significant gaps.

What happens if I set DMARC to p=reject too early?
Legitimate emails from sending sources you haven't yet authorised (a CRM, a form tool, a third-party integration) will be rejected and never delivered. This can block transactional emails like order confirmations or password resets. Always start with p=none, analyse your DMARC reports to identify all sending sources, and progress through p=quarantine before reaching p=reject.

How long does it take to set up SPF, DKIM, and DMARC?
The DNS records themselves take 15–30 minutes to create. DNS propagation takes up to 48 hours. The entire process from start to p=none DMARC monitoring typically takes less than one business day. Moving to full enforcement (p=reject) should take 4–8 weeks to allow time to analyse reports and ensure no legitimate senders are being caught.

Will DMARC stop all phishing attacks using my domain?
DMARC with p=reject will block emails that fail SPF and DKIM alignment — which covers the majority of spoofing attempts. It will not stop attackers who register lookalike domains (e.g., miig0mail.com) — that requires brand monitoring and domain registration. Migomail's Email Threat Intelligence service monitors for both.

Does SPF cover subdomains?
No. An SPF record published at yourdomain.com does not automatically apply to mail.yourdomain.com or any other subdomain. Each subdomain that sends email needs its own SPF record. For DMARC, you can use the sp= tag to apply your root domain's DMARC policy to subdomains (sp=reject).

How do I check if my SPF, DKIM, and DMARC are set up correctly?
Send a test email to a Gmail or Outlook account and view the original message headers. Look for Authentication-Results — you should see spf=pass, dkim=pass, and dmarc=pass. You can also use MXToolbox, Google Admin Toolbox, or Migomail's built-in deliverability checker to verify your DNS records directly.

Summary

Email authentication is no longer optional — it's the foundation of inbox delivery. The three protocols work as a system:

1. SPF → Authorise your sending servers in DNS
2. DKIM → Sign every email with a cryptographic key
3. DMARC → Set enforcement policy and receive reports

Start with p=none to gather data, verify that all your legitimate senders are passing, then progress to p=quarantine and finally p=reject over 4–8 weeks. Once all three are in place at enforcement level, your domain is protected from spoofing and your inbox placement rates will improve measurably.

Migomail handles DKIM key generation, DMARC report processing, and one-click SPF record validation directly inside the platform. Start your free trial or book a deliverability audit to get your full authentication stack reviewed by our team.