CharacterStringTooLong when trying to import v1-rsa domain key via route53 autodns

Issue Description

When trying to perform autoDNS to route53 I get a CharacterStringTooLong error for the v1-rsa domain key record.
It works for the rest of the DNS records which is good

Expected Behavior

A successful import of the record should happen

Actual Behavior

FATAL problem: CharacterStringTooLong (Value is too long) encountered

Stalwart Version

v0.15.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

The CharacterStringTooLong error comes from a DNS protocol limitation, not from Stalwart itself. Looking at the code, when Stalwart generates the DKIM TXT record for RSA keys it builds a single-string TXT record (v=DKIM1; k=rsa; h=sha256; p=<PUBLIC_KEY>). The DNS protocol limits each character-string within a TXT record to 255 bytes, and a 2048-bit RSA public key encoded in base64 is ~400 characters - well over that limit. The proper solution is to split the TXT content into multiple 255-byte quoted strings, which well-behaved DNS providers handle automatically (and Route 53 requires).

Looking at crates/common/src/network/dkim.rs, Stalwart passes the entire value as a single DnsRecord::TXT(record) string. Whether Route 53 splits it into 255-byte chunks is the responsibility of the dns_update crate’s Route 53 provider - and it appears it is not doing so, which causes Route 53 to reject it with CharacterStringTooLong.

The CharacterStringTooLong error comes from the underlying dns_update library that Stalwart uses to communicate with Route53, not from Stalwart’s own code. Let me check if there’s any known handling or issue in the dns_update dependency.

The CharacterStringTooLong error is coming from the dns-update library (an external crate), not from Stalwart itself. This is a well-known DNS constraint: individual TXT record strings are limited to 255 bytes per RFC 1035, but RSA 2048-bit DKIM public keys produce a base64-encoded value that exceeds this limit. Stalwart currently passes the RSA DKIM TXT record as a single unbroken string (v=DKIM1; k=rsa; h=sha256; p=<very_long_key>), and the Route 53 provider in the dns-update library rejects it because one of the character-strings exceeds 255 bytes.

What is happening: When Stalwart auto-generates the DKIM TXT record in generate_dkim_dns_record(), the full RSA 2048-bit public key is put into a single TXT string. Route 53 (via the dns-update crate) enforces the 255-byte character-string limit and returns CharacterStringTooLong. Ed25519 keys are much shorter and don’t hit this limit, which is why your other records succeed.

What you can do right now:

  1. Add the DKIM record manually. In Route 53, create the TXT record yourself, splitting the p= value into quoted 255-byte chunks. For example:
    "v=DKIM1; k=rsa; h=sha256; p=<first 200 chars of key>" "<next chunk>" "<etc>"
    
  2. Use Ed25519 instead of RSA for your DKIM key. Stalwart supports DKIM1/Ed25519-SHA256 keys, whose public keys are only ~44 base64 characters - well under the 255-byte limit - and which work fine with autodns.

The root fix (having Stalwart split the TXT value into 255-byte chunks before submitting to Route 53) would need to happen either in Stalwart’s generate_dkim_dns_record function or in the dns-update library. This appears to be a bug that a human maintainer should follow up on.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

This has been fixed and the fix will be included in v0.16.6.