Email security is a two-way street, which means both the client and the email service provider are responsible for maintaining the legitimacy and authenticity of the communication process. It is not only the company sending out emails that should take action against spoofing and phishing attacks but also the platforms through which the emails are sent; they also need to ensure that the messages securely travel through their mailboxes and reach the recipients.
To ensure this, the ESPs must take tactical steps like implementing authentication protocols like SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance).
Out of these three, SPF is the first line of defense that both parties must implement to ensure that only authorized mail servers can send emails on behalf of a domain. While it is the most basic email authentication mechanism, it is also the most commonly misconfigured protocol that can break your entire email security strategy if not set up correctly. What’s surprising is that even ESPs—who are supposed to be the masters of email deliverability—sometimes get SPF wrong, leading to deliverability issues, security vulnerabilities, and domain spoofing risks.
In this article, we will take a look at why this happens and what can be done to fix it.
Understanding SPF alignment
Before we get into what goes wrong with SPF implementation when ESPs try to configure it, let us understand how SPF works, particularly its role in domain alignment and email authentication.
For starters, it is important to know that there are two ‘From’ addresses in any email: one that is visible to you and your recipient and the other one that operates behind the scenes.
1. Return-Path address
Also known as the envelope sender, bounce address, or MAIL FROM, this address is used primarily for processing bounced mail. If an email cannot be delivered to its destination, the Return-Path directs mail servers to send non-delivery reports there. This address is defined in the SMTP envelope of the email and is not seen by the recipient.
2. ‘From’ address
The other one is the ‘From’ address, which is basically the sender’s address that you see in your inbox. Unlike the Return-Path address, which is used for email bounce processing and routing errors, the From: address is what recipients identify as the source of the email.
Coming back to SPF alignment, it simply means that the From: address you see and the Return-Path (the hidden bounce address) should match or be from the same domain. So, if you are sending an email from someone@company.com, and the Return-Path is support@company.com, then it is aligned. But for it to be DMARC compliant, the sending server must also be included in the SPF record. If everything seems good, the email is authenticated and is more likely to land in the inbox.
Why does SPF even fail?
There are many reasons why SPF fails, even when implemented by ESPs. Since SPF depends on looking up DNS records to confirm whether an email is being sent from an authorized server, even a minor misconfiguration can render it useless. Let us take you through some of the most common reasons why this happens:
Alignment Failures
You might think that SPF alignment is all about updating your SPF record with the authorized sending IPs or domains, but that’s not the case. What’s worse is that some ESPs also believe the same. By adding sending IPs to the SPF record, you’re just whitelisting them without achieving proper alignment.
For SPF alignment, the sending domain must match the Return-Path domain, which is a requirement for DMARC compliance. When ESPs provide outdated or inaccurate instructions, businesses may add unnecessary ‘include’ statements to their SPF records, taking up valuable DNS lookup space and sometimes causing email authentication failures.
Alignment failures happen when the Return-Path domain (the invisible bounce address) does not match the From: address domain (the visible sender address).
Achieving SPF alignment with a subdomain
If you’re working with an ESP like Mandrill, you might run into a problem of SPF alignment. The thing is, by default, these ESPs use their own Return-Path (bounce address) domain, which certainly won’t match with your From: address, and this creates SPF alignment issues. But there’s a way to fix this.
In such cases, the ESP uses a subdomain-based approach to help you achieve SPF alignment. That means that instead of changing your main SPF record, you can create a subdomain and configure it specifically for your ESP’s authentication. Here, you create a subdomain and set up a CNAME record that points to Mandrill’s domain (e.g., mandrillapp.com).
So, when you create this subdomain within Mandrill’s portal, it enables you to set up the Return-Path address to utilize your subdomain. This makes the Return-Path domain match your sending domain’s subdomain, attaining SPF alignment without filling up your main domain’s SPF record.
Adding unnecessary domains in the SPF Record
Many ESPs ask their users to update their SPF records with every other domain that they use for sending emails. This includes even the extra or inactive email services that they might not even use. Doing this can do more harm than good. It can waste your SPF lookups and cause authentication issues.
The main problem with this approach is that SPF has a 10 DNS lookup limit, and when you include too many include statements, you easily hit this limit, and SPF will fail—even for valid emails. Instead, you should only include the services you actually use. For instance, if you use Google to send your emails, add _spf.google.com; or if you use Microsoft, add spf.protection.outlook.com. There’s no need to add both just for the sake of it.
Are you too facing deliverability issues because of misconfigured SPF records? Now that we have identified the problem areas, it is time to fix them. At AutoSPF, we make SPF deployment and management a breeze! To get started, book a demo with us today.
