🔥 My hot take about SPF records
(2026-02-06)
Almost nobody should be listed in your SPF record, and if anybody asks to be listed in your SPF record, you should cease doing business with them immediately.
The only thing you should list in your SPF record is whatever service you use to actually write and send out emails. Nothing automated, no third-parties, just your primary mail host.
📫 A quick SMTP primer
Whenever any piece of email is delivered to a mail server, at some point the following transaction will happen. The below illustrations a client (designated "C") handing off a piece of mail to a server (designated "S").
I know the terminology can be confusing since it many cases we're talking about servers sending to other servers but, in this context the sending server is the "Client" and the receiving server is the "Server." Bear with me:
You'll notice that the "From" email address shows up twice. First in the MAIL FROM command, then later in the DATA part of the SMTP transaction, as a header.
It's fairly common to refer to the the SMTP-level data as envelope data. That is - the address given in "MAIL FROM" is the envelope sender, and the address given in "RCPT TO" as the envelope sender. This is since this is all outside of the message - like how when sending real-life mail, your envelope states where the message should go, and where it's from.
We'll refer to the MAIL FROM address as the envelope sender, and the email address inside the "From:" header as the header from address.
You'll also see the envelope address referred to as the Return Path, you can often see this if you view all your email headers - the "Return-Path" header is usually injected by your mail server before doing the final delivery into your mailbox.
Your envelope sender has nothing to do with the header address.
These addresses don't need to match, at all. They can be completely different domains - it's perfectly legal to have an envelope sender like "bob@example.org", and for the header's "From" address list "greg@example.com."
SPF doesn't give a shit about the header's "From" address.
SPF is used to verify one thing - the envelope sender's domain. The RFC makes no recommendation about whether these two addresses should match, or even what to do with a failing SPF result.
I'm not going to get into the details on how SPF verifies anything, all that you really need to know is - when a server gets an email, it looks up the SPF record for the envelope sender and checks if the server IP is authorized to use that envelope domain.
🦘 Bouncing email
When an email bounces - the bounce will always go to the envelope address. It never goes to the header's "from" address.
Bouncing email can get delayed. It's very common in say, cases of email forwarding - for an intermediary server to accept a message, and then have a failure later.
When this happens - the server will look up the MX record for the envelope's domain and send the bounce there.
Here's where SPF comes into play
So - SPF only cares about the envelope address.
When your company's marketing team decides they need to use some whizz-bang new marketing platform that will generate yet more unwanted email, and that marketing platform says "yeah, tell your IT team to add our include into your SPF record" that's huge red flag 🚩.
That means they'll be using your domain in the envelope addresses.
That means when your dumbass marketing team inevitably sends out a bunch of garbage email and generates bounces, guess who's getting the bounce notifications? You! Which - y'know, not the end of the world for you. You're a pro and can handle it.
The main issue is - it means this third-party, whizz-bang b̵u̵l̵l̵s̵h̵i̵t̵ marketing platform can't track bounces, since they're going to your servers. So when your marketing team does some big push again later, they'll generate all those same bounces and your domain's reputation will go in the toilet.
✅ The right way to do things
DKIM and DMARC.
First a quick DKIM primer - basically it's a way to attach a cryptographic signature to an email, and that signature is associated to a domain. Receivers can validate if the signature is valid but - like SPF - the specs don't actually state anything about if the signature's domain should match the From address domain. It's perfectly valid to receive an email with a "From" address of example.org, with a DKIM signature from example.com.
DMARC is the rug that really ties the room together. It takes both SPF and DKIM and adds a requirement.
For an email to pass DMARC, it must have either:
- a passing SPF result that aligns with the "From" address domain, or
- a passing DKIM result that aligns with the "From" address domain.
You don't need both, and if one result is failing or missing or out of alignment - it doesn't matter so long as at least one of those results passes and is in alignment.
I'm not going to get into all the details around DMARC alignment - but the ideal solution for a third-party mailing platform is:
- Use the platform's domain in the SMTP envelope and pass SPF for that domain.
- Perform DKIM signing with the "From" address domain and pass DMARC.
That will let the platform pass even strict alignment and ensures they receive bounces, so when your dumbass^H^H^H^H^H^H^H marketing crew wind up sending emails out to a bunch of bad addresses - the platform can detect it, block the addresses, kick your marketing team out as customers, whatever makes sense.
The amount of companies I've seen just absolutely fuck this up is astounding. If you're running one of these platforms and you have no idea what I'm talking about - you should get out of the email business.