免费注册

SOLVE SPF "TOO MANY DNS LOOKUPS" ISSUE CAUSING "PERMERROR".
AUTOMATICALLY AUTHORIZE YOUR EMAIL SENDING SOURCES.

REQUEST A DEMO

"TOO MANY DNS LOOKUPS" PROBLEM AND
SPF 10 DNS LOOKUP LIMITATION

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.

Before SPF flattening

v=spf1 include:amazonses.com include:_spf.google.com -all

After SPF flattening

v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20 ip4:76.223.180.0/23 ip4:76.223.188.0/24 ip4:76.223.189.0/24 ip4:76.223.190.0/24 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/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:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 -all

THE PROBLEMS WITH SPF FLATTENING

Included records can be changed during the time

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 TXT record's 512 bytes limitation related to UDP packet size

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.

SPF flattening with nested includes can exceed 10 DNS lookup limitation

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.

DMARC "QUARANTINE" and "REJECT" POLICY
REJECTS UNAUTHENTICATED BUT LEGITIMATE EMAILS

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.

EASYSPF

is a smart and adaptive SPF record to overcome "Too many DNS lookups" problem
and to automatically authorize email sending providers

TRY NOW

HOW EASYSPF WORKS

You just add a single include in your SPF record which points to our server and we take care of the rest.

Solution for "Too many DNS lookups"

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.



Solution to "Unauthenticated, but legitimate email rejections"

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.

Easy SPF how it works illustration

BENEFITS OF USING EASYSPF

Overcome "Too many DNS lookups" issue

causing "permerror" result by optimizing your SPF record

Repair your SPF record

causing SPF permanent errors ("permerror")

Add, remove, update lots of email service providers

without being concerned about SPF 10 DNS lookup limitation

Mitigate and avoid outgoing emails' loss

by automatically authorizing new email sending sources even when your DMARC policy is "quarantine" or "reject"