You might assume that ESPs know it all; after all, they are managing your entire email infrastructure. But that’s not always the case. While these service providers excel when it comes to sending and delivering emails efficiently, they don’t always prioritize security and authentication. When it comes to protecting those emails, they are not always the ultimate safeguard against spoofing and phishing attempts.

Yes, protecting your outgoing emails isn’t just your responsibility; it is also the responsibility of the ESP that you’re using to send emails.

Speaking of protecting your emails, these ESPs do a fair job of authenticating your messages with protocols like SPF, DKIM, and DMARC. But, to tell you the truth, they don’t always do the best job when configuring these protocols. One of the security standards that they often misconfigure is SPF, or Sender Policy Framework.

In this article, we will dive into all the ways that ESPs mess up SPF configuration, but first, let us understand what SPF alignment actually is.

Cracking the code: SPF alignment

To understand where ESPs go wrong with SPF configuration, we first need to break down how SPF works and why it even matters in the first place.

Any email has two ‘From’ addresses— one that the sender and the receiver can see (the From: address) and the other one that operates behind the scenes (the Return-Path address).

1.    Return-Path address

Even though you don’t get to see the Return-Path address, it is one of the most important parts of email delivery. This is the address that mail servers use to handle undelivered emails. If an email can’t be delivered, the failure notice is sent to this address.

As you already know, this address is hidden from the recipient; it’s primarily used for mail processing. Basically, it serves as a fail-safe measure, ensuring that any email delivery problem is reported back to the sender domain for monitoring and fixing.

2.    From: Address

This is the email address that appears in your inbox—the one that tells you who the sender is. If you get an email from hello@company.com, that’s the ‘From’ address. It’s the address people trust and associate with the sender’s identity.

SPF alignment is pretty simple: the From address and the Return-Path address should match or at least have the same domain.

Let’s say, an email is sent from sales@example.com but has a hidden Return-Path address mailer@exampleservice.com, the alignment will fail. If your SPF is not aligned, your mail will probably be marked as suspicious, end up in spam, or even be blocked entirely.

This isn’t just a mismatch; it is a loophole that affects your email deliverability, brings down open rates, and taints your reputation.

SPF failure: why and how?

Now that we know what SPF alignment is, let’s dig deeper into why things go wrong and what that means for your email deliverability.

When SPF isn’t properly configured, your emails won’t land in the recipient’s inbox. Instead, they could end up in spam or get rejected altogether. This is because ESPs don’t always set up SPF correctly—or because SPF itself has some inherent limitations.

But where exactly do they go wrong? Let’s find out.

Alignment issues

SPF isn’t only about updating your SPF record with the authorized sending domains and IP addresses. It’s rather about ensuring that the From: address and the Return-Path address match with each other. But this is something that most ESPs overlook. What they actually do is use their own domain in the Return-Path address instead of yours.

Let’s say you send an email from sales@yourcompany.com, but your ESP set the Return-Path address as mailer@youresp.com. So, even if your domain is listed in the SPF record, the outbound email will fail SPF alignment, and it won’t reach the recipient’s inbox because the Return-Path domain doesn’t match the visible From: address domain.

Alignment issues with subdomain

Some ESPs, like Mandrill, cause SPF alignment issues because they use their own Return-Path address as a default. What this does is that the hidden Return-Path address will be different from your From: address, and this can cause your emails to look untrustworthy and get flagged as spam.

Thankfully, there’s an easy solution. You don’t have to modify your primary SPF record. You can set up a subdomain solely for the ESP. For instance, you configure email.yourcompany.com and connect it with Mandrill by setting up a CNAME record pointing to mandrillapp.com. When you set this up in Mandrill settings, the Return-Path gets to use your subdomain, hence matching your From: address. This automatically fixes SPF alignment, and your emails will get delivered to the inbox more effectively.

Unnecessary domain in the SPF record

Some ESPs ask you to include a long list of domains in your SPF record, even for the services you don’t use. This may sound helpful, but it will end up causing problems.

RFC allows each SPF record to have a maximum of 10 DNS lookups. So, if you add too many sending domains, your SPF record will reach this limit, and SPF will fail even for valid emails.

Instead of adding all the domains your ESP recommends, we’d suggest you add only the email services you use. If you’re sending emails through Google, just add _spf.google.com. If you’re using Microsoft, add spf.protection.outlook.com.

By having a clean and simple SPF record, you prevent lookup failures, improve email deliverability, and have your emails delivered to inboxes instead of spam folders.

Hi, I’m Daksh Kaur, and I’m a freelance cybersecurity writer. My forte is simplifying security topics into simple, compelling, and actionable content. If you need well-researched, easy-to-understand cybersecurity blogs for your website, I’d love to help!

I’d love for us to work together on long-term projects where I can create content that not only informs and educates but also makes a real impact. You can get in touch with me at daksh@turtlewords.com, and I’d be happy to discuss how I can bring value to your brand!