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
A straightforward way to avoid the 10 DNS lookup limit is to delegate different sending services to subdomains, each with its own SPF record. Because SPF is evaluated on the RFC5321.MailFrom domain, every subdomain receives its own SPF evaluation and its own 10 DNS lookup budget.
The visible RFC5322.From address does not need to change and can still use the apex domain (for example user@yourdomain.com). As long as the Return-Path uses a subdomain of the same organizational domain, DMARC will still pass with relaxed alignment.
The only scenario where this approach may cause issues is when strict SPF alignment (aspf=s) is configured in DMARC, since strict alignment requires the domains to match exactly.
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!