If email providers report SPF PermError (permanent error), your outgoing messages may fail SPF checks. Many receivers treat SPF PermError as “fail” or at least reduce trust, which can impact deliverability.
The most common causes are:
- Multiple SPF records for the same domain (more than one TXT record starting with
v=spf1).
- Too many DNS lookups in a single SPF evaluation (the SPF specification limits this).
Step 1 — Make sure you have only ONE SPF record
Your domain should have a single TXT record that starts with v=spf1.
Wrong: two separate SPF TXT records:
v=spf1 include:_spf.google.com -all
v=spf1 include:mailgun.org -all
Correct: one combined SPF record:
v=spf1 include:_spf.google.com include:mailgun.org -all
Step 2 — Reduce DNS lookups (10-lookup limit)
SPF processing has a DNS lookup limit. Each include:, a, mx, ptr, exists, and redirect= can trigger lookups.
If you exceed the limit, SPF can return PermError.
How to reduce lookups
- Remove providers you no longer use (old includes).
- Avoid chaining too many includes (include → include → include).
- If you send from a fixed IP, replace an include with
ip4:/ip6: where appropriate.
- Use subdomains for different systems (for example, separate transactional email from main domain).
Step 3 — Publish the corrected SPF record in DNS
Add/replace the SPF TXT record at the DNS provider that hosts your domain’s DNS zone:
- My.GARMTECH DNS Management (if you use
ns1.garmtech.com, ns2.garmtech.com, ns3.garmtech.com), or
- Plesk DNS Settings (if you manage DNS in Plesk), or
- Your external DNS provider (Cloudflare, etc.).
Step 4 — Verify after propagation
- Check that only one SPF record exists.
- Send a test email to a mailbox that shows authentication results (SPF/DKIM/DMARC).
Notes
- Do not use
+all (it disables SPF protection). Use ~all (softfail) or -all (fail) based on your policy.
- If you use DMARC, SPF alignment matters. Use the correct domain for sending and return‑path.