Email Authentication & Deliverability Studio
See what uses your SPF lookup budget and generate DMARC and SPF records
- SPF lookup budget
- SPF dependency tree
- Safe SPF flattening
About Email Authentication & Deliverability Studio
Enter a domain to see which SPF terms use the 10 DNS lookups RFC 7208 allows, as a tree of every include and the records behind it. The studio explains each problem, can produce a flattened SPF record where that is safe, builds a DMARC record from a short form, and checks a DKIM selector you name. Every generated record comes with its host, type and value to copy. It reads published DNS only, so it cannot tell you how a receiving mail system will treat your messages.
The SPF 10-lookup limit
Some SPF terms make the receiving server look up more DNS records: include, a, mx, ptr, exists and the redirect modifier. RFC 7208 allows 10 of them across the whole check, including every record an include pulls in. The limit is about the total, not how deeply records are nested, so two includes that each contain five more already use 12.
When a check needs more than 10, receivers may stop and return a permanent SPF error, and that can make DMARC fail too. ip4, ip6 and all never cost a lookup.
Reading the dependency tree
Each provider you add usually publishes its own record, which can include others. The tree shows every term in the order receivers evaluate it, the DNS record type it queries, whether it costs a lookup and the running total, plus the addresses it resolves to. Loops, missing include targets and names with no records are flagged where they occur. The same tree is available as plain text you can copy.
When SPF flattening helps
Flattening replaces include, a and mx terms with the IP ranges they resolve to today, which removes their lookups. The result is a snapshot: when a provider changes its addresses, a flattened record goes out of date and real mail can fail SPF.
- Remove includes for services you no longer use before flattening anything.
- Terms that cannot be replaced without changing what the record allows are kept and explained.
- Review the generated record and re-check it regularly.
What this studio can’t see
It reads published DNS only. It does not send or receive email, verify DKIM signatures on real messages, test DMARC alignment or predict inbox placement. Results reflect DNS at the moment of the check.
Further reading
Questions people ask
- Which SPF terms count toward the lookup limit?
- include, a, mx, ptr, exists and redirect each count once, wherever they appear in nested records. ip4, ip6 and all are free, and exp is only fetched after a failure.
- Is SPF flattening safe?
- It reduces lookups, but the record must be re-checked because providers change their addresses. The studio replaces only terms whose meaning it can keep and lists the rest with a reason.
- Which DMARC policy should I start with?
- Start with p=none and a reporting address. Once reports show every legitimate sender passes, move to quarantine and then reject.
- Does the studio guess DKIM selectors?
- No. It checks only the selector you enter. Suggested names just fill the field; find yours in your provider’s DKIM settings or the s= value of a DKIM-Signature header.