Email DNS Check

Invalid DKIM Key Format (Malformed TXT Record)

A DKIM public key must live in a single well-formed TXT record: `v=DKIM1`, optional `k=`, required `p=` base64, and no stray punctuation that splits the base64 across lines incorrectly in DNS. When mail systems export keys, admins sometimes paste PEM bodies, include headers, or stuff URL-encoded characters into DNS. The record then fails canonical parsing even though part of the string still looks like a key. Receivers refuse verification immediately; you will see DKIM=fail in Authentication-Results without ever reaching body hashing. This failure mode is distinct from weak key length—the cryptography never starts. Many issues come down to a missing DKIM record or a selector mismatch in DNS.

Updated for 2026 to reflect current Gmail, Outlook, and Yahoo behavior.

If signatures fail, check the DKIM selector troubleshooting guide.

Learn the bigger picture in our Email Authentication Explained guide and compare SPF vs DKIM vs DMARC to understand how these protocols work together.

Quick answer

  • Only base64 characters belong inside p=; PEM BEGIN lines are invalid there.
  • Some panels double-encode; the resulting TXT is not a DKIM record at all.
  • Whitespace inside quoted TXT must follow DNS concatenation rules.
  • Ed25519 keys use different k= labels—mixing tags between algorithms breaks resolution.

One-Minute Fix

Regenerate the selector from your sending platform, paste the exact single-line `v=DKIM1; … p=…` value the vendor outputs, remove PEM armor lines, and keep the record under your DNS host’s TXT length handling (split strings only if the host merges them correctly).

Well-formed DKIM TXT skeleton
DNS TXT
s1._domainkey.example.com TXT "v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCS..."

Compare to the vendor clipboard output line by line; any extra newline artifact inside the quoted block is suspect.

Run free check

Free live DNS check. No signup required.

Wrong vs correct setup

Wrong setup

Wrong setup
DNS TXT
s1._domainkey.example.com TXT "-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqG..."

PEM headers are not part of DKIM TXT. Parsers halt when unexpected tokens appear before or inside p=.

Correct setup

Correct setup
DNS TXT
s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Only RFC 6376 tag soup inside one TXT RR set; base64 stays contiguous per string segment rules.

Why malformed keys slip through

Humans recognise a PEM block and assume DNS should carry the same artefact. DKIM intentionally carries a flattened representation. Another pitfall is copying from HTML docs that insert soft hyphens or line breaks mid-base64. In practice it usually traces back to a missing selector or an invalid DKIM key in DNS.

What breaks downstream

  • No valid signature match, so aligned DMARC cannot use DKIM.
  • Incident teams chase content or footer edits when DNS was the broken root.
  • Regeneration churn without fixing DNS hygiene repeats failures.
  • Support escalations balloon when multiple selectors exist but none parse.

Deliverability impact

Malformed keys erase DKIM entirely. Providers leaning on DKIM-first strategies will see sudden alignment cliffs until the TXT is repaired. Providers tend to trust domains with a stable DKIM record and clean DKIM signatures far more than those with intermittent failures.

Common causes

  • Copy/paste from certificate viewers instead of signing software exports.
  • Manual stitching of split TXT strings in wrong order.
  • Accidental deletion of semicolons between tags.
  • Using sandbox keys in production selectors without updating p=.

What we checked

We locate the selector TXT at `selector._domainkey.domain` and evaluate whether the payload matches expected DKIM grammar. Structural problems surface before cryptographic strength is assessed.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

Can I use CNAME instead of TXT for the selector?

You may delegate the selector name via CNAME to a provider-managed target that still terminates in TXT. A bare CNAME without valid DKIM TXT at the end fails.

Does OpenSSL output match DKIM DNS?

Only after converting to the flattened tag form your ESP prints. Never upload PEM directly.

What about quotes inside Windows DNS?

Enter the inner text once; the UI adds quoting. Double-quoting or escaping can corrupt the record.

Next steps

  • Export the vendor’s canonical TXT line into a scratch buffer without rich text.
  • Publish exactly that value to the documented selector name.
  • Remove legacy PEM-style records from earlier experiments.
  • Send a probe and confirm d= and s= match the updated record.
  • If rotation is imminent, stage a second selector rather than hot-editing live traffic.
  • Review the full troubleshooting guidance in the DKIM Hub.
  • Explore sender authorization issues in the SPF Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues