5.7.22

Enhanced Status Code 5.7.22: No Valid Author-Matched DKIM Signature Found

Permanent failure High severity Authentication RFC 7372
What it means

Enhanced Status Code 5.7.22 means “No Valid Author-Matched DKIM Signature Found.” DKIM passed, but the signing domain does not match the author address in the From header. This is a DKIM alignment failure stated in its own code rather than folded into a DMARC result.

At a glance
Code5.7.22
Bounce typeHard (permanent)
SeverityHigh
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7372
What it looks like in your mail logs 
550 5.7.22 No valid author-matched DKIM signature found: d= does not match the From header domain

What does 5.7.22 mean?

Enhanced status code 5.7.22 means no valid author-matched DKIM signature was found. RFC 7372 defines it for a message that contains passing DKIM signatures where none carry an identifier matching the author address in the From header. It is DKIM alignment, expressed directly.

This is the failure mode that confuses people most, because every visible check looks healthy. The Authentication-Results header shows dkim=pass. The signature verifies. And the message is still refused, because the domain that signed it is not the domain your recipient sees. Sending platforms commonly sign with their own domain by default, which produces exactly this: a valid signature belonging to the platform rather than to you.

The fix is to sign as your own domain. Every serious sending platform supports a customer DKIM key, usually as a CNAME or TXT record you publish under a selector on your own domain, and most do not enable it automatically. Until that is configured, DKIM protects the platform's reputation rather than yours, and any DMARC policy you publish cannot be satisfied through the DKIM path.

How 5.7.22 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.22 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.22 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.22 is✓ this code

Common causes of 5.7.22

  • The sending platform signs with its own domain rather than a key belonging to you
  • A customer DKIM key was never configured for the account
  • The signature uses a subdomain while DMARC is set to strict DKIM alignment
  • The From header was changed to a different domain after signing was set up
  • A forwarding service re-signed the message with its own domain
  • Multiple platforms send as your domain and only some sign as you

How to fix 5.7.22

  • Configure a customer DKIM key so the platform signs with your domain and selector
  • Compare the d= value in the DKIM-Signature header against your From domain
  • Check adkim in your DMARC record, since strict alignment rejects subdomain signatures
  • Repeat the check for every platform that sends as your domain
  • Read DMARC aggregate reports, which report alignment separately from pass and fail
  • Where mail is forwarded, verify whether ARC is preserving the original result

Frequently asked questions

What does 5.7.22 mean?
It means the message had a valid DKIM signature, but the domain that signed it does not match the domain in the From header. That is a DKIM alignment failure. The signature is genuine and verifies correctly; it simply belongs to somebody else, usually your sending platform rather than you.
How do I check which domain signed my message?
Look at the d= tag in the DKIM-Signature header of a delivered message and compare it to the domain in your From header. If d= names your sending platform rather than your own domain, the signature is not author-matched and this code is the result. Authentication-Results will still show dkim=pass, which is why the header alone is misleading.
Why does dkim=pass appear if alignment failed?
Because they measure different things. dkim=pass means the cryptographic signature verified, which it did. Alignment asks a further question: does the signing domain match the visible author? A message can pass the first and fail the second, and that combination is exactly what 5.7.22 reports.
How is 5.7.22 different from 5.7.32?
They overlap in cause and differ in scope. 5.7.22 is registered by RFC 7372 and speaks only about DKIM author matching. 5.7.32 is a Google code covering the From header not aligning with SPF or DKIM, so it includes the SPF path as well. If you see either, the investigation is the same: find out which domain actually authenticated.
Does strict DKIM alignment cause this?
It can. With adkim=r, the relaxed default, signing as mail.yourdomain.com aligns with yourdomain.com. With adkim=s the match must be exact, so a subdomain signature fails. If you have set strict alignment, either sign with the exact From domain or relax the tag.

Related bounce codes

5.7.20 No Passing DKIM Signature Found 5.7.21 No Acceptable DKIM Signature Found 5.7.32 From Header Not Aligned with SPF or DKIM 5.7.26 DMARC Authentication Failed 5.7.23 SPF Validation Failed

Sources & further reading

RFC 7372 · The standard that defines this reply code RFC 7372 · Email authentication status codes, which define the DKIM and SPF codes Google email sender guidelines · The February 2024 authentication requirements for bulk senders
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes