Enhanced Status Code 5.7.14: DKIM Verification Failed

Permanent failure High severity Security RFC 6376

What it means

Enhanced Status Code 5.7.14 means “DKIM Verification Failed.” Your email had a DKIM signature but it failed verification. The message was modified in transit, the DKIM key in DNS does not match, or the signature is malformed. This causes authentication failure and potential DMARC rejection.

At a glance

Code5.7.14

Bounce typeHard (permanent)

SeverityHigh

CategorySecurity

What to doSuppress the address; do not retry

StandardRFC 6376

What it looks like in your mail logs

dkim=fail (body hash did not verify) header.d=example.com; 550 5.7.14 DKIM signature verification failed for this message

What does 5.7.14 mean?

Enhanced status code 5.7.14 means your email included a DKIM signature, but when the receiving server tried to verify it, the verification failed. This is worse than having no DKIM at all - a failing DKIM signature actively hurts your deliverability because it suggests the message was tampered with.

Common causes include the message being modified after signing (by a mailing list, forwarding server, or security appliance), the DKIM public key in DNS not matching the private key used for signing, or the DNS record being malformed. If you have a DMARC policy and DKIM fails, the message may be rejected entirely.

Use our DKIM Checker tool to verify your DKIM DNS record is correctly published and the public key is valid.

How 5.7.14 plays out

Your server attempts delivery

The recipient server returns a permanent 5.7.14 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.14 sits: soft vs hard bounce

	Soft bounce (4xx)	Hard bounce (5xx)
Nature	Temporary	Permanent
SMTP class	`4xx`	`5xx`
What to do	Let it retry	Suppress the address
Recoverable?	Often	No
5.7.14 is		✓ this code

Common causes of 5.7.14

Message was modified in transit after DKIM signing (content, headers, or attachments changed)
DKIM public key in DNS does not match the private key used for signing
DNS record for DKIM key is malformed or has incorrect syntax
Mailing list or forwarding server modified the message body
DKIM key has been rotated but old key is still in use for signing
Security appliance (anti-virus, content filter) modified the message after signing

How to fix 5.7.14

Verify your DKIM DNS record using a DKIM Checker tool
Ensure the private key used for signing matches the public key in DNS
Check for intermediary servers that might modify messages after signing
If using a forwarding or mailing list, implement ARC (Authenticated Received Chain)
Regenerate and publish a new DKIM key pair if the current one is compromised or mismatched

Frequently asked questions

What does SMTP error 5.7.14 mean?

Error 5.7.14 indicates that a required trust relationship for email authentication could not be established. According to the IANA registry of SMTP enhanced status codes, X.7.14 means the server requires a configured trust relationship with a third-party server to process the message. In practice, this often appears when DKIM verification fails or when the sending server cannot establish the required cryptographic trust with the recipient server.

How do I fix a DKIM verification failure that causes email bounces?

First, verify your DKIM DNS record is correctly published by using a DKIM lookup tool; check for syntax errors, correct selector names, and key lengths of at least 1024 bits (2048 bits recommended). Ensure your mail server is signing outbound messages with the correct private key matching the public key in DNS. If you use email security gateways or forwarding services, confirm they are not modifying the message body or headers after DKIM signing, as any alteration breaks the signature.

Why does DKIM fail after email forwarding?

DKIM signatures cover specific message headers and the body content. When a forwarding server modifies the message, by adding footers, rewriting headers, or altering formatting, the DKIM signature becomes invalid because the cryptographic hash no longer matches. This is a known limitation of DKIM. The solution is ARC (Authenticated Received Chain), which allows trusted intermediaries to preserve authentication results. Ensure your forwarding servers support ARC sealing.

What is the difference between 5.7.14 and 5.7.26 email errors?

Error 5.7.14 specifically relates to a missing trust relationship or cryptographic authentication failure at the server level, often involving DKIM key validation. Error 5.7.26 indicates a broader DMARC policy failure where the email failed both SPF and DKIM alignment checks. You may see 5.7.14 when the DKIM mechanism itself is broken (missing key, wrong selector), while 5.7.26 appears when authentication fails at the DMARC policy evaluation stage.

Related bounce codes

Sources & further reading

RFC 6376 · The standard that defines this reply code IETF Datatracker · RFC 8601 defines the Authentication-Results header used to report dkim=fail verification results Google Workspace Admin Help · Email sender guidelines requiring DKIM authentication that aligns with the From domain

Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes