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.
What Does Error 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.
Common Causes
- 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 Error 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
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.
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.
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.
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.