spf=permerror

spf=permerror means the receiver found the bounce-address domain's SPF record but could not make sense of it. Unlike a temperror, this won't clear up by retrying: someone has to change the DNS. Until then, every message from the domain gets no SPF result, good or bad.

What the RFC says

RFC 7208 §2.6.7 defines permerror as published records that can't be correctly interpreted, a condition that definitely needs the DNS operator to step in. §8.7 notes that a receiver rejecting for this reason should use 550 with enhanced code 5.5.2. The rest of the RFC lists the specific ways a record ends up here.

The usual suspects, in order

1. Too many DNS lookups. include, a, mx, ptr, exists and redirect each cost a lookup, and an evaluation may use at most 10 in total, counting everything pulled in through includes (§4.6.4). Adding a fourth or fifth email service is the classic way to go over. The same section caps "void" lookups, those that return nothing, at two by default.
2. Two SPF records. A domain must not publish more than one v=spf1 record (§3.2), and finding two produces permerror (§4.5). This usually happens when a new service's setup guide says "add this TXT record" and someone adds it instead of merging.
3. A syntax error anywhere. A typo such as inlcude:, ip4:192.0.2.0/33 or a stray character invalidates the whole record before any evaluation (§4.6).
4. An include or redirect pointing at nothing. If an include: target has no SPF record, the include returns permerror, not none (§5.2), and the same goes for redirect= (§6.1). This happens when a provider retires an old include hostname.

Received-SPF: PermError (mx.example.org: permanent error in processing
       during lookup of example.com: too many DNS lookups) client-ip=198.51.100.9;
Authentication-Results: mx.example.org;
       spf=permerror smtp.mailfrom=example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

If you received this message

The error is the sender's configuration problem, not a sign of forgery. DMARC only counts an aligned SPF pass (RFC 9989 §5.3.5), so a broken record contributes nothing and DKIM has to carry the message, as it does above. If DKIM is missing too, the message has no authentication at all. The analyser will show that.

If you own the domain

Pull your TXT records and check that there is exactly one beginning v=spf1. Count the lookup terms, expanding every include. If you are over 10, drop services you no longer use, replace a and mx with explicit ip4:/ip6: ranges, or move a service onto its own bounce subdomain with its own record. "Flattening" includes into IP lists works, but it goes stale silently when the provider changes its ranges. Then send yourself a test message and confirm the header shows pass.