Most companies use multiple email service providers and every provider requires its own email authentication configurations. If provider supports SPF authentication, then you must include their SPF mechanism into your domain's SPF record. However, this can quickly breach the 10 DNS lookup limit and cause "permerror" results. SPF "permerror" result means the domain's published records can not be correctly interpreted and the domain's owner must take an action to solve the issue.
To reduce the number of DNS lookups, you have to replace the elements causing additional DNS lookups ("a", "mx", "ptr", "exists", "redirect" and "include"), with the elements not causing any lookup ("ip4" and "ip6"). That process is also called SPF flattening.
For example, let's assume you use G Suite and AmazonSES.
v=spf1 include:amazonses.com include:_spf.google.com -all
v=spf1 ip4:188.8.131.52/22 ip4:184.108.40.206/22 ip4:220.127.116.11/18 ip4:18.104.22.168/20 ip4:22.214.171.124/23 ip4:126.96.36.199/24 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11/24 ip4:18.104.22.168/19 ip4:22.214.171.124/20 ip4:126.96.36.199/20 ip4:188.8.131.52/18 ip4:184.108.40.206/16 ip4:220.127.116.11/21 ip4:18.104.22.168/16 ip4:22.214.171.124/17 ip4:126.96.36.199/19 ip4:188.8.131.52/19 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ip4:184.108.40.206/19 ip4:220.127.116.11/20 ip4:18.104.22.168/19 ip4:22.214.171.124/20 ip4:126.96.36.199/19 ip4:188.8.131.52/19 ip4:184.108.40.206/16 ip4:220.127.116.11/22 -all
SPF flattening is not one time task. You need to always be aware of any changes that could be made by email service providers in their SPF, which you include in your SPF record, and do not delay with updating your flattened SPF record accordingly. If you use multiple email service providers, then flattening the SPF record every time is even harder and error-prone.
SPF's TXT record can't have infinite length. So if flattened SPF record has more than 460 symbols, the record must be split into multiple SPF record chunks and be managed separately.
Even with 512-byte flattened SPF record chunks, you can exceed 10 DNS lookup limitation. So you need to include SPF macroses instead of simple IP and IP ranges in SPF record.
When deploying DMARC your goal is to correctly identify existing email authentication issues, fix SPF/DKIM and reach "quarantine" or "reject" policy. However, after moving to quarantine/reject policy, new legitimate email sending sources can appear out of your control (e.g. newly hired marketing person decides to use another and more familiar product for email marketing). You will "lose" all emails sent from new sending source and waste money. To mitigate the loss, you need to be informed and react to new changes as soon as possible.
You just add a single include in your SPF record which points to our server and we take care of the rest.
EasySPF's engine uses SPF flattening and/or SPF macroses to create nested SPF chunks. The engine constantly checks for every change in original SPF record, and updates SPF chunks within a couple of minutes. So it combines all your authorized services correctly at the point of query.
EasySPF engine uses DMARC aggregated reports to detect a new sending source. We have a trusted configuration instructions' data about ~1070 email service providers. Based on that data and IP addresses as well, the smart engine automatically detects the provider and updates the SPF record to authorize new sending source. Sometimes it asks you to confirm the new source, as some of sources can be identifed as "grey" and require user's knowledge and interaction.
causing "permerror" result by optimizing your SPF record
causing SPF permanent errors ("permerror")
without being concerned about SPF 10 DNS lookup limitation
by automatically authorizing new email sending sources even when your DMARC policy is "quarantine" or "reject"