DKIM TXT Record Formatter

The DKIM TXT Record Formatter converts DKIM public keys into properly formatted DNS TXT records that comply with the 255-character string limit. Paste a base64-encoded public key like a 2048-bit RSA key and get a correctly split, zone-file-ready record for a selector like google._domainkey.example.com.

Understanding DKIM Records

DKIM is the email authentication mechanism that proves a message has not been tampered with in transit. When your mail server sends an email, it generates a cryptographic signature over the message headers and body using a private key. The corresponding public key is published in DNS so that receiving servers can look it up and verify the signature. If the signature checks out, the receiver knows the message was genuinely sent by your domain and was not modified along the way.

The challenge with DKIM is not the cryptography -- your mail server handles that automatically. The challenge is getting the public key into DNS correctly. A 2048-bit RSA key produces a base64-encoded string of roughly 392 characters, but a single DNS TXT record string can only hold 255 characters. If you paste the key directly into most DNS provider interfaces, it either gets silently truncated (breaking DKIM verification) or the provider rejects it with a confusing error message. The key needs to be split into multiple quoted strings within a single TXT record, and the split must be done correctly for DNS resolvers to reassemble it.

This formatter handles the splitting for you. You paste your public key, specify the selector name and any optional DKIM tags, and it produces the complete DNS record in the correct format -- ready to paste into a BIND zone file or your DNS provider's web interface. It prevents the subtle formatting errors that cause DKIM validation failures, which are notoriously difficult to debug because the symptoms (emails marked as spam or rejected) do not obviously point to a DNS formatting issue.

How to Format a DKIM TXT Record

1. Paste your DKIM public key (typically a 2048-bit RSA key in base64 encoding)
2. Enter your selector name (e.g., google, s1, default)
3. Select the key type -- RSA is standard, Ed25519 is emerging
4. Configure optional DKIM tags such as testing mode (t=y) or service type (s=email)
5. The formatter splits the key into 255-character quoted strings with proper syntax
6. Copy the formatted record for your DNS zone file or provider interface

DKIM Record Format Examples

Short Key (1024-bit RSA) -- Single String

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK49aE..."

Long Key (2048-bit RSA) -- Multi-String Required

selector._domainkey.example.com. IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI"
    "k5LDXFMxqsmSZMTpNEm0MKhDlMlSGbNyERxMnpPQKHlkNPPsFKdXJQsaJFcFP1ab"
    "jCNRQaSwrztEOLGhSV1YlfS0MkIm8v5LqlkFRm0+3kOpE+RSI0E/9IMERJ3v5ggJ"
    "QIDAQAB"
)

BIND Zone File Format

google._domainkey IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...base64data..."
    "QIDAQAB" )

DKIM Record Tags Reference

When to Use the DKIM Formatter

• Setting up DKIM signing for a new domain and need to publish the public key in DNS
• Rotating DKIM keys from 1024-bit to 2048-bit RSA for improved security
• Adding new selectors for different email streams (marketing, transactional, corporate)
• Migrating DNS providers and need to re-enter DKIM records in a different interface format
• Troubleshooting DKIM failures caused by improper TXT record formatting or truncation
• Deploying multiple signing keys when different services (Google, SendGrid, Postmark) each require their own selector

How DKIM DNS Records Work

Selector and Domain Structure

DKIM public keys are published at a specific DNS location following the pattern:

<selector>._domainkey.<domain>

For example, if your selector is google and your domain is example.com, the record lives at google._domainkey.example.com. The selector allows multiple DKIM keys per domain -- one for each signing source.

The 255-Character String Limit

DNS TXT records store data in individual strings of up to 255 characters. A 2048-bit RSA public key in base64 encoding is approximately 392 characters for the key data alone, plus the DKIM tags. The total record easily exceeds 255 characters, requiring the value to be split across multiple quoted strings.

DNS resolvers automatically concatenate multiple strings in a TXT record into a single value. The split points can occur anywhere in the data -- even mid-word -- because the concatenation is byte-level, not semantic.

Key Size Considerations

2048-bit RSA is the current industry standard. Keys shorter than 1024 bits are considered insecure and may be rejected by receivers. Ed25519 keys are much shorter but not yet universally supported.

DKIM Key Management in Practice

The most common DKIM deployment mistake is publishing the key incorrectly and not verifying it. After you add the TXT record to DNS, always confirm it by querying the record with a tool like dig or nslookup and comparing the returned value against the original public key. DNS propagation can take minutes to hours depending on your TTL settings, so wait appropriately before testing. A quick way to check is dig TXT selector._domainkey.example.com and verifying the full base64 key appears in the response without truncation.

Key rotation is another area where administrators often stumble. Best practice is to generate a new key pair with a new selector, publish the new public key in DNS, wait for propagation, switch your mail server to sign with the new private key, and only then remove the old public key from DNS. If you remove the old key before all in-flight messages have been delivered and verified, those messages will fail DKIM checks. A good approach is to keep the old key published for at least a week after switching selectors, giving cached messages time to be delivered.

When setting up DKIM for the first time, use the t=y testing flag initially. This tells receiving servers that your domain is in DKIM testing mode and that they should not take action on verification failures. Once you have confirmed that signing is working correctly by checking DMARC aggregate reports, remove the t=y flag to enable full enforcement. Leaving t=y in place permanently undermines the security value of DKIM, as receivers will ignore failures.

Frequently Asked Questions

Why is my DKIM record failing validation after I paste it into DNS?

The most common cause is improper string splitting. If your DNS provider does not support multi-string TXT records or truncates long values, the public key data is incomplete and DKIM verification will fail. Use this formatter to ensure correct splitting, then verify the published record matches the expected value using dig TXT selector._domainkey.yourdomain.com.

Can I have multiple DKIM records for one domain?

Yes. Unlike SPF, DKIM supports multiple keys through different selectors. Each email system (Google Workspace, SendGrid, Mailchimp) uses its own selector, so their keys do not conflict. For example, google._domainkey.example.com and sendgrid._domainkey.example.com coexist without issues.

What does t=y (testing mode) do?

When t=y is set, receiving mail servers should treat DKIM verification failures as if the domain is not signed. This allows you to publish a DKIM key and start signing emails without risk of delivery failures while you verify the configuration is correct. Remove t=y once testing is complete to enable full DKIM enforcement.

Should I use 2048-bit or 4096-bit RSA keys?

2048-bit RSA is the current standard and is accepted by all major email providers. While 4096-bit keys provide stronger security, they produce very long TXT records that some DNS providers have trouble handling, and they increase the size of DKIM signature headers in every email. The security improvement over 2048-bit is marginal for email authentication purposes. Use 2048-bit unless your security policy specifically requires longer keys.

What is Ed25519 and should I use it?

Ed25519 is an elliptic curve algorithm that produces much shorter keys (~44 characters) and signatures than RSA, making DNS records and email headers smaller. However, Ed25519 DKIM support is not yet universal among receiving mail servers. If you adopt Ed25519, publish both an Ed25519 key and a 2048-bit RSA key under different selectors, and sign with both. Receivers that support Ed25519 will use it; others will fall back to RSA.

Related Tools

• SPF Record Builder - Build SPF records with proper syntax
• DMARC Record Builder - Build DMARC records with all policy tags
• SPF Record Length Checker - Check SPF record length and lookup limits
• DNS Record Set Deduper - Find and remove duplicate DNS records
• Zone File Linter - Check zone files for syntax errors and duplicates