DKIM (DomainKeys Identified Mail) is a crucial email authentication method that uses cryptographic signatures to verify the sender's identity and ensure message integrity. A common issue arises when DNS providers impose character limits on TXT records, which are used to publish DKIM public keys. While the DNS protocol itself allows for longer TXT records by concatenating multiple strings within a single record, many older or less sophisticated DNS management interfaces (such as those that are CGI or ASPX based) fail to properly support this, leading to truncated or invalid DKIM keys. This can result in authentication failures and impact email deliverability.
Key findings
DNS protocol limit: The DNS protocol specifies a maximum string length of 255 characters for a single TXT record string. However, a single TXT record can contain multiple such strings, which are then concatenated by the DNS resolver, allowing for longer total values (often up to around 510 characters for a 2048-bit key).
Provider limitations: Many DNS providers, particularly those with older or basic web interfaces, impose their own lower character limits (e.g., 133 characters) for TXT record input fields, preventing the full DKIM key from being entered. For more information on related issues, see our article on why your SPF record might be too long.
Incorrect solutions: Some DNS provider support teams may incorrectly advise splitting a single DKIM key across multiple, separate TXT records, which will invalidate the DKIM signature. The correct approach is to split the key into multiple strings within a single TXT record.
Impact on deliverability: An improperly configured or truncated DKIM record leads to authentication failures, which can cause emails to be soft-bounced, rejected, or sent to spam folders by recipient mail servers. This is particularly problematic for emails originating from the same domain.
Key considerations
DNS management interface: Assess the capabilities of your DNS provider's interface. If it has strict, arbitrary character limits, it may not be suitable for modern email authentication standards. As Amazon Web Services documentation suggests, split your TXT record strings over 255 characters into multiple strings within the same record.
Migrate DNS: If your current DNS provider cannot properly handle DKIM records, consider migrating to a more robust and compliant DNS hosting service. There are many reliable (and often free) options available.
Understand DNS resolution: Familiarize yourself with how DNS resolvers concatenate multiple strings in a single TXT record. This is key to properly publishing long DKIM keys.
Troubleshoot bounce messages: A missing or improperly configured DKIM TXT record can lead to various bounce codes. Investigate DNS lookup failure errors, especially if they are originating from your own domain or related to Microsoft 365 Exchange.
Email marketers and technical managers frequently encounter challenges with DKIM key length limits imposed by DNS providers. These limitations often stem from outdated or restrictive DNS management interfaces rather than fundamental DNS protocol constraints. The consensus among marketers is that such issues are frustrating and necessitate workarounds or, ideally, a migration to a more capable DNS service. Understanding the true nature of TXT record concatenation is crucial to overcoming these hurdles.
Key opinions
UI limitations are common: Many marketers report encountering DNS providers whose web interfaces arbitrarily limit the length of TXT record inputs, even though the underlying DNS system supports longer records.
Incorrect advice from support: Some support teams suggest incorrect methods like creating duplicate TXT entries, which fundamentally breaks DKIM authentication.
Need for proper DNS: There's a strong call for using competent DNS providers who offer proper interfaces for managing records, even if it means moving away from a primary registrar's basic offering.
Client-side workarounds: Some users suggest that certain character limits might only be enforced client-side, making it possible to bypass them with advanced browser developer tools.
Key considerations
Evaluate DNS provider capabilities: Prioritize DNS providers that explicitly support longer TXT records by allowing multiple strings within a single record, or those known for their robust DNS management tools. This is key to avoiding invalid RSA public key errors in DKIM.
Educate clients: When advising clients, explain the distinction between concatenating strings within a single TXT record and creating multiple, separate TXT records. Emphasize the importance of correct DKIM configuration for email deliverability.
Consider managed DNS services: For clients with less technical savvy or restrictive current providers, recommend using dedicated managed DNS services (like Cloudflare) that offer better flexibility and support for advanced records like DKIM.
Troubleshoot DNS lookup failures: If you encounter errors like 'unable to route: dns lookup failure', investigate potential issues with local DNS resolvers or accidental domain entries in internal DNS systems.
Marketer view
Marketer from Email Geeks suggests that their customer faced a DKIM barrier where their domain portal trimmed the key to 133 characters, despite the value being 228 characters and expecting space for 255. This limitation prevented the full DKIM key from being entered, causing authentication issues.
25 May 2021 - Email Geeks
Marketer view
Marketer from Email Geeks notes that their DNS provider's support (BT) advised splitting the DKIM key into duplicate TXT entries using their portal. However, this approach resulted in incorrect dig outputs and confusion for dkimcore, indicating that duplicate entries lead to invalid DKIM keys.
25 May 2021 - Email Geeks
What the experts say
Industry experts concur that DNS provider limitations on TXT record length are a common, yet solvable, issue for DKIM key implementation. These limitations are typically due to inadequate web interfaces rather than inherent DNS protocol restrictions. Experts emphasize the importance of understanding how DNS concatenates strings within a single TXT record and advise migrating to more capable DNS services when faced with such constraints. They also highlight the need to correctly diagnose bounce messages, differentiating between DNS configuration issues and other potential problems like Exchange server misconfigurations.
Key opinions
UI problems, not protocol limits: Experts stress that while DNS TXT records have a per-string limit of 255 characters, the protocol allows for concatenation of multiple strings within a single record to accommodate longer keys. The issue is usually with DNS provider UIs that don't support this properly.
Invalid configurations: Creating multiple separate TXT records for a single DKIM key will lead to an invalid DKIM key and non-signing emails.
DNS provider competence: It is a wise and cost-effective investment to use a DNS provider that is competent in DNS management, ensuring system stability and proper record handling.
Diagnosing bounce errors: Errors like '4.4.4 (unable to route: dns lookup failure)' often point to an Exchange server's inability to resolve a domain, rather than a direct block. This can be exacerbated by incorrect DNS configurations like duplicate DKIM entries.
Key considerations
Seamless migration: Advise clients to migrate to a DNS provider that offers a proper interface and supports the full range of DNS capabilities required for email authentication. Services like Cloudflare, for instance, can manage DNS records even if the primary service remains with another provider.
Understanding resolvers: Explain that DNS resolvers are the servers used by email systems (like Exchange) to perform domain lookups. Issues with these resolvers can lead to delivery failures that may be misattributed to other problems. For more context, read our article A simple guide to DMARC, SPF, and DKIM.
Client education: It's important to educate less tech-savvy clients on the benefits of proper DNS management and the risks of sticking with outdated systems, even if they fear disruption.
Advanced troubleshooting: When diagnosing issues, consider less obvious causes, such as local Active Directory (AD) DNS configurations conflicting with external DNS records, particularly in hybrid environments.
Expert view
Expert from Email Geeks indicates that they frequently encounter DNS providers who are not truly competent DNS specialists, leading them to provide inaccurate or misleading information about DNS configurations. This highlights a common challenge in email deliverability.
25 May 2021 - Email Geeks
Expert view
Expert from Email Geeks clarifies that using duplicate TXT entries for a single DKIM key will inevitably lead to an invalid DKIM key and, consequently, no valid DKIM signatures on outbound emails. This is a critical point for proper authentication.
25 May 2021 - Email Geeks
What the documentation says
Official documentation and technical guides consistently confirm that the DNS protocol allows for long TXT records by breaking them into multiple strings within a single record, which are then concatenated by the resolver. The common problem of character limits is typically an arbitrary restriction imposed by DNS management interfaces, not a fundamental protocol limitation. Therefore, overcoming these issues requires either a compliant DNS provider or careful manual splitting and concatenation of the DKIM key string.
Key findings
DNS TXT record structure: A TXT record value can contain multiple string literals (sequences of characters enclosed in quotation marks). DNS resolvers are designed to concatenate these strings into a single, longer value.
255-character string limit: While each individual string literal within a TXT record is limited to 255 characters, the overall record's length can exceed this by using multiple concatenated strings.
Provider-specific errors: Errors like 'CharacterStringTooLong' typically arise from DNS providers' interfaces or underlying systems that do not properly support the concatenation of multiple strings for TXT records.
DKIM key size: Modern DKIM keys, especially 2048-bit RSA keys, often exceed the 255-character single string limit, necessitating the use of multiple concatenated strings in the TXT record.
Key considerations
Splitting DKIM records: When your DKIM key is longer than 255 characters, it must be split into multiple 255-character (or less) strings, enclosed in separate quotation marks, within the same TXT record entry. This is the recommended practice by cPanel support documentation.
DNS provider compliance: Ensure your DNS provider's interface allows you to input TXT records with multiple quoted strings. If not, consider moving to a more compliant provider.
Selector usage: Remember that DKIM selectors are used to identify the specific public key in DNS. If splitting is necessary, ensure the record is still associated with the correct selector.
Validation tools: Always use DKIM validation tools after publishing or modifying your record to ensure it is correctly parsed and active, helping to avoid issues such as DKIM record not found errors.
Technical article
Documentation from Server Fault explains that the 255-character limit per string on TXT records is not a limitation imposed by specific DNS providers like Route 53, but rather a fundamental constraint of the DNS protocol itself. This means that any long TXT record must be split into multiple string literals.
15 Mar 2016 - Server Fault
Technical article
Documentation from AWS Knowledge Center advises that DNS DKIM TXT records can contain up to 255 characters in a single string. To resolve the 'CharacterStringTooLong' error, it is necessary to split TXT record strings that exceed 255 characters into multiple text strings within the same record.