Dkim Record Generator
Email Authentication Suite

DNS DKIM TXT Record Builder & Selector Helper

Generate RFC 6376 compliant DNS DKIM TXT records with selector, public key formatting (v=DKIM1; k=rsa; p=...), and verification guidance.

100% Client-Side Privacy
RFC 1035 255-Byte Safe
Presets:
DNS Hostname:google._domainkey.example.com
RSA 1024-bit (Legacy / Deprecated)
Advanced RFC 6376 Parameters
Record Type
TXT
Host / Name
google._domainkey
TTL (Time to Live)
3600 seconds
TXT Record Value (Full Unchunked):352 characters
v=DKIM1; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Q2kZ4+jX6s1aL9mB/8uI7fUvX1Q2W3E4R5T6Y7U8I9O0P1A2S3D4F5G6H7J8K9L0M1N2O3P4Q5R6S7T8U9V0W1X2Y3Z4a5b6c7d8e9f0g1h2i3j4k5l6m7n8o9p0q1r2s3t4u5v6w7x8y9z0A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0U1V2W3X4Y5Z6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1p2q3r4s5t6u7v8w9x0y1z2A3B4C5D6E7F8G9H0I1J2K3L4M5N6O7P8QIDAQAB
RFC 6376 Tag Breakdown
TagValue
v=DKIM1
k=rsa
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
s=email
Selector FQDN
google._domainkey.example.com
Query destination for mail relays
Key Algorithm & Bits
RSA 1024-bit
RSA 1024-bit (Legacy / Deprecated)
RFC 6376 Compliance
Valid & Verified
2 strings chunked (<255B)

Zero-Knowledge Local Execution

All data processing, parsing, and compilation execute strictly inside your local browser memory. Zero external server uploads.

Sub-Millisecond AST Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technical Reference & Architecture Guide

DNS DKIM TXT Record Builder & Selector Helper — Reference Guide

Generate RFC 6376 compliant DNS DKIM TXT records with selector, public key formatting (v=DKIM1; k=rsa; p=...), 255-character chunking, and validation guidance.

Key Parameters & Controls

Selector (s)String (Alphanumeric/Hyphen)

The DKIM selector subdomain prefix defining the DNS record host at <selector>._domainkey.<domain>. Enables multiple independent signing keys for key rotation and third-party mailers.

Default: default
Public Key (p)Base64 String

The Base64-encoded ASN.1 DER SubjectPublicKeyInfo public key payload. Must exclude PEM header/footer lines and all newline whitespace. Setting p= to empty explicitly revokes the selector.

Default: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Key Algorithm (k)Enum (rsa | ed25519)

The asymmetric cryptographic algorithm used by the signer. 'rsa' is universally supported across global MTAs; 'ed25519' (RFC 8463) provides compact keys and high efficiency.

Default: rsa
Key Flags (t)Flags (y | s | y:s | None)

Operational control flags. 'y' flags the domain as operating in testing mode (verifiers should not reject failing messages); 's' restricts the signature strictly to the parent domain without subdomains.

Default: None
Service Type (s)Enum (* | email)

Defines the service scope permitted for this public key. 'email' restricts validation to electronic mail signing, whereas '*' permits all supported services.

Default: *

Pro Tips & Best Practices

Standard DNS protocol limits single

Standard DNS protocol limits single TXT character-strings to 255 octets. A 2048-bit RSA key Base64 string is ~392 characters. In BIND zone files, wrap the record in parentheses and split the string across double quotes: ("v=DKIM1; k=rsa; p=part1..." "part2..."). Modern cloud DNS providers (Cloudflare, Route 53) often concatenate split strings automatically.

Google

Google, Yahoo, and the M3AAWG industry consensus require at least 2048-bit RSA keys for DKIM. 1024-bit RSA keys can be factored with moderate cloud compute resources and are treated as insecure. Avoid 4096-bit keys unless strictly necessary, as oversized DNS responses can trigger UDP truncation and TCP fallbacks.

Never overwrite an active DKIM

Never overwrite an active DKIM record directly. Generate a new key pair with a timestamped selector (e.g. 2026q4), publish the DNS TXT record, verify worldwide propagation via dig, switch the outgoing MTA to sign with 2026q4, and retain the previous selector record for 7-14 days to validate messages still in transit.

If a private signing key

If a private signing key is leaked or compromised, do not simply delete the DNS record immediately (which may leave cached queries undefined). Publish an explicit revocation record 'v=DKIM1; p=' under that selector to force receiving mail servers to treat the key as revoked.

Common Gotchas & Troubleshooting

Receiving MTA logs 'dkim=fail (bad signature)' or reports key not found

Verify that your DNS host is created as <selector>._domainkey.<domain> (do not omit '._domainkey'). Ensure that PEM headers ('-----BEGIN PUBLIC KEY-----'), trailing spaces, and line breaks (\r, \n) were stripped from the p= value, as verifiers compute Base64 hashes strictly.

DNS registrar rejects TXT record with 'String too long' or syntax error

If your registrar does not automatically split TXT records over 255 bytes, split the string manually into two adjacent quoted strings within parentheses for BIND-compatible consoles, or switch the DNS host to a provider that supports automatic string chunking.

DKIM passes verification individually but DMARC reports 'dkim=fail (unaligned)'

DMARC requires identifier alignment between the domain in the d= tag of the DKIM signature and the domain in the visible 'From:' header. If using third-party ESPs (SendGrid, Mailgun), configure a custom DKIM domain (CNAME delegation) instead of signing with the shared provider domain.

Frequently Asked Questions

What is the primary difference between DKIM, SPF, and DMARC?▼

SPF validates whether the sender IP address is authorized to transmit email on behalf of the envelope domain (Return-Path). DKIM provides cryptographic non-repudiation by signing message headers and body content. DMARC synthesizes both mechanisms, checks domain alignment with the visible From address, and specifies receiver enforcement policies (none, quarantine, reject).

Why is a DKIM selector required instead of a single root domain record?▼

A selector creates an isolated subdomain namespace (_domainkey) that allows a single domain to maintain multiple independent public keys simultaneously. This enables seamless key rotation schedules, distinct keys for different physical offices, and delegated signing for third-party SaaS services without sharing private keys.

How do I correctly split a 2048-bit RSA public key in a DNS TXT record?▼

Under RFC 1035 section 3.3.14, individual TXT string segments cannot exceed 255 bytes. To publish a 2048-bit RSA key (~392 base64 characters), split the value across two concatenated strings: ("v=DKIM1; k=rsa; p=FIRST_200_BYTES..." "REMAINING_BYTES..."). Resolvers automatically concatenate the byte array into a single continuous payload without added whitespace.

Can I use Ed25519 (RFC 8463) instead of RSA for DKIM signing?▼

Yes, RFC 8463 defines DKIM signatures using the Ed25519 elliptic curve algorithm. Ed25519 public keys are only 44 characters long in Base64 and easily fit in a single 255-byte DNS string. However, because older corporate mail transfer agents do not support Ed25519, standard practice is to deploy 2048-bit RSA or perform dual-signing (both RSA and Ed25519).

How can I verify that my DKIM DNS TXT record has propagated correctly?▼

Query your authoritative nameservers via command line using 'dig TXT <selector>._domainkey.<yourdomain.com> +short' or 'nslookup -type=TXT <selector>._domainkey.<yourdomain.com>'. Additionally, send a signed test message to an external mailbox like Gmail and inspect the 'Authentication-Results' header for 'dkim=pass'.

Related Tools & Utilities

All Tools →