Why do some ESPs no longer require me to add their SPF record to my domain?

Many ESPs now use their own domains for the `Return-Path` (envelope-from) address, meaning their SPF record authenticates the email. Your domain's SPF record isn't needed for this part. However, you still need your SPF record to cover any other services that send email directly from your domain (e.g., your corporate mail server).

What happens if I have multiple SPF records or exceed the 10-DNS lookup limit?

Creating multiple SPF records for a single domain or having an SPF record that performs more than 10 DNS lookups will cause a `PermError`. This invalidates your SPF record, often leading to legitimate emails being marked as spam or rejected entirely by receiving mail servers.

Should I still set up DKIM and DMARC if my ESP says SPF isn't needed?

Yes, you should. While your ESP might handle SPF for the `Return-Path`, DKIM authentication is crucial for aligning your From: header domain with your DMARC policy. This ensures your visible sender identity is authenticated.

What are the benefits of proper SPF configuration?

The main benefit is improved email deliverability and protection against spoofing. By correctly configuring your SPF, DKIM, and DMARC, you tell receiving servers that your emails are legitimate, reducing the likelihood of them landing in spam folders or being rejected. It also helps preserve your domain's reputation.

Why do some ESPs recommend SPF records when they are not needed? - Technical - Email deliverability - Knowledge base

When setting up email for your domain, you've likely encountered advice from your Email Service Provider (ESP) about configuring SPF records. While SPF (Sender Policy Framework) is a crucial email authentication standard, some ESPs still recommend adding their SPF mechanisms to your main domain, even when it's not strictly necessary. This can lead to confusion and, in some cases, even harm your email deliverability.

This situation often stems from a misunderstanding of how SPF works in conjunction with other authentication protocols like DKIM and DMARC, particularly concerning which domain SPF actually authenticates during the email sending process.

Understanding the nuances of SPF, especially in a world where DMARC is becoming increasingly vital, is key to ensuring your emails reach the inbox reliably.

Suped DMARC monitoring

Free forever, no credit card required

Learn more

Trusted by teams securing millions of inboxes

The role of SPF in email authentication

SPF is designed to prevent email spoofing by allowing domain owners to specify which mail servers are authorized to send email on behalf of their domain. It does this by publishing a DNS TXT record that lists these authorized servers' IP addresses or includes other domains' SPF records. When a receiving mail server gets an email, it checks the SPF record of the Return-Path (or envelope-from) domain, not necessarily the From: header domain that recipients see.

The primary goal of SPF is to ensure that mail claiming to be from your domain is sent from one of your authorized IP addresses. If an email originates from an unauthorized server, it can fail SPF authentication, leading to it being flagged as spam or rejected. This helps improve email deliverability by validating the sender's legitimacy.

However, SPF alone isn't a complete solution for email authentication. It works best when combined with DKIM and DMARC. DKIM provides a cryptographic signature for emails, while DMARC ties SPF and DKIM together, allowing domain owners to tell receiving servers what to do with emails that fail authentication. For a deeper dive into these protocols, you can explore Sender Policy Framework on Wikipedia.

Typical SPF record example

An SPF record is published as a TXT record in your DNS. It starts with v=spf1 followed by mechanisms that define authorized senders.

SPF TXT RecordDNS

v=spf1 ip4:192.0.2.1 include:spf.example.com ~all

This example allows emails from 192.0.2.1 and any servers authorized by spf.example.com. The ~all indicates a soft fail for unauthorized senders.

The confusion with ESP SPF recommendations

Many ESPs used to, and some still do, provide instructions that suggest adding their specific SPF include mechanism directly to your root domain's SPF record, such as include:servers.mcsv.net for Mailchimp. The problem arises because your ESP typically sends emails with a Return-Path that uses their own domain or a subdomain they control (e.g., bounces.mailchimp.com). In such cases, SPF authentication checks their domain's SPF record, not yours. Your domain's SPF record is not needed for this type of SPF alignment.

The crucial point is SPF alignment with DMARC. DMARC requires that either the Return-Path domain or the DKIM signing domain (or both) align with the From: header domain. Since many ESPs configure DKIM for customers using CNAME records, the DKIM signature often provides the necessary alignment, making an SPF include on your root domain redundant for that ESP's traffic.

Adding an unnecessary SPF include can also lead to exceeding the SPF 10-DNS lookup limit, which can cause your SPF record to fail authentication entirely, marking legitimate emails as spam or getting them blacklisted (or blocklisted). This is a common pitfall that can severely impact your deliverability.

Traditional ESP advice

SPF record update: ESPs recommend adding their include mechanism to your root domain's SPF record.
Assumption: Your root domain's SPF is needed for ESP's sending, irrespective of the Return-Path domain.
Potential issues: Risk of multiple SPF records, exceeding the 10-DNS lookup limit, or redundant entries.

Correct understanding

ESP's role: ESPs typically send with a Return-Path domain they control, so their SPF record is checked.
DKIM alignment: DKIM provides alignment for your From: domain, which is what DMARC primarily relies on for third-party sending.
Optimal setup: Focus on proper DKIM configuration and DMARC policies for your domain.

Why some ESPs still make unnecessary recommendations

There are several reasons why some ESPs might still recommend SPF records even when they're not strictly necessary for your primary sending domain. One major factor is legacy documentation. Many ESPs, especially older or larger ones, may have had legitimate reasons to ask for SPF includes in the past, particularly before custom DKIM was widely supported for shared IP senders. These historical recommendations often persist in their help articles and setup wizards, leading to outdated advice being disseminated.

Another reason is simplification for users. For non-technical users, suggesting a simple SPF record update might seem easier than explaining the intricacies of SPF, DKIM, and DMARC alignment. In some cases, it was a quick and dirty solution for common support issues, like customers being unable to email their own company domain. This approach, while initially helpful, became less relevant as email authentication evolved.

While some ESPs, like AWeber and Postmark, have updated their guidance to clarify that SPF updates aren't needed when they handle the `Return-Path` and DKIM, many others have not. This creates a landscape where domain owners receive conflicting information, making it challenging to implement the correct email authentication setup.

ESP	SPF requirement for your domain	Primary authentication method for alignment
Mailchimp	Historically recommended, but now often unnecessary for the main domain.	DKIM for From: header alignment. ESP manages Return-Path SPF.
SendGrid	Often recommended, even if they handle Return-Path SPF via CNAMEs.	DKIM for From: header alignment. ESP manages Return-Path SPF with CNAMEs.
Amazon SES	Similar to SendGrid, includes are often advised.	DKIM for From: header alignment. ESP manages Return-Path SPF.
AWeber	Explicitly states no SPF update needed for your domain.	DKIM for From: header alignment. ESP manages Return-Path SPF.

The dangers of incorrect SPF configuration

While it might seem harmless to add an SPF include from your ESP, even if it's not strictly necessary, it can introduce several problems. The most critical is the SPF 10-DNS lookup limit. Your SPF record is limited to 10 DNS lookups. Exceeding this limit will cause your SPF record to return a `PermError`, leading to authentication failures for your legitimate emails. Many receiving servers, especially those of major mailbox providers, will treat these emails as suspicious or outright spam.

Another danger is the risk of having multiple SPF records for a single domain. While less common now, some outdated advice might lead users to create a separate SPF TXT record for each ESP. This also results in a `PermError` because a domain can only have one SPF record. When this happens, email deliverability suffers greatly, as your emails may fail to authenticate and land in the spam folder or be rejected entirely.

Incorrect SPF configuration can also make your domain more susceptible to phishing and spoofing attacks if it's too permissive, or conversely, cause legitimate mail to be blocked if it's too restrictive. Maintaining a clean and accurate SPF record is essential for overall email deliverability and domain reputation, preventing your IP or domain from ending up on an email blacklist (or blocklist).

Navigating SPF for better deliverability

Navigating the complexities of email authentication, especially SPF, can be challenging. Many ESPs have evolved their sending practices, relying more on DKIM and DMARC for From: header alignment, while SPF remains crucial for the `Return-Path` domain they manage. The key takeaway is to understand how your specific ESP handles authentication and ensure your DNS records are configured optimally without unnecessary entries.

Always prioritize clear, correct SPF records that avoid exceeding the 10-DNS lookup limit and consolidate all authorized senders into a single TXT record. Combined with proper DKIM and DMARC implementation, this approach will significantly bolster your email deliverability and protect your domain's reputation from spoofing and phishing attempts. Regular monitoring of DMARC reports can provide insights into your email authentication performance and help you catch issues before they impact your sender reputation.

By focusing on modern authentication standards and understanding the specific roles of SPF and DKIM in DMARC alignment, you can cut through outdated advice and build a robust email sending infrastructure.

Views from the trenches

Best practices

Always verify if your ESP handles SPF authentication on their `Return-Path` domain before adding their `include` mechanism to your primary domain's SPF record.

Prioritize setting up DKIM and DMARC for your `From:` domain, as these protocols ensure authentication and alignment for your visible sender identity.

Consolidate all authorized sending sources into a single SPF record for your domain to avoid `PermError` issues and maintain a valid policy.

Common pitfalls

Creating multiple SPF records for a single domain will lead to `PermError` failures, causing emails to be rejected or sent to spam.

Exceeding the 10-DNS lookup limit in your SPF record can cause authentication failures, as receiving mail servers may stop evaluating the record prematurely.

Blindly following outdated ESP documentation without understanding SPF's underlying mechanics for `Return-Path` versus `From:` domain alignment.

Expert tips

When using an ESP, confirm if they manage the `Return-Path` domain's SPF. If so, your domain's SPF record may only need to include other services that send directly from your `From:` domain.

Use a dedicated subdomain for marketing or bulk email to isolate its reputation and SPF records from your primary corporate email domain.

Implement DMARC with a `p=none` policy initially to gather reports and observe your SPF and DKIM authentication results without impacting deliverability.

Expert view

Expert from Email Geeks says many third-party services, including major ones like SendGrid, Mailgun, and Amazon SES, provide SPF recommendations that aren't fully aligned with the best practices for subdomain Return-Path authentication.

2021-12-19 - Email Geeks

Expert view

Expert from Email Geeks says outdated SPF advice from some providers originated over a decade ago when custom DKIM support for shared IP senders was not widely available. This recommendation was a quick solution to help users with internal email delivery issues.

2021-12-19 - Email Geeks