DNS lookup constraint and scope of analysis

The Too many included lookups error is caused by the DNS Lookup Limits defined in RFC 7208, 4.6.4:

The following terms cause DNS queries: the include, a, mx, ptr, and exists mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.

While we cannot determine whether any of your include mechanisms can be removed or simplified – since only you know which email infrastructure sends messages using your domain in the envelope sender – we can help evaluate what causes the additional DNS lookups and by how much the limit is exceeded.

SPF evaluation analysis

The evaluation of your SPF policy currently triggers twelve DNS queries:

(For brevity, ip4 and ip6 mechanisms have been replaced with ..., as they do not trigger additional DNS queries.)

Or a tree view:

• initial
  • a:mail.example.com
  • include:no-ip.com
    • include:_spf.hostedemail.com
    • include:sendgrid.net
      • include:ab.sendgrid.net
    • include:mail.zendesk.com
  • include:_spf.google.com
  • include:spf-1.xmailer.com.br
    • include:spf-xm1.xmailer.com.br
    • include:spf-ll.xmailer.com.br
      • include:spf-ll2.xmailer.com.br

Conclusions and recommendations

Your SPF record exceeds the DNS lookup limit by two queries. The main contributors to the excess lookups are the long SPF include chains used by no-ip.com and spf-1.xmailer.com.br. Fully flattening the SPF record is generally not practical to maintain. However, if neither of these includes can be removed, minimal changes could still reduce the number of DNS queries below 10.

• Replace a:mail.example.com with explicit ip4/ip6 mechanisms. If an existing ip4 entry already covers the mail server, the a mechanism is redundant and can be removed.
• spf-1.xmailer.com.br contains only include mechanisms, which can be referenced directly as include:spf-xm1.xmailer.com.br and include:spf-ll.xmailer.com.br.

These changes reduce the number of DNS lookups by two, bringing the configuration to the limit threshold. However, any additional include will cause the limit to be exceeded again. This is most likely to occur within third-party SPF include chains already subject to these sorts of practices. As an additional recommendation, review the no-ip.com dependency in particular to determine whether all included services are actually required – for example, whether only specific providers such as sendgrid.net or zendesk.com are in use.