What 550 5.7.1 Means
Per RFC 6376, DKIM attaches a cryptographic signature to each message; receivers look up the signing domain's public key in DNS and verify the signature. Gmail returns 550 5.7.1 with 'DKIM signature verification failed' when the signature exists but doesn't verify. The signature can fail for two reasons: (1) the public key lookup failed, or (2) the message body or headers were modified after signing, invalidating the hash.
Gmail, Microsoft 365, Yahoo, and any receiver enforcing DKIM. DKIM enforcement is most strict at Gmail post-February 2024 bulk-sender rules.
DKIM selector TXT record is missing, returns wrong public key, or has a typo; the private key your mail server signs with doesn't match the published public key (key rotation without DNS update); a relay or mail-list software modified message content after signing; or the signing canonicalization is too strict for the actual transmission path.
How to Fix 550 5.7.1
- 1
Identify the selector and signing domain from the failed message
View the failed message's Authentication-Results header (or DMARC aggregate report). The DKIM record will tell you: d=signing-domain, s=selector. Those two values point to the DNS record: selector._domainkey.signing-domain. That record must publish the public key matching the private key your mail server signs with.
- 2
Verify the DKIM TXT record resolves
Look up the TXT record at selector._domainkey.yourdomain.com. It should return a record starting with 'v=DKIM1;' and including a 'p=' tag with the public key. If the record is missing or empty, that's your problem. Use the DKIM Generator at coldrelay.com/tools/dkim-generator to publish a correct record.
- 3
Confirm the public key matches the signing key
If the DNS record exists but DKIM still fails, your mail server's signing key doesn't match the published public key. Common cause: you rotated the key on the server but forgot to update DNS, or you have the wrong selector configured. Re-export the public key from your mail server and compare against DNS character-for-character.
- 4
Check for in-transit modification
If the keys match but DKIM still fails on certain messages, a relay is modifying content after signing. Common culprits: a mailing-list expander adding 'List-' headers, a corporate gateway prepending a confidentiality footer, or an inbound spam-scanner rewriting subject lines. Configure signing to use relaxed canonicalization (c=relaxed/relaxed) which tolerates minor whitespace changes.
- 5
Wait for DNS propagation after any update
DKIM updates propagate in 5-60 minutes for most receivers. Re-test with the Email Deliverability Test until DKIM passes consistently before resuming high-volume sends.
References
550 5.7.1 in the Cold Email Context
DKIM failures in cold email almost always come from one of three causes: missing DKIM record entirely on a self-hosted sender (rare, since most platforms publish for you), key-rotation desync (you generated a new key on the server but the DNS update lagged), or the signing-domain doesn't match the From-header domain so DKIM passes but doesn't align for DMARC. ColdRelay generates and publishes DKIM records as part of domain provisioning, rotates keys on a schedule that includes DNS updates, and signs with the customer's sending domain so alignment is always satisfied. The Domains page shows per-record DKIM status with the selector and key fingerprint, so any drift between server and DNS is visible at a glance.
Frequently Asked Questions
How long should a DKIM key be?
RFC 6376 recommends 2048-bit RSA keys minimum. 1024-bit keys are technically supported but increasingly flagged by receivers as weak. Modern tools default to 2048-bit. Ed25519 keys are also supported by some receivers but RSA-2048 is the safe default.
Can I have multiple DKIM selectors?
Yes — most domains publish multiple selectors so you can rotate keys without downtime (use the new selector for new sends while the old key validates in-flight messages). Common naming: 'cr1', 'cr2', or year-based names like 'kr2026q1'.
What does the d= field do in DKIM?
The d= field declares which domain is taking responsibility for the message. For DMARC alignment, d= must match (or be a subdomain of) the From-header domain. If d=sendgrid.net but From is yourdomain.com, DKIM may pass but DMARC alignment fails.
Why does DKIM fail after my email passes through a forwarding rule?
Forwarders often modify headers or body (adding 'Fwd:' to subject, footers, etc.), which invalidates the DKIM signature. ARC (Authenticated Received Chain, RFC 8617) was designed to solve this — it lets forwarders attest that authentication was valid at original delivery. Most major receivers honor ARC; smaller relays may not.