You send an important email to a client. Hours pass. No response. You follow up, only to discover it landed in their spam folder—again. Sound familiar? Welcome to the invisible war between legitimate senders and spam filters, where three acronyms hold the keys to your email’s fate: SPF, DKIM, and DMARC.
TL;DR: Is This Even For You?
Before we dive deep, let’s be clear about who needs to care about this stuff:
If you use Gmail, Yahoo, Outlook, or any other free email service → You can read this for educational purposes, but you can’t actually configure these settings. You are at the mercy of your freemail service provider.
If you own a domain but use a hosting service (like Google Workspace, Microsoft 365, or Fastmail) → This post is definitely for you. *** Your provider gives you the tools, but you need to understand how to use them.***
If you run your own email server → You’re in the deep end, and while this post will help you understand the concepts, the actual implementation details are beyond our scope here. Good luck.
The Three Tribes of Email Users
Think of the email world as three distinct tribes:
Tribe 1: The Freeloaders use gmail.com, outlook.com, yahoo.com, or similar. They get excellent spam protection and deliverability for free, but they’re stuck with someone else’s domain name. No configuration needed—or possible.
Tribe 2: The Domain Owners have their own domain (like yourcompany.com) but let someone else handle the technical stuff. Google Workspace, Microsoft 365, Fastmail, and others provide the infrastructure while you get to use your branded email address.
Tribe 3: The DIY Warriors run their own mail servers. They have complete control and complete responsibility. With great power comes great complexity—and great opportunities to mess things up.
This post is mainly for Tribes 2 and 3, though Tribe 1 folks might find it interesting to understand what’s happening behind the curtain.
The Email Journey: What Actually Happens When You Hit Send
Let’s follow an email from your outbox to your recipient’s inbox and see where SPF, DKIM, and DMARC come into play.
Step 1: Your Email Server Prepares the Message
When you hit send, your email server does more than just forward your message. It:
- Adds headers with routing information
- Signs the message with DKIM (if configured)
- Looks up the recipient’s mail server using DNS
Step 2: SMTP, MTA, blah, blah, blah
Your message arrives at recipient’s server. We skip over all the magic of Mail Transfer Agents (or MTAs) and focus on what happens at the destination.
Step 3: The Recipient’s Server Gets Suspicious
This is where the magic happens. The receiving server doesn’t just accept your word for it. It runs a series of checks:
SPF Check: “Is mail.yourcompany.com actually authorized to send email for yourcompany.com?” It looks up your domain’s SPF record to find out.
DKIM Check: “Is this message actually from yourcompany.com, and has it been tampered with?” It uses the DKIM signature to verify authenticity and integrity.
DMARC Check: “What should I do if SPF or DKIM fails?” It looks up your DMARC policy for instructions.
Step 4: The Verdict
Based on these checks, the receiving server decides whether to:
- Deliver to inbox (all checks pass)
- Deliver to spam folder (some checks fail, but policy is lenient)
- Reject entirely (checks fail and policy is strict)
The Three Guardians Explained
SPF: The Bouncer’s Guest List
SPF (Sender Policy Framework) is like a bouncer checking IDs against a guest list. You publish a list of IP addresses and servers authorized to send email for your domain.
What it looks like:
v=spf1 include:_spf.google.com include:mailgun.org ~all
Translation: “Google’s servers and Mailgun’s servers can send email for this domain. Be suspicious of everyone else.”
The catch: SPF only checks the “envelope from” address (like the return address on a physical letter), not the “From” header that users actually see. Clever spammers can work around this.
DKIM: The Cryptographic Seal
DKIM (DomainKeys Identified Mail) is like a tamper-evident seal with a unique signature. Your mail server signs outgoing messages with a private key, and recipients verify the signature using a public key published in your DNS.
What it does:
- Proves the email really came from your domain
- Detects if the message was modified in transit
- Nearly impossible to forge (when implemented correctly)
The complexity: Setting up DKIM requires generating cryptographic keys and publishing them correctly in DNS. Get it wrong, and your emails start failing authentication.
DMARC: The Policy Enforcer
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the boss that tells everyone what to do when things go wrong. It ties SPF and DKIM together and provides instructions for handling failures.
What it looks like:
v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; ruf=mailto:forensic@yourcompany.com
Translation: “If emails fail SPF or DKIM checks, reject them. Send me summary reports daily and detailed forensic reports for each failure.”
The power: DMARC policies range from “monitor only” to “reject everything that fails.” It’s the difference between a warning and a brick wall.
When Tribe 2 Members Face Reality: “But My Email Went to Spam!”
You’re using Google Workspace or Microsoft 365. Your provider set up basic SPF, DKIM, and DMARC records. Life should be good, right? Then someone tells you your email landed in their spam folder, and you’re left wondering what went wrong.
This is where DMARC reporting becomes your best friend.
Understanding DMARC Reports
DMARC gives you two types of reports:
RUA (Aggregate Reports): Daily summaries showing who’s sending email claiming to be from your domain. Think of it as a daily newspaper of your email reputation.
RUF (Forensic Reports): Real-time alerts when specific emails fail authentication. These are like breaking news alerts for email problems.
Reading the Tea Leaves
When you start receiving DMARC reports, you’ll see:
-
Legitimate sources you forgot about: That newsletter service you set up two years ago, the CRM system that sends automated emails, the contact form on your website.
-
Spoofing attempts: Bad actors trying to impersonate your domain. This is why DMARC exists.
-
Configuration issues: Services you authorized but forgot to include in your SPF record, or DKIM signatures that aren’t working properly.
The Debugging Process
- Set up DMARC reporting with a policy of
p=none(monitor only) - Wait a week and collect reports
- Identify all legitimate sources sending email for your domain
- Update your SPF record to include any missing authorized senders
- Gradually tighten your DMARC policy from
nonetoquarantinetoreject
The scourge of freemail providers
Take a look at the SPF records for popular freemail providers.
% dig txt yahoo.com outlook.com gmail.com | grep spf
yahoo.com. 1800 IN TXT "v=spf1 redirect=_spf.mail.yahoo.com"
outlook.com. 300 IN TXT "v=spf1 ip4:157.55.9.128/25 include:spf-a.outlook.com include:spf-b.outlook.com include:spf2.outlook.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all"
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
I won’t go into the details of how redirect and include differ, but focus instead on the use of ~all by outlook.com but not by the other two.
I used to have some very old monitoring devices in my house, and I used them to generate email alerts. For that, they generated mail using my gmail account. This is quite common, and one of the reasons freemail providers (like google) don’t include a ~all. If they did that, they’d hugely reduce the amount of crap mail in the world, but they don’t. I guess there’s money to be lost if they did.
The Reality Check
Here’s what your email hosting provider won’t tell you: basic SPF, DKIM, and DMARC setup is just the beginning. Email deliverability is an ongoing process, not a one-time configuration.
You’ll need to:
- Monitor DMARC reports regularly
- Update SPF records when you add new services
- Maintain your sender reputation
- Deal with the occasional false positive
But here’s the good news: once you understand these three guardians and how they work together, you’ll have the tools to diagnose and fix most email deliverability issues. Your important emails will reach their destination, and you’ll sleep better knowing that spammers can’t easily impersonate your domain.
The invisible war between senders and spam filters will continue, but at least now you’re properly armed for battle.
What you should do
If you host your own email domain (either through a mail hosting service or on your own servers) definitely consider setting up DMARC properly and reviewing the reports regularly.
A bad actor who is spoofing your email domain and producing a lot of email that other mail servers view as SPAM could get your email domain blocklisted – and that’s a pain to unwind.
Proactively protect your mail domains reputation, it is much more costly to try and salvage it later.
Next time someone complains that your email went to spam, you’ll know exactly where to look. And when you see those DMARC reports rolling in, you’ll understand the story they’re telling about your domain’s email reputation.
Hype Cycles 