550 DKIM Verification Error

A 550 DKIM Verification Error (and its standardized variants 550 5.7.20, 550 5.7.21, 550 5.7.22) is a permanent rejection returned by the receiving mail server: it tried to verify the DKIM signature on your message and the verification did not pass (or no usable signature was found), so the message was refused rather than accepted or quarantined. The 550 class is a permanent negative completion reply per RFC 5321 §4.2.1 — retrying the same message unchanged will not help.

Note: "DKIM Verification Error" is not a single verbatim RFC reply string. Different MTAs phrase it differently. The standardized enhanced codes are X.7.20 "No passing DKIM signature found", X.7.21 "No acceptable DKIM signature found" (one or more signatures passed, but none are acceptable), and X.7.22 "No valid author-matched DKIM signature found" (none of the passing signatures match the From: author domain), all with a basic code of 550 per RFC 7372 §3.1. A related but broader code, 550 5.7.26, is what Gmail (and other large receivers) return for "unauthenticated email ... not accepted due to [the domain's] DMARC policy" — it signals that the message failed more than one authentication check (RFC 7372 §3.4 calls X.7.26 "Multiple authentication checks failed"), typically meaning neither SPF nor DKIM produced an aligned pass, rather than a single DKIM signature problem.

What causes a 550 DKIM Verification Error?

DKIM (RFC 6376) signs selected headers and the body of your message with a private key and publishes the matching public key in DNS at selector._domainkey.yourdomain. Verification fails — and a stricter receiver returns 550 — for these distinct reasons:

• Missing or malformed public key in DNS. The selector._domainkey TXT record is absent, was deleted, has a broken/split p= value, or contains a typo. The verifier does a DNS lookup, can't retrieve a usable key, and fails the check.
• The message was modified after signing. A mailing list, forwarding rule, antivirus/security gateway, or appended footer/disclaimer changed a signed header or the body. The body hash (bh=) or signature (b=) no longer matches, so the signature is invalid even though the key is fine. This is the single most common real-world cause.
• Key mismatch / rotation. The private key the signer is using no longer corresponds to the public key in DNS (e.g., keys were rotated but DNS wasn't updated, or stale DNS is still cached).
• DMARC alignment failure. Even a passing DKIM signature is rejected under DMARC (RFC 9989, obsoletes RFC 7489) if the signing domain (d=) does not align with the From: header domain and the published DMARC policy is p=reject. This is the X.7.22 case; when both SPF and DKIM fail to align, large receivers such as Gmail return 550 5.7.26.

How do I fix a 550 DKIM Verification Error?

Read the bounce first — the enhanced code tells you which branch you're in (5.7.20/5.7.21 = signature didn't pass; 5.7.22 = DKIM didn't align to the From domain; 5.7.26 = the message failed more than one auth check and was refused under DMARC).

1. Find the selector and signing domain. Look at the DKIM-Signature header of a sent message and note the s= (selector) and d= (domain) tags.
2. Confirm the public key resolves. Query DNS directly:

dig TXT selector._domainkey.yourdomain.com +short

You should get back a single logical TXT record containing v=DKIM1; k=rsa; p=<base64 key>. If it's empty, split incorrectly across quoted strings, or p= is truncated, republish it exactly as your ESP/provider specifies.

3. Test the full signing path with a real send. Send to a validator (e.g., a check-auth@ mailbox or your provider's DKIM tester) and read the Authentication-Results header. dkim=pass confirms the key and signer are correct; dkim=fail with body hash did not verify points to message modification.
4. If the body hash fails, stop post-signing rewrites. Disable footer/disclaimer injection, "safe links"/attachment rewriting, or list-server modifications on the signed path — or sign after those steps. For forwarded mail that breaks DKIM, ARC or relaxing the affected hop is the path, not changing the key.
5. If it's an alignment failure (5.7.22, or 5.7.26 where DMARC refused unauthenticated mail), make the DKIM d= domain align with your visible From: domain (a subdomain like mail.yourdomain.com satisfies DMARC relaxed alignment; an unrelated ESP domain does not). Verify your DMARC record at _dmarc.yourdomain.com.
6. Allow for DNS propagation. After publishing or correcting the record, wait for TTL/caches to clear (commonly up to a few hours, occasionally longer) before re-testing.

If you send through Courier, configure DKIM on the underlying email provider you've connected (e.g., SendGrid, Amazon SES, Mailgun, Postmark) and publish that provider's DKIM/CNAME records on your domain — the receiver verifies against the provider's signature, so the records must match what that integration signs with.