You've got 50,000 subscribers, a beautiful welcome sequence, and open rates that make you want to frame your Klaviyo dashboard. Then one day, your emails start landing in spam. All of them. Every. Single. One. (If this is happening to you right now, our guide on preventing emails from going to spam has the quick fixes.)
I've been there. Spent three weeks blaming my subject lines, my send times, even my email copy before someone finally asked: "Did you check your authentication records?"
My response? "My what?"
Turns out, email authentication is the unsexy technical foundation that determines whether inbox providers trust you or treat you like a Nigerian prince. And most marketers have no idea it exists until everything breaks.
What Is Email Authentication (And Why Should You Care)?
Email authentication is a set of protocols that prove your emails are actually from you and not some scammer pretending to be you.
Think of it like this: anyone can write "From: nike@nike.com" in an email header. Without authentication, inbox providers have no way to verify that Nike actually sent that message. This is why phishing exists.
The three protocols you need:
| Protocol | What It Does | Analogy |
|---|---|---|
| SPF | Lists which servers can send email for your domain | A guest list at a club |
| DKIM | Adds a digital signature to prove the email wasn't altered | A wax seal on a letter |
| DMARC | Tells providers what to do if SPF or DKIM fail | The bouncer's instructions |
Here's why this matters to your bottom line: the average email deliverability rate is just 83.1%, according to Email Tool Tester's testing across 15 ESPs. That means roughly 17% of your emails never reach the inbox.
If you're sending 100,000 emails a month, that's 17,000 messages going nowhere. And the #1 reason? Authentication failures.
SPF: Who's Allowed to Send Your Emails
SPF (Sender Policy Framework) is a DNS record that lists every server authorized to send email on behalf of your domain.
When someone receives an email "from" your domain, their email server checks your SPF record. If the sending server isn't on the list? Suspicious. Possibly spam.
What an SPF record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
This says: "Google and SendGrid are allowed to send emails for my domain. Anyone else? Be suspicious."
The mistake everyone makes: Adding your ESP, forgetting about your CRM, your helpdesk software, your invoicing tool, your calendar booking app... then wondering why half your transactional emails land in spam.
Every service that sends email on your behalf needs to be in your SPF record. I once spent two days debugging deliverability issues because someone forgot we'd added a new survey tool that sent post-purchase emails.
SPF limitations to know:
- Only 10 DNS lookups allowed (yes, there's a limit)
- Only checks the envelope sender, not the "From" header
- Breaks when emails are forwarded
SPF alone isn't enough. That's where DKIM comes in.
DKIM: Proving Your Email Wasn't Tampered With
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your email headers. This signature proves two things:
- The email actually came from your domain
- Nobody altered the content in transit
When you send an email, your server uses a private key to sign it. The receiving server uses your public key (published in DNS) to verify that signature.
If the signature doesn't match? Either you didn't send it, or someone messed with it. Either way, red flag.
Why DKIM matters more than SPF:
SPF breaks when emails are forwarded. DKIM doesn't. The signature travels with the email, so it still passes authentication even after bouncing through multiple servers.
Setting up DKIM:
Your ESP handles most of this. You just need to add their DKIM record to your DNS. It looks something like:
k1._domainkey.yourdomain.com
With a TXT value that's a long string of characters (your public key).
The mistake I see constantly: Using your ESP's shared sending domain instead of authenticating your own domain. Yes, it's easier. But you're building someone else's sender reputation, not yours.
When you switch ESPs (and you will eventually), you start from zero.
DMARC: The Bouncer That Ties It All Together
DMARC (Domain-based Message Authentication, Reporting & Conformance) does two things:
- Tells receiving servers what to do when SPF or DKIM fail
- Sends you reports so you can see who's using your domain
DMARC policies:
| Policy | What It Does | When to Use |
|---|---|---|
p=none | Monitor only, don't block anything | Starting out, gathering data |
p=quarantine | Send failures to spam | After you've fixed issues |
p=reject | Block failures completely | When you're confident |
A basic DMARC record:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
This says: "Send authentication failures to spam, and email me reports about it."
The stat that should terrify you: Only 15-18% of domains have a valid DMARC record. Meanwhile, Google and Yahoo now require DMARC for anyone sending more than 5,000 emails per day.
No DMARC? Your bulk emails might not reach Gmail or Yahoo inboxes at all. Period.
Since these requirements kicked in, there's been a 65% reduction in unauthenticated email reaching Gmail inboxes. The inbox providers aren't playing around anymore.
How to Set Up Email Authentication (Step by Step)
Step 1: Audit your current setup
Use a free tool like MXToolbox or dmarcian to check what records you currently have. You might be surprised (I once found SPF records from an ESP we'd stopped using three years earlier).
Step 2: List every service that sends email for you
This includes:
- Your ESP (Klaviyo, Mailchimp, etc.)
- Your CRM
- Your helpdesk
- Your invoicing software
- Your booking/calendar tool
- Your survey tools
- Anything else that sends automated emails
Miss one and you'll have deliverability issues.
Step 3: Set up SPF
Add or update your SPF record in DNS to include all authorized senders. Stay under 10 lookups, or SPF will fail.
Step 4: Set up DKIM
Your ESP will give you the DKIM records to add. Add them. Verify they're working.
Step 5: Set up DMARC
Start with p=none so you can monitor without breaking anything. After 2-4 weeks of clean reports, move to p=quarantine. Eventually, p=reject.
Step 6: Monitor regularly
Authentication isn't set-and-forget. Every time you add a new tool or change ESPs, you need to update your records. Set a quarterly reminder to audit.
For more on keeping your emails out of spam, check out our guide on how to improve email deliverability.
Common Authentication Mistakes (And How to Avoid Them)
Mistake 1: Too many SPF lookups
Every include: statement in your SPF record triggers a DNS lookup. More than 10 and SPF fails completely. If you're using multiple services, consider an SPF flattening tool.
Mistake 2: Jumping straight to DMARC reject
Going from no DMARC to p=reject is like going from couch potato to marathon runner overnight. You will hurt yourself. Start with p=none, review reports, fix issues, then escalate gradually.
Mistake 3: Forgetting about subdomains
If you send from marketing.yourdomain.com and support.yourdomain.com, each needs its own authentication. DMARC can help here with subdomain policies.
Mistake 4: Not warming up new sending infrastructure
Even with perfect authentication, a brand new domain or IP needs proper warmup. Authentication proves you're legitimate. Warmup builds trust with inbox providers.
Mistake 5: Ignoring DMARC reports
Those XML reports are ugly, but they tell you exactly who's sending email as your domain (including attackers). Use a free DMARC report analyzer to make sense of them.
FAQ
What's the difference between SPF and DKIM?
SPF verifies that the sending server is authorized to send for your domain. DKIM verifies that the email content wasn't altered and actually came from someone with access to your domain's private key. You need both.
Do I really need all three (SPF, DKIM, DMARC)?
Yes. Since 2024, Gmail and Yahoo require all three for bulk senders (5,000+ emails per day). Even if you send less, having all three significantly improves deliverability.
Will setting up authentication fix my spam problems?
It fixes authentication-related spam problems. If your emails are landing in spam because of bad content, poor list hygiene, or reputation issues, authentication alone won't save you. Check out our guide on preventing emails from going to spam for the full picture.
How long does it take for authentication changes to work?
DNS changes typically propagate within 24-48 hours. However, seeing the full impact on deliverability can take days to weeks as inbox providers adjust their trust scores.
Can I set up authentication myself or do I need a developer?
If you're comfortable editing DNS records, you can do it yourself. Most ESPs have step-by-step guides. That said, getting it wrong can break your email, so if you're unsure, having a developer verify your work isn't a bad idea.
What happens if I don't set up DMARC?
Your emails may get blocked or sent to spam by major providers like Gmail and Yahoo. You also have zero visibility into who might be spoofing your domain to send phishing emails.