Where exactly does the DKIM record go?

It's a TXT record at ` ._domainkey. `. The selector is a label your mail provider gives you — something like `google`, `s1`, or `k1`. So if your provider's selector is `s1` and your domain is `example.com`, the record name is `s1._domainkey.example.com`. Get the selector wrong and receivers look up a name that doesn't exist, which reads as a missing key, not a broken one.

My 2048-bit DKIM key is too long for one TXT record. What do I do?

A 2048-bit public key runs past the 255-character limit on a single DNS TXT string, so you split the value into multiple quoted chunks — but inside ONE record, not two. `"chunk1" "chunk2"` in the same TXT value; the resolver concatenates them back into one key. The mistake that silently breaks DKIM is creating two separate TXT records for the same selector. A receiver then sees two keys and can't tell which one signed the mail.

The record is published but DKIM still fails. What's the usual reason?

Three common ones. The selector in your published record doesn't match the `s=` tag in the actual DKIM-Signature header your mail carries. The record still has `t=y` (testing mode) left over from an onboarding wizard, so receivers treat failures leniently and some ignore the signature entirely. Or the key was rotated on the sending side but the old public key is still in DNS. Compare the published key against what your provider currently shows in its admin console.

Views: 11

DKIM Record Setup and Check (DNS TXT)

DKIM record setup and check: publish the selector._domainkey TXT, avoid the two-record split trap, and confirm the key resolves. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

What DKIM actually is

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to every message you send. Your mail server holds a private key and signs outgoing mail; you publish the matching public key in DNS. A receiving server pulls that public key, checks the signature, and confirms the message really came from your domain and wasn’t tampered with in transit.

The private key stays on the sending side and never leaves it. The only thing that goes into DNS is the public half. If a setup guide ever tells you to paste a private key into a DNS record, stop — that’s a different, very bad thing.

Where the record lives

DKIM uses one specific TXT record location:

<selector>._domainkey.<yourdomain>

The selector is a label chosen by whoever signs your mail — Google Workspace uses google, Microsoft 365 uses selector1 and selector2, and bulk senders often use short ones like s1 or k1. It exists so one domain can publish several keys at once: a separate key per sending service, and a fresh key for rotation without breaking the old one. Your provider tells you both the selector and the record value to publish.

What goes in the value

The record is a semicolon-separated tag list. A minimal one looks like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

v=DKIM1 — the version. When present it must come first.
k= — key type. Defaults to rsa; ed25519 is defined in RFC 8463 and produces a much shorter record, though not every receiver checks it yet.
p= — the base64 public key. This is the required part. An empty p= (p=) is not a bug; it’s how you revoke a key.

Two optional tags cause most of the “why won’t this work” support tickets: t=y marks the key as being in testing, and t=s locks the key to the exact signing domain. More on t=y below.

The three mistakes that quietly break it

Splitting a 2048-bit key into two records instead of one. A 2048-bit public key is roughly 392 characters, and the full record lands near 420 — well past the 255-character limit for a single DNS TXT string. The correct fix is to break the value into multiple quoted chunks inside one record: "first255chars" "therest". The resolver stitches them back together. Creating two separate TXT records for the same selector is the classic silent failure: a receiver now sees two candidate keys for one name and can’t decide which signed the mail, so verification fails even though every character you pasted is correct.
Leaving t=y on after go-live. Onboarding wizards often publish the key in testing mode. A record with t=y is a rehearsal, not a working control — receivers are told to treat signature failures as insignificant, and some skip the check entirely. Once you’ve confirmed real mail is signing, remove t=y.
Selector mismatch. The s= tag inside the DKIM-Signature: header of your actual mail has to match the selector you published in DNS. If your server signs with s1 but you published s2._domainkey, receivers look up the wrong name, find nothing, and treat it as an unsigned message.

Check it with DechoNet

Email Auth Check resolves your domain’s SPF, DKIM, and DMARC together, so you can see whether the DKIM key actually publishes and parses — not just whether a TXT record exists.
DNS Lookup queries the exact <selector>._domainkey.<domain> name directly. Use it to confirm the record resolves to a single, complete key and that a 2048-bit value didn’t get truncated or split into two records.

Setup checklist

Get the selector and the public key value from your mail provider’s admin console — never generate your own key for a hosted service.
Create one TXT record named <selector>._domainkey.<yourdomain> with the provider’s value.
If the key is 2048-bit and your DNS host complains about length, split the value into multiple quoted strings in the same record, not into two records.
Resolve the record with DNS Lookup and confirm it comes back as one complete key with no missing tail.
Send a test message to an address you control and confirm the DKIM-Signature header’s s= selector matches what you published.
Once real mail verifies, remove any t=y testing flag.
Only then tighten DMARC — DKIM has to align (the signing d= domain matching your From domain) before a p=reject policy is safe.

When it’s not the record

If the published key is correct, complete, and matches the signing selector but mail still fails DKIM, the problem is on the sending side, not in DNS: the server may not be signing at all, may be signing with a rotated key whose public half you haven’t published yet, or may be modifying the message after signing (a mailing list or forwarder rewriting the body breaks the signature by design). Confirm the record is right first, then take a genuinely signed message’s headers to whoever runs the mail platform.