Your domain is warmed. Your copy is tight. Your list is verified. But emails still land in spam. The problem? Authentication.
SPF, DKIM, and DMARC are the three protocols that prove you are who you say you are. When configured correctly, they signal to inbox providers that your emails are legitimate. When misconfigured — or missing entirely — your emails get filtered, blocked, or bounced.
This guide explains each protocol in plain English, shows you how to verify your setup, and covers the configuration mistakes MSPs make most often.
1. SPF: Who Can Send Email From Your Domain
SPF (Sender Policy Framework) tells inbox providers which mail servers are authorized to send email on behalf of your domain. Think of it as a guest list for your email.
How SPF Works:
1. You add a TXT record to your domain's DNS
2. That record lists authorized mail servers (by IP or domain)
3. When you send email, the recipient checks: "Is this server on the list?"
4. If yes → SPF passes. If no → SPF fails, email may be rejected
Example SPF Record:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Breaking down that record:
v=spf1— Declares this is an SPF recordinclude:_spf.google.com— Google Workspace servers are authorizedinclude:sendgrid.net— SendGrid servers are authorized~all— Soft fail for servers not listed (still delivers, but flagged)
Warning
2. DKIM: Cryptographic Proof Your Email Wasn't Altered
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. It proves the email came from your domain and wasn't modified in transit.
How DKIM Works:
1. Your mail server signs each outgoing email with a private key
2. You publish the matching public key in your DNS
3. Recipients decrypt the signature using your public key
4. If it matches → DKIM passes (email is authentic and unmodified)
DKIM is typically set up through your email provider (Google Workspace, Microsoft 365, etc.) rather than manually. They generate the keys; you add their DNS record.
Example DKIM Record (Google Workspace):
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjAN... (long public key)
Pro Tip
3. DMARC: What Happens When Authentication Fails
DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It tells inbox providers what to do when emails fail authentication — and sends you reports.
DMARC Policies:
p=none — Monitor only. Failing emails still deliver. (Start here)
p=quarantine — Send failing emails to spam folder
p=reject — Block failing emails entirely
Example DMARC Record (Monitoring Mode):
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com
Breaking down a DMARC record:
v=DMARC1— Declares this is a DMARC recordp=none— Policy: don't reject/quarantine (monitoring)rua=mailto:...— Where to send aggregate reports
Note
4. The "All Pass" Requirement
Google requires SPF or DKIM for all senders to personal Gmail accounts. Its bulk senders must configure SPF, DKIM and DMARC. Microsoft has a separate high-volume policy for its consumer service. We recommend configuring and testing all three mechanisms even below those thresholds.
Authentication Checklist:
Pro Tip
5. How to Check Your Current Setup
Before sending a single cold email, verify all authentication is working. Here are the tools:
Free Verification Tools:
mxtoolbox.com/SuperTool
Check SPF, DKIM, and DMARC records. Also tests for blacklists.
mail-tester.com
Send a test email and get a deliverability score with specific recommendations.
dmarcanalyzer.com
Parse and visualize DMARC aggregate reports.
postmaster.google.com
See Gmail's view of your domain reputation and authentication rates.
Note
6. Common MSP Misconfigurations
MSPs often manage multiple sending sources (Google Workspace, PSA email notifications, marketing platforms, cold email tools). This complexity breeds authentication errors.
Authentication Setup
Do This
- Include ALL sending sources in SPF
- Set up DKIM for each email platform
- Start DMARC with p=none for monitoring
- Use tools like Valimail to track DMARC reports
- Keep SPF under 10 DNS lookups
Avoid This
- Forget cold email platform in SPF record
- Use multiple SPF records (only one allowed)
- Jump straight to DMARC p=reject
- Ignore DMARC aggregate reports
- Mix transactional and cold email on same domain
Most Common Errors:
1. Multiple SPF records: DNS allows only ONE SPF record per domain. Multiple records = both fail.
2. Too many SPF lookups: Over 10 include:/a:/mx: lookups causes "permerror" — total SPF failure.
3. Missing DKIM for cold email tool: Your cold email platform needs its own DKIM, separate from Google Workspace.
4. DMARC alignment failure: Sending as @yourmsp.com but authenticating via @mailservice.com breaks DMARC.
Warning
7. Troubleshooting Failed Authentication
When authentication fails, start by identifying which protocol is failing and why.
Troubleshooting by Error Type:
SPF Failure: "SPF: FAIL" or "SPF: SOFTFAIL"
The sending server isn't in your SPF record.
Fix: Add the sending platform's servers to your SPF include list.
SPF Permerror: "Too many DNS lookups"
Your SPF record exceeds 10 lookups.
Fix: Use SPF flattening tools to reduce lookup count, or consolidate services.
DKIM Failure: "DKIM: FAIL"
The DKIM signature doesn't match or isn't present.
Fix: Verify DKIM is enabled in your email platform AND the DNS record is published.
DMARC Failure: "DMARC: FAIL"
Neither SPF nor DKIM align with your From domain.
Fix: Ensure at least one of SPF or DKIM authenticates AND aligns with your sending domain.
Best Practice
Key Takeaways
- 1.SPF, DKIM, and DMARC work together. Configure and monitor all three. Authentication is required for bulk senders and does not guarantee inbox placement.
- 2.Google and Microsoft require authentication for bulk senders. Missing authentication means your cold emails hit spam or get blocked.
- 3.Each sending platform needs its own DKIM. Google Workspace, cold email tools, and marketing platforms all need separate configuration.
- 4.Use tools to verify before sending. MXToolbox, Mail-Tester, and Google Postmaster catch issues before they hurt deliverability.
- 5.Start DMARC with p=none, then tighten. Monitor reports for 2-4 weeks before enforcing quarantine or reject policies.