DKIM Key Size Calculator
Estimate RSA or Ed25519 DKIM TXT record length, DNS chunks, provider fit, selector naming, DNSSEC overhead, and rotation footprint before publishing.
Each preset uses a named onclick handler and immediately recalculates the TXT footprint.
Cloudflare
Usually supports multi-string TXT records.
Typical fit: 2048 RSA works.
Watch: pasted quotes.
Route 53
Accepts long TXT values split into strings.
Typical fit: 4096 possible.
Watch: zone file import.
Google DNS
Modern UI handles common DKIM records.
Typical fit: 2048 RSA works.
Watch: copied spaces.
cPanel DNS
Behavior depends on host version and UI.
Typical fit: 1024 or 2048.
Watch: field truncation.
Microsoft 365
Often publishes CNAME selectors instead of raw keys.
Typical fit: CNAME model.
Watch: selector pairs.
Google Workspace
Commonly uses generated 1024 or 2048 RSA keys.
Typical fit: 2048 RSA.
Watch: long domain names.
SendGrid
Uses provider supplied hostnames and values.
Typical fit: delegated records.
Watch: multiple selectors.
Amazon SES
Easy DKIM normally uses three CNAME records.
Typical fit: CNAME model.
Watch: label length.
| Key choice | Approx p tag | Common chunks | Practical note |
|---|---|---|---|
| 1024-bit RSA | 216 to 230 chars | 1 | Legacy compatible, but weaker than modern defaults. |
| 2048-bit RSA | 388 to 410 chars | 2 | Common balance for current DKIM deployments. |
| 4096-bit RSA | 728 to 760 chars | 3 to 4 | Large TXT record; verify provider and resolver behavior. |
| Ed25519 | 44 to 80 chars | 1 | Compact, but receiving support varies by ecosystem. |
| Limit | Value | Calculator check | Why it matters |
|---|---|---|---|
| DNS label length | 63 chars | Selector and each domain label | Long selectors can fail before the TXT value is evaluated. |
| Full DNS name | 253 chars | selector._domainkey.domain | Deep subdomains consume owner-name budget quickly. |
| TXT string | 255 chars | Chunk count | Long DKIM values must be split into quoted strings. |
| UDP response | Size varies | Wire bytes plus DNSSEC | Large signed answers may require EDNS0 or TCP fallback. |
| Rotation model | Active selectors | Zone footprint | Recommended use |
|---|---|---|---|
| Single live key | 1 | Lowest | Small domains with one sender and simple rollback needs. |
| Blue and green | 2 | Moderate | Most home labs, SaaS apps, and business domains. |
| Per provider | 3 to 6 | Higher | Domains using Workspace, marketing mail, and ticket systems. |
| Staged migration | 4+ | Highest | Short-term migrations where old mail may still validate. |
| Algorithm | DNS size | Compatibility | Operational guidance |
|---|---|---|---|
| rsa-sha256 1024 | Small | Very broad | Use only when a provider cannot publish 2048-bit keys. |
| rsa-sha256 2048 | Medium | Very broad | Default choice for most production DKIM records. |
| rsa-sha256 4096 | Large | Broad, but DNS-sensitive | Validate with your DNS host and external DKIM testers. |
| ed25519-sha256 | Very small | Emerging | Use as a pilot or secondary selector when receivers support it. |
Making a DKIM key is not as simple as pushing a button and pasting text into your DNS configuration. You need to understand what the key does to your domain and how the key impact that functionality. Does it mean splitting up your data? Will this be acceptable to my DNS provider? Most admins don’t know any of this, unless they is running into errors when upgrading/rotating keys.
By plugging in your preferred bit strength and domain structure into the calculator above, you’ll get the numbers needed. It eliminates any need to guess at impact of a 4096-bit key on DNS load.
How DKIM Key Size Affects Your DNS
To start with, select an algorithm (RSA or Ed25519). You start by choosing between RSA and Ed25519. For that, 2048 bits are a good compromise between a key being large enough and not being too big. The bigger 4096-bit key is more secure against cracking efforts in the distant future, but it make the public key almost twice as long. And the longer public key mean less room for those TXT record values.
Why does chunk size matter? DNS systems splits long text records into several strings. Typically, each string must be 255 characters or fewer. For example, a 1024-bit key may well fit in a single string, while an RSA key of 2048 bits will typically need two or three. The tool calculates that for you.
Smaller keys are more manageable if your DNS interface isn’t up to handling multi-string records properly. Some providers also silently truncate anything longer than a certain length, breaking authentication and leading to difficult-to-spot errors.
The other factor is selector length. That’s the first component of the DKIM record name (e.g., `default._domainkey.example.com`). By default you get to pick any length up to 63 characters. But if you go too far into your domain’s namespace with that selector, it may push past the 253-character maximum for a complete DNS name. The calculator accounts for this footprint when analyzing records. Often folks are tripped by this when they think of selectors as titles and not technical identifiers, so make ’em short.
This introduces some additional complexity: don’t just change all your keys to a different one on day X in production. For best practice, run two keys concurrently so old emails can still validate while new ones signs with the fresh key. So that briefly doubles the size of your zone file. That’s noticeable if you are doing DNSSEC because that adds its own signature overhead.
Zone load is a good measure of what this feels like. Does your DNS provider handle serving those bigger responses well? Not all providers are created equal: Modern control panels will accommodate long TXT records just fine; some older ones choke on anything greater than 1024 characters. A fit error indicates that you probably have selected an overly-large key for your panel’s UI. To fix it, select a smaller key or upload via API. The former does not greatly impact security and doesn’t require any new infrastructre.
Another alternative would of Ed25519. It’s faster to verify, and its keys is smaller than RSA keys (making the DNS overhead less). Not all services will support this yet, though. You can use it as a pilot key in addition to your primary RSA key to see how it performs without risking deliverability.
DKIM design is a compromise between security requirements and practical limits. A key must be long enough to be secure but short enough to fit into your DNS zone and rotate by running two keys simultaneous for a period. This table makes those compromises explicit. By understanding how many characters are used for each bit and what chunking means, you won’t have to guess anymore, and will confidently serve up the right records to your users.
