How do I set up an SPF record when using multiple email sending services?
Michael Ko
Co-founder & CEO, Suped
Published 2 May 2025
Updated 16 Aug 2025
8 min read
Sender Policy Framework (SPF) records are a cornerstone of email authentication. Their primary role is to inform receiving mail servers which IP addresses and domains are authorized to send emails on behalf of your domain. This verification helps prevent email spoofing, a common tactic used in phishing and spam, by ensuring that only legitimate senders can use your domain.
In today's digital landscape, it's rare for a business to use just one email sending service. You might use Google Workspace for internal communications, Amazon SES for transactional emails, and a dedicated email marketing platform for campaigns. The challenge arises when all these services need to send emails using the same domain, such as yourdomain.com.
The critical rule you must remember is that a domain should only have one SPF TXT record. If you publish multiple SPF records for the same domain, recipient mail servers will likely ignore them, leading to SPF authentication failures. This confusion can cause your legitimate emails to be marked as spam or rejected outright, severely impacting your deliverability.
An SPF record is a specifically formatted TXT record in your Domain Name System (DNS). It declares the legitimate email sending sources for your domain. When a mail server receives an email, it checks your domain's SPF record to verify if the sending IP address is on the authorized list. If it's not, the email may be flagged as suspicious or spam.
As per RFC 7208, the official specification for SPF, a domain or subdomain should only have one SPF record. Having multiple SPF records (or multiple TXT records starting with v=spf1) can lead to a PermError, which essentially tells the receiving server, "I don't know what's going on here," leading to authentication failure.
Beyond the single record rule, SPF also has a 10-DNS lookup limit. This means that your SPF record, when parsed by a receiving server, cannot involve more than ten DNS queries to resolve all specified mechanisms (like include, a, or mx). Exceeding this limit also results in a PermError, making it critical to optimize your SPF record. You can find more information on how to optimize your SPF record in our other guides.
The 10-DNS lookup pitfall
A common mistake when consolidating SPF records is exceeding the 10-DNS lookup limit. Each include or mechanism that requires a DNS query counts towards this limit. If your SPF record triggers more than ten DNS lookups, it will result in an SPF PermError. This error can cause legitimate emails from your domain to be rejected or sent to the spam folder. Always verify your combined SPF record to ensure it stays within this critical limit.
Identifying all your email sending sources
The first step in setting up a robust SPF record for multiple email services is to thoroughly identify every single platform that sends email on behalf of your domain. This includes not only your primary email provider but also marketing automation tools, CRM systems, customer support platforms, transactional email services, and even internal applications that send notifications.
A common point of confusion is differentiating between the From: address (what recipients see) and the Return-Path: address (also known as the Mail From, Envelope From, or Bounce address). SPF authentication checks the domain in the Return-Path: header. You can check this by sending a test email from each service to your own inbox and inspecting the email headers. Many email clients offer a "Show original" or "View source" option to reveal this information. Google Workspace provides guidance on inspecting headers.
Once you have a clear list of all your sending services, refer to their documentation to find the specific SPF include mechanisms or IP addresses they require. Be aware that some services, like Mailchimp, recommend against adding their include directly to your main domain's SPF record. For more details, see our article on why you shouldn't add Mailchimp to your SPF record.
Service
Common SPF include
Google Workspace
include:_spf.google.com
Amazon SES
include:amazonses.com
HubSpot
include:_spf.hubspotemail.net
SendGrid
include:sendgrid.net
Crafting your single, comprehensive SPF record
Since you can only have one SPF record, you must combine all the necessary mechanisms into a single TXT record. This is done by listing all the include statements from each of your email sending services, along with any other required mechanisms like ip4 or ip6 for your own servers, within that one record. Remember to keep the total number of DNS lookups under ten.
Mechanisms like a (for the A record of your domain) and mx (for the MX records of your domain) are common in SPF records. However, if you are relying solely on third-party services for sending email, these mechanisms might not be necessary, and removing them can help reduce your DNS lookup count. Only include them if your main domain's A or MX records genuinely send email on behalf of your domain's Return-Path:.
Finally, you must choose an SPF qualifier that dictates how receiving servers should treat emails that fail SPF checks. The most common are -all (Fail) and ~all (SoftFail). We generally recommend -all once you are confident in your SPF record, as it provides the strongest protection against spoofing. However, during initial setup, ~all can be a safer starting point to avoid inadvertently blocking legitimate emails.
Policy: Instructs receiving servers to reject emails that fail SPF checks (i.e., emails sent from unauthorized sources).
Security: Provides the highest level of protection against email spoofing and phishing attempts for your domain.
Use case: Recommended once you have confidently identified and authorized all legitimate sending sources.
Lenient enforcement (~all)
Policy: Suggests to receiving servers that emails failing SPF checks should be treated with caution, but not necessarily rejected. They might be marked as spam.
Security: Offers less protection than -all but reduces the risk of legitimate emails being blocked during initial setup.
Use case: Ideal for initial deployment and testing phases, allowing you to monitor results before moving to a stricter policy.
Verifying and maintaining your SPF record
Once you've published your consolidated SPF record, verification is essential. There are many online SPF record checkers that can help you confirm that your record is correctly formatted, doesn't have any syntax errors, and most importantly, does not exceed the 10-DNS lookup limit or contain multiple SPF records. This step helps prevent SPF authentication failures before they impact your email deliverability. For general troubleshooting, refer to our guide on troubleshooting SPF authentication issues.
Setting up SPF is not a one-time task, especially if your email infrastructure evolves. Periodically review your SPF record to ensure it reflects any changes in your email sending services. Neglecting this can lead to legitimate emails failing authentication, increasing the risk of your domain appearing on a blocklist (or blacklist) and damaging your sender reputation. For more information, you can read our guide on why emails might fail at Microsoft due to SPF issues.
While SPF is a vital component, it's part of a larger email authentication ecosystem that includes DKIM and DMARC. Once your SPF record is correctly configured, implementing DMARC is the next logical step. DMARC provides reporting and policy enforcement, giving you visibility into your email channels and allowing you to instruct receiving servers on how to handle emails that fail authentication. Learn about a simple guide to DMARC, SPF, and DKIM.
Views from the trenches
Best practices
Always identify the true envelope from address (Return-Path) for each service, as this is what SPF authenticates.
Consolidate all legitimate sending sources into a single SPF record, using 'include' mechanisms where appropriate.
Regularly review your SPF record, especially after adding or removing email sending services, to ensure it remains accurate and optimized.
Common pitfalls
Creating multiple SPF TXT records for the same domain, which leads to 'PermError' and authentication failure.
Exceeding the 10-DNS lookup limit by including too many external services or unnecessary 'a'/'mx' mechanisms.
Not accounting for all email sending services, causing legitimate emails to fail SPF checks.
Expert tips
If you set up custom bounce domains for services like Amazon SES, publish separate SPF records for those subdomains.
While 'mx' and 'a' mechanisms are not inherently wrong, consider removing them if your primary domain's A or MX records don't directly send email, to save on DNS lookups.
After implementing any changes, send test emails from all your services and examine the 'Authentication-Results' and 'Return-Path' headers for successful SPF validation.
Expert view
Expert from Email Geeks says SPF records are tied to the domain in your envelope from address, not the visible 'From' address in the mail client.
2021-09-02 - Email Geeks
Marketer view
Marketer from Email Geeks says SPF specifies which IP addresses are authorized to use the domain for which the SPF record is set. 'Mx' allows the MX server's IP, and 'a' allows the A record's IP.
2021-09-02 - Email Geeks
Ensuring optimal email deliverability
Mastering SPF configuration when using multiple email sending services boils down to one fundamental principle: you must consolidate all authorized sending sources into a single, well-structured SPF TXT record for each domain or subdomain. Adhering to the single record rule and carefully managing your DNS lookups are crucial to avoid authentication failures and ensure your emails reach the inbox.
The process involves a thorough audit of all your sending platforms, understanding which domain is used in the Return-Path: header, and then meticulously combining the required include mechanisms and IP addresses. Regular validation and ongoing monitoring are key to maintaining the integrity of your SPF record.
By following these best practices, you enhance your email security posture and significantly improve your email deliverability, protecting your brand reputation and ensuring your messages reliably land in recipient inboxes.
Google Workspace for internal communications, 
Amazon SES for transactional emails, and a dedicated email marketing platform for campaigns. The challenge arises when all these services need to send emails using the same domain, such as yourdomain.com.
Amazon SES
