SPF PermError: too many DNS lookups
Receivers stop reading SPF after 10 lookups and call the whole record broken, so your real invoices and password resets fail SPF too. Check yours, then bring it back under.
Free, with no sign-up. Takes a few seconds.
SPF lists the servers allowed to send mail as your domain. Reading it can mean further DNS lookups: every include:, a, mx, ptr, exists: and redirect= costs one, and so does everything inside the records they include. The standard (RFC 7208) caps the total at 10.
Past 10, the receiver stops and returns PermError. DMARC treats that as a fail, so unless your DKIM signature passes and matches your domain, real mail is handled like a fake: spam folder, or rejected outright if your DMARC policy says so.
ip4:, ip6: and all cost nothing, which is why they are the way back under the limit.
v=spf1 include:_spf.google.com
include:mailgun.org include:sendgrid.net
include:servers.mcsv.net ~allEach newsletter, helpdesk, CRM and invoicing tool asks for its own include. Nobody removes the ones you stopped using.
include:_spf.example
include:_netblocks1
include:_netblocks2A single include can cost three or four lookups, because providers nest their own records.
+2 without you touching DNSProviders edit their own records whenever they like. You can go over the limit with no change on your side.
a mx ptr include:old-host.examplea and mx are often copied from a template even when your web and mail servers never send mail, and ptr is slow and discouraged.
Go through every include and name the service behind it. Remove any you have stopped using. This alone fixes most records.
Drop a, mx and ptr unless those servers actually send mail as your domain.
Let your newsletter or marketing tool send from something like news.yourdomain.com, with its own SPF record. Each name gets its own 10 lookups, and your main domain's reputation is kept apart.
Replacing an include with the provider's ip4: ranges costs no lookups, but providers change their ranges without telling you, and a stale record quietly fails. Only flatten what you will keep up to date, or have it watched.
Run the check above. Because providers change their own records, the count can creep back over without any edit from you, which is the change a Tripline alert catches.
No. Only mechanisms that need a DNS lookup count: include, a, mx, ptr, exists and redirect, plus everything inside the records they pull in.
Because the records you include have includes of their own. The count follows the whole tree, which is why a checker that only counts your own record gets it wrong.
No. The ending only says what to do with servers you didn't list. It costs no lookups.
DMARC passes when either SPF or DKIM passes and matches your domain, so signed mail can still get through. A PermError still counts against you with some receivers and leaves mail that isn't signed unprotected, so fix it anyway.
Free for one site. We look every 6 hours and only write when something changes.