DKIM Record Generator & Selector Key Inspector
Free enterprise RFC 6376 DKIM TXT record generator, cryptographic public key bit-depth validator, and syntax inspector for DNS email authentication.
DKIM Key & DNS Record Parameters
PEM headers (-----BEGIN PUBLIC KEY-----) and line wraps are stripped automatically for DNS TXT compatibility.
DNS Resource Record Entry
RFC 6376 Formatdefault._domainkey.example.com
TXT
3600 (1 Hour) / Auto
Key Health & Security Diagnostics
The Cryptographic Foundation of DKIM: RFC 6376 and RFC 8301
DomainKeys Identified Mail (DKIM) provides a digital signature mechanism for email verification. When an outbound Mail Transfer Agent (MTA) dispatches an email, it calculates a cryptographic hash over selected headers (such as From, Subject, and Date) along with the message body. This hash is encrypted using the domain owner’s private key and attached to the email header as DKIM-Signature.
Selector DNS Delegation
The selector tag (s=) isolates different signing keys under one domain. A company can host Google Workspace on google._domainkey while hosting SendGrid on s1._domainkey without key collision.
Tamper-Proof Integrity
Receiving MTAs independently fetch the public key via DNS TXT lookup and decrypt the signature. If a single byte in the signed headers or message body was altered in transit, signature verification fails outright.
DMARC Alignment Anchor
Under RFC 7489, DMARC passes if the domain declared in the DKIM d= tag matches or aligns with the RFC 5322 From header, surviving message forwarding where SPF typically breaks.
DKIM TXT Record Tag Specification
| Tag | Status | Default | Functional Purpose |
|---|---|---|---|
| v=DKIM1 | Mandatory | DKIM1 | Identifies the DNS record as a DKIM public key record. |
| k= | Optional | rsa | Specifies key algorithm: rsa or ed25519 (RFC 8463). |
| p= | Mandatory | None | Base64-encoded public key data. An empty value explicitly revokes the key. |
| h= | Optional | sha1, sha256 | Colon-separated acceptable hash algorithms. SHA-1 is deprecated by RFC 8301. |
| s= | Optional | * | Permitted service types. Setting ‘s=email’ prevents other services using this key. |
| t= | Optional | None | Operational flags: ‘y’ enables testing mode, ‘s’ allows subdomain inheritance. |
Cryptographic Key Comparison: RSA 1024 vs RSA 2048 vs Ed25519
Industry security mandates from major mailbox providers require retirement of obsolete key lengths. Compare the security parameters, DNS overhead, and compatibility profiles across modern standards:
| Algorithm & Strength | Character Length | DNS Packet Size (<512 UDP) | Mailbox Provider Support | Security Assessment |
|---|---|---|---|---|
| RSA 1024-bit | ~216 chars | Fits in single 512B UDP | Legacy Support; Flagged by Google/Yahoo | Insecure; Deprecated |
| RSA 2048-bit | ~392-420 chars | Requires EDNS0 or 255-char splitting | Universal Gold Standard (100%) | Enterprise Grade |
| Ed25519 (Curve25519) | ~44 chars | Extremely compact (<100 bytes) | Modern MTAs (RFC 8463); Some legacy gaps | Future Proof |
DNS Administration: The 255-Octet String Limit and Key Rotation
Setting up enterprise 2048-bit RSA keys often triggers DNS errors due to legacy protocol limits. Understand how DNS resolvers reconstruct long TXT records and how to execute seamless key rotations:
Resolving the 255-Character DNS Limit
- • RFC 1035 Constraints: Individual strings inside a DNS TXT record cannot exceed 255 bytes. A 2048-bit public key spans ~400 characters.
- • Quoted Chunking in BIND: In BIND and raw zone files, wrap the record into two consecutive double-quoted strings within parentheses:
("v=DKIM1; ..." "...p=second_half"). - • Automatic DNS Management: Cloudflare, AWS Route 53, and Google Cloud DNS automatically fragment long TXT strings behind the scenes; paste the continuous unquoted string in their UI.
Seamless Dual-Selector Key Rotation
- • Step 1: Publish New Selector: Generate a new keypair and publish selector
selector2._domainkeyin DNS while keepingselector1active. - • Step 2: Allow DNS TTL Propagation: Wait 24 to 48 hours to guarantee global resolver synchronization across recursive caches.
- • Step 3: Switch Outbound MTA: Update your email sending server to sign outbound messages using
selector2. - • Step 4: Retire or Revoke Old Key: After 7 days of verified traffic, delete the obsolete selector record or set its public key to
p=to formally revoke it.
Frequently Asked Questions (FAQ)
What is a DKIM Selector and why is it required in DNS?
A DKIM selector is an arbitrary string assigned by an email sender that differentiates multiple public keys published under a single domain. It allows an organization to sign emails from multiple providers (e.g., Google Workspace, Zendesk, SendGrid) without key collisions, and enables periodic cryptographic key rotation without downtime.
Where should the DKIM record be published in DNS?
A DKIM record must be published as a DNS TXT or CNAME record at the subdomain location formatted as [selector]._domainkey.[yourdomain.com]. For example, if your selector is ‘google’ and your domain is ‘example.com’, the DNS host label is ‘google._domainkey.example.com’.
Why are 2048-bit RSA keys recommended over 1024-bit RSA keys?
1024-bit RSA keys can theoretically be factored using modern distributed computing clusters. Major email receivers including Google and Yahoo enforce 2048-bit RSA keys for high-volume outbound senders. Keys shorter than 1024 bits are treated as untrusted or invalid.
How does DNS handle DKIM records exceeding 255 characters?
RFC 1035 limits an individual character-string within a DNS TXT record to 255 octets. Since a 2048-bit RSA key spans over 400 characters, DNS administrators must split the record into multiple double-quoted strings within a single resource record. Resolvers concatenate these strings automatically during verification.
What is the consequence of publishing an empty public key tag (p=)?
Under RFC 6376 §3.6.1, an empty p= tag explicitly signals key revocation. Receiving mail transfer agents will treat any email signed by that specific selector as unauthenticated, failing DKIM verification.
What do the DKIM flags t=s and t=y signify?
The ‘t’ tag specifies operational flags. The ‘t=s’ flag restricts key matching to the exact domain only, prohibiting subdomains from using the parent key. The ‘t=y’ flag signals testing mode, requesting receiving MTAs to inspect the signature but avoid rejecting failing messages.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
Meta Tag Generator & Social Preview Inspector
Generate SEO-optimized HTML meta tags, Open Graph properties, and Twitter Cards with live previews for Google, Facebook, & X. 100% client-side & secure.
WHOIS Domain Age Checker & Expiration Auditor
Query live WHOIS registries to inspect domain creation dates, total active age, registrar information, expiration milestones, and trust metrics.
IP Location Lookup & GeoIP Visualizer
Inspect IPv4/IPv6 locations, ASN telemetry, ISP network data, and interactive location maps.