DKIM DNS Record Example: Keys and Selectors

Do not index

A DKIM DNS record example only helps if the selector and domain line up exactly. When the record lives at the wrong hostname, the message can still be signed, but receivers can't fetch the public key, so authentication fails and inbox placement takes the hit.

Table of Contents

Why a DKIM DNS Record Example Matters for Deliverability The Anatomy of a DKIM TXT Record How the header maps to DNS Real DKIM DNS Record Examples by Provider Key Lengths, Record Sizes, and RSA vs Ed25519 Where Ed25519 fits How to Look Up a DKIM Record and Read the Header What the header should tell you Selector Strategy and Key Rotation in Practice Common Mistakes That Break DKIM Verification The mistakes that show up most often Putting DKIM Together With SPF and DMARC

Why a DKIM DNS Record Example Matters for Deliverability

A broken DKIM publish often shows up as a sudden spam placement problem after a system change, like a new ESP rollout or a domain migration. The signing side can look healthy while Gmail or Microsoft can't resolve the selector-based TXT lookup under <selector>._domainkey.<domain>, which is the core DNS mechanic in RFC 6376 RFC 6376.

That lookup pattern matters because the signer's domain is carried in d= and the selector in s=. If a message is signed as d=example.com with s=foo.bar, the verifier queries foo.bar._domainkey.example.com in DNS, not the apex domain RFC 6376. A DKIM DNS record example that misses that hostname still looks “published” in the admin console, but receivers can't use it to verify the message.

For a broader security context, a useful companion resource is F1Group's email security guide, especially if the issue extends beyond DKIM into broader authentication and domain hygiene. The deliverability takeaway is simple, a record that can't be queried is no better than no record at all.

The Anatomy of a DKIM TXT Record

A DKIM TXT record has one job, publish the public key where verifiers expect it. The common shape is selector._domainkey.domain, and the value normally contains v=DKIM1 plus the key material in p= RFC 6376, Palisade DKIM record format.

A minimal record often looks like this.

Example record value

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

The important parts are straightforward. v=DKIM1 declares the version, k=rsa indicates the key type in the common RSA form, and p= carries the Base64 public key without the private key and without the PEM header or footer Palisade DKIM record format. An empty p= revokes that selector's key, so a record can exist and still be useless for verification Palisade DKIM record format.

How the header maps to DNS

The verifier reads the DKIM-Signature header, extracts d= and s=, then looks up the matching DNS owner name. The DNS record does not store the signature itself, it stores the public key that verifies the signature created with the private key dmarcguard.io DKIM guide.

A clean operational habit is to treat the header and the DNS record as one pair. If d= and s= point at the wrong place, the key can't be found, and the message fails even if everything else about the email is correct.

Real DKIM DNS Record Examples by Provider

Different providers expose DKIM in different shapes, and that's where a lot of production confusion starts. The record may be a raw TXT entry under the selector, or a CNAME that points to a provider-controlled target where the actual TXT lives Cloudflare DKIM record guide.

Google Workspace generally uses a selector-based hostname with a TXT public key published under the domain's DKIM selector, while Microsoft 365 commonly relies on selector1 and selector2 with CNAME indirection to Microsoft-hosted DNS targets. Transactional senders often use the same indirection model, because it lets the provider rotate the underlying key without asking customers to edit DNS every time RFC 6376, Cloudflare DKIM record guide.

Provider	Selector Hostname	Record Type	Typical Key Length
Google Workspace	selector-based hostname under the sending domain	TXT	RSA key published through the provider workflow
Microsoft 365	selector-specific hostname with provider delegation	CNAME, then TXT at the target	Provider-managed RSA key
Transactional ESPs	customer selector pointing to provider target	CNAME, then TXT at the target	Provider-managed RSA key

The practical trade-off is clear. Raw TXT gives direct control, but it can be awkward during rotations. CNAME delegation reduces customer-side change management, but it also means you have to understand where the actual key is hosted and whether your DNS provider tolerates that model Cloudflare DKIM record guide.

Cloudflare-style multi-string handling and some DNS console behaviors can hide mistakes, while host fields in other panels may auto-append the zone name. That's why the literal record line in the UI isn't enough, the published owner name still has to match the selector the signer uses.

Key Lengths, Record Sizes, and RSA vs Ed25519

Key length affects both security posture and DNS usability. For RSA DKIM keys, public guidance derived from RFC 8301 says signers must use at least 1024-bit keys and recommend 2048-bit keys for stronger security RevenueFlow DKIM record guide.

That stronger key can create practical DNS friction. A larger RSA public key often needs multiple quoted TXT strings because DNS TXT data is constrained by string formatting limits, while shorter keys fit more comfortably in one record RevenueFlow DKIM record guide. A 1024-bit key is easier to publish, but it's the weaker operational choice, and many teams have moved away from it for that reason.

Example of a multi-string RSA TXT record

v=DKIM1; k=rsa; p="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "AQAB..."

The exact chunking depends on the DNS host, but the key point doesn't change. If the UI mangles the strings, verification fails even though the text looks intact to the human editor RevenueFlow DKIM record guide.

Where Ed25519 fits

Ed25519 is attractive because the public key is much shorter, so it fits better in DNS TXT formatting and reduces record bloat RevenueFlow DKIM record guide. Support is growing, but RSA remains the safer compatibility baseline for many sending environments, so a parallel selector strategy is often the cleanest operational path.

Key Type	Public Key Size	TXT Record Fit	RFC 8301 Status	Provider Support
1024-bit RSA	Smaller Base64 payload	Usually fits easily	Minimum acceptable, weaker choice	Broad legacy acceptance
2048-bit RSA	Larger Base64 payload	Often needs multiple strings	Recommended	Broad support
Ed25519	Much shorter key material	Usually fits in one string	Different algorithm path	Growing, but not universal

A DKIM DNS record example should be chosen for both cryptography and operations. If the DNS platform can't publish the key cleanly, the stronger algorithm won't matter because the message still won't verify.

How to Look Up a DKIM Record and Read the Header

A lookup starts with the selector hostname, not the email body. The receiver does the same thing, it extracts the selector and domain from DKIM-Signature, queries DNS for the matching TXT record, and compares the signature against the computed hashes dmarcguard.io DKIM guide.

A terminal check is usually the fastest sanity test. Use a DNS query for the selector hostname and confirm the TXT value is visible outside your network. The same logic applies whether you use a shell, a Windows lookup, or a web-based DNS diagnostic.

What the header should tell you

The d= tag should match the signing domain, and s= should match the selector you queried. bh= is the body hash, and b= is the actual signature data dmarcguard.io DKIM guide. If the selector in the header doesn't line up with the DNS name, the problem is usually not the signature itself, it's the published record.

The fastest way to avoid chasing ghosts is to compare three things side by side.

Published owner name: the selector-based hostname in DNS.

Header selector and domain: the values in s= and d=.

Authentication result: the receiver's DKIM pass or fail status.

For a quick validation workflow, the dkim checker is a practical first pass before deeper header analysis. If the selector can't be resolved there, the mail won't authenticate cleanly in production either.

Selector Strategy and Key Rotation in Practice

A single static selector is a maintenance liability. The safer pattern is to keep multiple selectors alive so one key can be published while another is in active use, which makes key rotation possible without a signing outage RFC 6376.

A selector naming scheme should tell you who owns the key and when it entered service. Labels like g2024, ses2024, or msft2024 are easier to audit later than vague names that only make sense to the person who created them. The selector itself is a DNS label, so it has to stay within the DKIM selector constraints in the specification dkimcore.org specification.

A practical rotation sequence looks like this.

Publish the new selector. The record should be live before any sender starts using it.

Switch signers. Move outbound signing to the new key while keeping the old record visible.

Verify old traffic drains. Watch for messages still carrying the retired selector.

Remove the old record. Delete it only after it's no longer needed for verification.

That sequence matters because DKIM verification is a DNS lookup plus signature check, not a local setting dmarcguard.io DKIM guide. If the old selector disappears too early, messages already in transit can fail verification even though they were signed correctly when they left.

Common Mistakes That Break DKIM Verification

The failures that hurt most are the ones that look fine in the DNS console. A selector can be present, the value can look complete, and the message can still fail because the wrong hostname was published or the key material was left blank.

The mistakes that show up most often

Blank public key: an empty p= revokes the selector, so the record exists but no key can be trusted Palisade DKIM record format.

Wrong owner name: publishing at the apex or at _domainkey.example.com instead of selector._domainkey.example.com breaks the lookup path RFC 6376.

Selector mismatch: the s= value in the header must match the selector in DNS, or the verifier queries the wrong key dmarcguard.io DKIM guide.

Whitespace and line breaks inside quoted Base64 often survive resolvers, but DNS management UIs can still split or rewrite long values in ways that break parsing. That's why checking the zone file view isn't enough, the external lookup matters more than what the editor displays.

The more dangerous problem is duplicated or stale selector data. If an old TXT record lingers while the new one is live, troubleshooting becomes noisy and failures look intermittent. A short post-change checklist catches most of it before inbox placement suffers.

Confirm the owner name: verify the selector label is attached to the domain correctly.

Check the key body: make sure p= isn't blank or truncated.

Match the header: compare the live selector with s= in the signed message.

Re-query from outside: validate the public DNS view, not the local admin UI.

Putting DKIM Together With SPF and DMARC

DKIM is one leg of the authentication stack, not the whole stool. SPF authorizes the sending server, DKIM proves cryptographic identity for the signed domain, and DMARC ties those signals to the visible From domain and policy RFC 6376.

That means a DKIM pass alone isn't always enough. If the From domain doesn't align with d=, DMARC can still fail even though the signature verifies, which is exactly what DMARC is designed to catch. In production, that distinction matters because mailbox providers don't treat every authentication pass as equally meaningful.

The clean sequence is simple. The receiver reads s= and d=, fetches the public key from selector._domainkey.d, validates the signature, and then checks whether the authenticated domain aligns with the visible From domain dmarcguard.io DKIM guide.

For teams that want a more structured walkthrough of the whole stack, SPF, DKIM and DMARC explained is the natural companion reading. MailAdept also offers a subscription-based deliverability consulting service that can audit the DNS layer, inspect the signing flow, and tie the authentication setup back to mailbox behavior.

Still facing deliverability issues? Get a free deliverability audit. Mailadept helps teams clean up SPF, DKIM, and DMARC alignment, then trace the DNS and header details that keep messages out of spam. If the selector is published but mail still fails verification, the problem is usually somewhere in the handoff between signing, DNS, and provider-specific formatting, and that's exactly the kind of issue a deliverability review should catch.