How ESPs Get SPF Wrong

Sender Policy Framework or SPF is one of the security standards for email authentication that DMARC relies on (alongside DKIM).

It’s an essential mechanism required for an outgoing email source to achieve DMARC compliance. A domain can have only a single SPF record in its DNS zone. It contains a list of all the IP addresses that are permitted to send emails on behalf of your domain.

Before we dive into details, you must know that there are two “From” addresses in any email

1. Return-Path address: Also known as the bounce address, envelope sender, or envelope from, it’s used for bounce purposes. When an email doesn’t make it to its intended destination, the return path indicates where non-delivery receipts (or bounce messages) are to be sent.
2. From: address: Who an email is from and where it originates. This is what you see as the “From” in most email clients.

SPF alignment is about the From: address domain matching the Return-Path domain. For example, if the From: address is [email protected] and the Return-Path is [email protected], SPF alignment is achieved. If the IP address is whitelisted, the email becomes DMARC Compliant.

In the example below we can see that the From: domain is “easydmarc.com” and the Return-Path (or mailed-by in the screenshot) domain is “notifications.easydmarc.com.” SPF alignment is achieved by default since the aspf is set to “relaxed.” You can read more about alignment tags here.

We can also analyze the email headers to check the Return-Path and From: addresses. In the screenshot below, both align as seen in the green boxes. We can also see that the IP address is whitelisted which makes this email pass and align with SPF, so it’s a DMARC compliant email.

Case 1: Failing Alignment

In some cases, email service providers or ESPs get the SPF configuration wrong by telling their users to append/update their SPF record with their source IPs whitelisted—without achieving alignment with their domain/subdomains.

Remember, by adding a source server in your SPF record, you’re simply whitelisting IP sources without achieving alignment.

For example, Constant Contact is a widely known email marketing solution.

A simple google search for “Constant Contact SPF” redirects you to their website. See the screenshot below:

Updating your SPF record with the given “include” allows Constant Contact to pass the SPF authentication without aligning with your domain. 

Let’s take a closer look at this misalignment using DMARC aggregate reports:

• The blue square is your domain.
• The green square is the DKIM domain, signed and aligned with the blue square (matching your domain).
• The red square is the SPF passing the authentication. However, the Return-Path address (in.constantcontact.com) doesn’t align with the domain (easydmarc.com), which is necessary to achieve SPF alignment, and, in turn, DMARC compliance.

Some ESPs have the option to align the SPF Return-Path address by having some sort of a checkpoint after adding the SPF record “include” from their portal. Other ESPs provide a “CNAME” record that simplifies the process by achieving alignment—whether it’s on a domain or subdomain level.

But in some cases, ESPs like MailChimp, Brevo, Constant Contact, and many more provide outdated or misleading information that guides you towards unnecessary steps. These ESPs want you to whitelist their domain in your SPF while using their own domain in the Return-Path address to handle your bounces. This wastes a Lookup space in the SPF record.

Case 2: Passing Alignment on a Subdomain Level

With some ESPs like Mandrill, you can achieve SPF alignment by adding a subdomain with a “CNAME” record that redirects to their mandrillapp.com domain. Adding that subdomain to their portal gives you access to change the Return-Path address from the settings, which then allows for SPF alignment. See the screenshot below:

In similar cases, you don’t have to whitelist or add Mandrill’s server to your root domain’s SPF record. You just need to add SPF Record on the specific subdomain you’ve created within the Mandrill portal’s Return-Path domain (in this case, mandrillsub.easydmarc.me).

Case 3: Including Original/Root Domains in your SPF Record

In some cases, ESPs ask their users to whitelist domains that contain irrelevant source IPs or hosts outside of their server scopes. For example, Bluehost and Hostgator tell their users to add “include:websitewelcome.com” in their users’ SPF record, where we can see the Google Workspace (include:_spf.google.com) and Microsoft 365 (include:spf.protection.outlook.com) IP addresses are also whitelisted.

Technically, by whitelisting “websitewelcome.com,” you’re also whitelisting Google and Microsoft (which are most probably email services you don’t use) since you’re already using Bluehost’s or Hostgator’s email service program. You’re simply wasting a large amount of SPF Lookups while whitelisting many sources that you don’t actually use to send emails.

Analyzing XML Files Help You Understand Better

After deploying DMARC, you’ll receive aggregate reports in XML format, which can be analyzed to better understand the sources and SPF, DMARC, and DKIM statuses.

In the example below, we can see the From: address is “easydmarc.com” while the Return-Path or Envelope From is “bnc3.mailjet.com.”  So, the email fails the SPF alignment process.

Key Takeaways:

1. Some ESPs handle your bounces with their domain name (Mailchimp, Sendinblue, etc.). For these cases, you don’t need to whitelist their servers in your domain’s SPF record.
2. Some ESPs let you achieve alignment by setting up the Return-Path domain on a subdomain level (AmazonSES, Sendgrid, Mailgun, Mandrill, etc.). As such, you don’t need to whitelist their servers in your root domain’s SPF record. Implement that SPF Record on your subdomain only.
   
3. Be aware when including other root domains in your SPF Record. You may be whitelisting sources that you don’t use within your organization.
   
4. Use EasyDMARC’s SPF Record Raw Checker to double-check any SPF Record for a third-party source before attempting to add it in your own domain’s SPF.
5. Check the dates of any official information before attempting to update or change your domain’s SPF record. Outdated articles should be ignored.
6. Check what DMARC aggregate report data is telling you in terms of your authentication and alignment processes. That’s the most accurate data you can get while optimizing your SPF record.

Contact the support team at EasyDMARC if you’re having any trouble with your sources. The support package in our premium and enterprise plans are designed to help you overcome these issues and guide you through the process of deploying and enforcing DMARC.

[email protected]