Overcoming SPF Limits with Subdomains, SPF Flattening, and SPF Macros


When your domain relies heavily on third-party services for sending emails, you might encounter the DNS lookup limit as outlined in section 4.6.4 of RFC7208. This can lead to an SPF permerror. Without proper DKIM configuration, emails may fail DMARC checks, leading to them being blocked or marked as spam.


Here are three common solutions to this issue: using subdomains, SPF flattening, and implementing SPF macros. We'll discuss each approach, highlighting why SPF macros might be the most effective solution.

Subdomains

A straightforward method to bypass the 10 DNS lookup limit of SPF is to assign a subdomain for each sending service requiring an SPF record. This approach means each subdomain has its unique SPF record, effectively sidestepping the lookup limit issue. However, this method can lead to the From address displaying the subdomain, such as user@subdomain.yourdomain.com, which might not be desirable. Additionally, it could cause DMARC to fail SPF when the SPF Identifier Alignment mode is set to strict (aspf=s).


SPF Flattening

Flattening an SPF record to include only ip4 and ip6 addresses can decrease DNS lookups. However, this approach is not without its drawbacks. Email services often update their SPF policies, which can lead to validation failures when new IP sources are added. Some services offer dynamic flattening, but outsourcing your SPF record management to a third party is not recommended due to potential reliability and security risks.


Macros

Original SPF Record Without Macros:

example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:spf.smtpservice.com include:sendgrid.net include:email.freshdesk.com include:_spf.salesforce.com ~all"

This SPF record directly includes each third-party service, leading to an increased number of DNS lookups, potentially exceeding the SPF 10 DNS lookup limit.


Subdomain Records for Specific Services

Each subdomain SPF record is dedicated to a specific service (hard-coded email address). Most third party services are being used for a specific function, and this function is typically related to the local part of the email address. The local part of the email address (like newsletter@, marketing@, etc.) determines which SPF record is included. If the service sends from multiple addresses like Office 365 in this example we are not applying a macro, we leave the include in place. 



For emails sent from info@example.com:

info._spf.example.com.    TXT    "v=spf1 include:spf.smtpservice.com"

For emails sent from newsletter@example.com:

newsletter._spf.example.com.    TXT    "v=spf1 include:sendgrid.net"

For emails sent from support@example.com:

support._spf.example.com.    TXT    "v=spf1 include:email.freshdesk.com"

For emails sent from billing@example.com:

billing._spf.example.com.    TXT    "v=spf1 include:_spf.billingsoftware.com"


SPF Macros


example.com.    TXT    "v=spf1 include:spf.protection.outlook.com include:%{l}._spf.example.com ~all"


This SPF record includes Google's SPF and a macro reference (%{l}._spf.example.com), which dynamically includes the appropriate SPF record based on the local part of the email address.


Advantages of Using SPF Macros:

  • Reduced DNS Lookups: By dynamically including SPF records based on the local part, you avoid hitting the SPF 10 DNS lookup limit.
  • Enhanced Security: Restricts third-party services to send emails only from specified addresses, preventing them from having blanket authorization over your entire domain.
  • Flexibility and Scalability: Easily accommodates changes in third-party service IPs without needing to constantly update your main domain's SPF record.


Important Considerations:

  • Compatibility: Ensure that your email ecosystem supports SPF macros. Some systems might not fully support or recognize them.
  • Complexity: SPF macros can add complexity to your setup. Proper configuration and testing are vital to avoid potential issues.

By using SPF macros, you can create a more efficient, secure, and manageable email authentication environment, which is especially beneficial for domains utilizing multiple third-party email-sending services.