SPF Macros: Overcoming the 10 DNS Lookup Limit
If your domain relies heavily on third-party services to send emails on its behalf, you could encounter the DNS lookup limit outlined in section 4.6.4 of RFC7208, resulting in an SPF permerror. Without a correct DKIM configuration, emails may not pass DMARC checks, potentially leading to blocking or being redirected to spam folders.
Three typical solutions for this issue are utilizing subdomains for specific sending services, employing an SPF flattening service, or integrating SPF macros into your configuration. We'll outline these alternatives and explain why using SPF macros is probably the best solution.
Subdomains
The most straightforward approach to overcome the 10 DNS lookup limit is to assign a subdomain for each sending service that requires an SPF record. Having a unique SPF record for each subdomain makes the lookup limit a non-issue. However, this solution may lead to the From address displaying the subdomain, resulting in addresses like user@subdomain.yourdomain.com instead of user@yourdomain.com. Additionally, it could cause DMARC to fail SPF when SPF Identifier Alignment mode is set to strict (aspf=s).
SPF Flattening
Flattening an SPF record to include only ip4 and ip6 addresses will decrease the number of DNS lookups, but it is not a reliable solution. Email services frequently revise SPF policies, causing validation failures when new IP sources are added. While some online services offer dynamic flattening services, outsourcing your SPF to a third party is highly discouraged. By using an external service, you become dependent on their infrastructure and reliability. Should there be any downtime or interruptions in the service, it will affect the delivery of your emails. There's also a potential risk of unauthorized access, compromising your security. Ultimately, it's crucial to evaluate the service provider carefully, consider the potential risks, and assess whether the convenience offered outweighs the drawbacks and potential complications.
SPF Macros
Section 7 of RFC7208 discusses SPF Macros, suggesting their use to get around DNS size and lookup limitations, enabling a more dynamic and adaptable approach to email authentication.
SPF macros are placeholders within SPF records that are replaced with specific values during evaluation. These macros serve as dynamic variables, allowing senders to create more concise and manageable SPF records while accommodating multiple sources of email transmission.
The simplest method to utilize SPF Macros and minimize DNS lookups is by setting up distinct SPF policies for specific local parts. Typically, third-party services such as Postmark, Mailchimp Mandrill, Sendgrid, Salesforce, or Zendesk utilize only a limited number of email addresses, like support@example.com or mailing@example.com.
Without SPF Macros:
| Host | Type | Value |
|---|---|---|
| example.com | TXT | "v=spf1 include:_spf.google.com include:spf.mandrillapp.com include:sendgrid.net include:mail.zendesk.com include:_spf.salesforce.com ~all" |
With SPF Macros:
| Host | Type | Value |
|---|---|---|
| example.com | TXT | "v=spf1 include:_spf.google.com include:%{l}._spf.example.com ~all" |
| newsletter._spf.example.com | TXT | "v=spf1 include:spf.mandrillapp.com" |
| marketing._spf.example.com | TXT | "v=spf1 include:sendgrid.net" |
| support._spf.example.com | TXT | "v=spf1 include:mail.zendesk.com" |
| invoice._spf.example.com | TXT | "v=spf1 include:_spf.salesforce.com" |
Furthermore, implementing SPF macros in this manner boosts security by confining these services to sending emails solely from a specified address rather than providing them unrestricted access to any address within the entire domain.
Alignment
Keep in mind that email servers validate SPF using the RFC5321.MailFrom domain. Third-party services often use their domain for RFC5321.MailFrom to track and manage email bounces. Adding their SPF policy to your domain's SPF only increases your DNS lookup count without contributing anything since your SPF record isn't checked in this scenario. However, this isn't a problem, as the service managing the email is also in charge of the SPF policy. Never incorporate a third-party SPF record when your domain is not used as the RFC5321.MailFrom address.
DMARC
To ensure DMARC passes, you need at least DKIM or SPF to generate a pass result and align with the RFC5322.From domain. If DKIM is correctly configured, the absence of a valid SPF validation doesn't matter. However, it's highly recommended to use a SoftFail SPF policy (~all) to prevent receiving servers from potentially blocking messages during SMTP communication when a Fail SPF policy is specified (-all). Under these circumstances, DKIM, which has the potential to secure DMARC authentication and guarantee message delivery, is overlooked. For further guidance on SPF, DKIM, and DMARC best practices, refer to our blog here.
URIports
Configuring an SPF policy demands ongoing attention and upkeep. URIports provides robust tools that consistently validate and monitor your SPF policy, offering the convenience of automatic push notifications upon detecting any issues. Monitoring your DMARC records enables us to identify redundant SPF elements and recommend optimizations for greater efficiency. Begin your complimentary 30-day trial today!