dkim=permerror

dkim=permerror means the receiver could not verify the DKIM signature and retrying won't help. Something about the signature or the published key is wrong in a way only the domain owner can fix. The most common version by far: the key the signature points to isn't in DNS.

What the RFC says

RFC 8601 §2.7.1 defines permerror as an unrecoverable error, and gives "a required header field being absent" as its example. RFC 6376 does not have a separate "permerror". It groups everything permanent under PERMFAIL (§3.9), including a plain cryptographic mismatch. So the line between permerror, fail and neutral is drawn by each receiver. As a rule, permerror covers the setup problems RFC 6376 lists in §6.1.1 and §6.1.2:

• No key for the signature (§6.1.2, step 3). Nothing at selector._domainkey.domain.
• Revoked key: a record with an empty p= (step 7).
• Malformed key record (step 5), or a key that doesn't match the signature's algorithm (step 8).
• Signature problems (§6.1.1): a required tag missing, From not listed in h=, or an i= domain that isn't d= or a subdomain of it.
• Outlawed crypto. RFC 8301 says rsa-sha1 signatures (§3.1) and RSA keys shorter than 1024 bits (§3.2) count as permanently failed.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=march; ...
Authentication-Results: mx.example.org;
       dkim=permerror (no key for signature) header.d=example.com header.s=march;
       spf=softfail smtp.mailfrom=example.com;
       dmarc=fail header.from=example.com

How it usually happens

1. The selector record was never published, or was published wrong. Common mistakes: the domain doubled up (march._domainkey.example.com.example.com, because the DNS panel adds the zone automatically); a key pasted with quotes, spaces or line breaks in the middle; or a CNAME that the email service told you to add but nobody did.
2. A key rotated out too soon. The old selector was deleted while mail signed with it was still in queues, or before someone re-checked old messages.
3. Moving to a new provider. The new service signs with its selector before its record exists.
4. Legacy software still signing with rsa-sha1 or a 512-bit key.

If you received this message

It is a configuration fault at the sender, not evidence of forgery. But the signature now counts for nothing. In the snippet, SPF didn't pass either, so DMARC failed and the domain's policy applies. Check the Received chain before deciding.

If you own the domain

Take s= and d= from the failing signature and query the TXT record at s._domainkey.d. If it's missing, publish what your provider gives you. If it's present, check that it parses: v=DKIM1; k=rsa; p= followed by one unbroken base64 string. Re-send a test until you see dkim=pass. When you rotate keys, leave the old selector published for at least a few days.