Latest / The Email Marketing Podcast with Fexingo: Newsletters, Open Rates, and Subscriber Growth / How Email List SPF Records Stop Spoofing Attacks
Transcript
- Lucas: So there's this scenario that keeps email marketers up at night — you craft the perfect newsletter, hit send, and then discover half your list never got it because your domain got flagged as spam. Luna: And usually the immediate suspect is content — bad subject lines, too many images, spammy words. But sometimes the problem isn't the email itself. It's the envelope it came in. Lucas: Exactly. And the envelope, in email terms, is authentication. Specifically, something called an SPF record — Sender Policy Framework. It's a tiny DNS text record that tells receiving mail servers, 'Here's a list of IP addresses that are allowed to send email for this domain.' Luna: And if you don't have one — or if it's wrong — your emails can get rejected or land in spam, even if you're totally legitimate. Lucas: Right. I want to ground this in a real example. I was talking to a marketing director at a mid-sized fashion e-commerce brand — let's call them 'Ridge & Co.' They were seeing open rates around 12 percent, which is terrible for that vertical. Turns out, their IT team had set up an SPF record years ago but never updated it. Luna: So what was the specific misconfiguration? Lucas: They were sending through Mailchimp, but the SPF record only listed their in-house email server's IP. Mailchimp's sending IPs weren't included. So every time a newsletter went out, Gmail and Outlook saw mail coming from an unauthorized IP and either bounced it or slapped a spam warning on it. Luna: Ouch. And how long had that been going on? Lucas: Over a year. They'd been tweaking subject lines, adjusting send times, improving content — all the right things — but the core plumbing was broken. Once they fixed the SPF record to include Mailchimp's IP range, their deliverability jumped from around 70 percent to 97 percent within two weeks. Luna: That's a huge swing. And it's not just about missing third-party senders. Sometimes the record itself is syntactically invalid — too many DNS lookups, or it uses the wrong qualifier. Luna: I remember one client whose SPF record had a 'soft fail' — that's the tilde dash — when they actually needed a 'hard fail' — the minus sign. Soft fail basically tells the receiver, 'This might not be legit, but go ahead and accept it anyway.' Not great for security. Lucas: And the hard fail is the opposite — it says, 'Reject anything not from these IPs.' But here's the thing: if your SPF record is too strict and you forget to include a legitimate sender, you'll have delivery failures. So you have to balance security with accuracy. Luna: Let's talk about the bigger picture. SPF is just one piece of the authentication puzzle. You've also got DKIM — DomainKeys Identified Mail — which adds a digital signature. And DMARC, which tells receivers what to do if authentication fails. Lucas: Right. But I want to focus on SPF today because it's often the first thing marketers overlook. A 2025 study by Validity found that 23 percent of Fortune 500 companies still have invalid SPF records. That's not small startups — that's major brands. Luna: And the consequences go beyond just delivery. A bad or missing SPF record makes it trivially easy for spammers to spoof your domain. They can send phishing emails that look like they're from you, and because there's no SPF check, they'll land in inboxes. Lucas: Exactly. That's what happened to a client I consulted for a few years back — a regional bank. Spoofers sent emails pretending to be from the bank's customer service, asking people to click a link and 'verify their account.' The bank's SPF record was nonexistent. Luna: How did they find out? Lucas: Customers started calling the actual bank saying, 'I think I got scammed.' The bank's domain ended up on several real-time blacklists. It took weeks to clean up, and their legitimate email volume dropped 40 percent during that period. Luna: So fixing SPF isn't just a deliverability tactic — it's a security fundamental. And the good news is, it's relatively simple to audit. You just look at your domain's DNS records for a TXT entry starting with 'v=spf1'. Lucas: Right. And there are free online tools like MXToolbox or SPF Record Checker that will validate your record and tell you if there are errors. The common ones: too many DNS lookups — the limit is 10 — or missing include statements for services like Mailchimp, Salesforce, SendGrid, or Google Workspace. Luna: Let's actually walk through what a good SPF record looks like. Lucas, can you give us a simple example? Lucas: Sure. Say your domain is 'ridgeandco.com'. A basic record might look like: v=spf1 mx include:servers.mcsv.net ~all. The 'mx' means your own mail server IPs are allowed. The 'include' pulls in Mailchimp's authorized IPs. The tilde-all at the end is a soft fail for everything else — not ideal for security, but safer while you're testing. Luna: And if you want to hard fail, you'd replace the tilde with a minus: -all. But you'd better be sure you've listed every legitimate sender. Lucas: Exactly. And if you use multiple sending platforms, you chain includes. So for example: v=spf1 mx include:spf.mailchimp.com include:spf.sendgrid.net ~all. Each include counts as one lookup, so you can have up to ten. Luna: One thing that trips people up: if you use a subdomain for sending — like 'mail.ridgeandco.com' — that subdomain needs its own SPF record. The root domain's record doesn't cover subdomains by default. Lucas: Great point. And another nuance: SPF only checks the envelope sender — the Return-Path address — not the 'From' address the reader sees in their email client. That's where DKIM comes in. But that's a topic for another episode. Luna: So let's bring it back to practical steps. If a marketer is listening right now and wants to check their SPF record today, what's the first thing they should do? Lucas: Go to a DNS lookup tool, type in your domain, and look for a TXT record starting with 'v=spf1'. If it's missing, you need to create one. If it exists, check that every service you use to send email is included. Most email service providers publish their SPF include values in their help docs. Luna: And after you update it, give it a few hours to propagate — DNS changes aren't instant. Then send a test email to a Gmail and Outlook address and check the full headers. You'll see something like 'received spf: pass' if it's working. Lucas: And if you see 'neutral' or 'softfail', you've got more work to do. But honestly, once you have a valid SPF record in place, you eliminate one of the biggest causes of mysterious deliverability problems. It's a ten-minute fix that can save months of frustration. Luna: It really is one of those 'check the plumbing before you redecorate' situations. And I think that's a good note to end on. Lucas: Before we wrap, I want to mention something. If these marketing deep dives have helped you — maybe you've used one of these fixes at work, or you've avoided a spoofing disaster — it means a lot that you listen. And if today's episode was worth a coffee to you, there's a link at buy me a coffee dot com slash fexingo. No pressure, just a small way to keep this show ad-free. Luna: Yeah, honestly, listener support is what lets us spend time on these technical deep dives instead of chasing ad sponsors. So if it's useful, that's the place. Lucas: Alright, let's get back to the nuts and bolts. One more thing I want to touch on: SPF record maintenance. It's not a set-it-and-forget-it thing. Every time you add a new sending tool — like a new CRM that sends transaction emails, or a new email testing platform — you need to update your SPF record. Luna: So it's a living document. And the companies with the best deliverability treat it that way — they have a process for reviewing it quarterly. Lucas: Exactly. And they also monitor their DMARC reports, which tell them if any unauthenticated email is being sent from their domain. That's the next level, but it starts with SPF. Luna: Alright, that's a solid takeaway. Check your SPF, include all your senders, and test it. Thanks for listening, everyone. Lucas: Talk to you next time.