How to fix “SPF PermError” from all mailbox providers
DMARC reports show SPF result “permerror”, and some legit mail lands in spam even though your SPF record looks correct.
Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English. Run the free check →
What this means
SPF allows a maximum of 10 DNS lookups. Every include:, a, mx, exists and redirect counts. Stack Google Workspace + a newsletter tool + a CRM + a helpdesk and you're over the cap — receivers then treat SPF as broken.
How to fix it
Step 1. Count your lookups (our checker counts them recursively, including nested includes).
Step 2. Remove includes for services you no longer use — old ESPs linger in records for years.
Step 3. Don't flatten manually to IP lists: providers rotate IPs and your record silently rots.
Step 4. If you legitimately need many services, use a dynamic/hosted SPF that stays under the cap automatically.
Frequently asked
How long until fixes take effect?
DNS changes propagate within minutes to 48 hours. Mailbox providers pick up the new records on their next check — most senders see bounces stop within a day of correct configuration.
Does this apply if I send fewer than 5,000 emails a day?
Formal enforcement targets bulk senders, but partial authentication already costs you inbox placement at every volume — and spoofing protection matters regardless of how much you send.
Can I just ask my hosting provider to fix it?
Hosting support can add DNS records for you, but they don't know which services send as your domain. You (or a monitoring tool reading your DMARC reports) have to provide that list — that's the actual hard part.
Don't want to babysit DNS records? DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection. Start free monitoring →