Stalwart hostname conflicts with an Amazon SES MAIL FROM domain

One DNS name should have one documented mail role

Mailbox domain

The domain after @ for inbound recipients. Its MX records decide which system accepts those recipients.

SMTP server hostname

The hostname used for A or AAAA, TLS, EHLO, and PTR. A direct-to-MX sender needs stable forward and reverse identity.

MAIL FROM domain

The SMTP envelope identity used for SPF and bounce handling. Amazon SES custom MAIL FROM uses an MX to feedback-smtp.REGION.amazonses.com and an SES SPF TXT record.

DKIM signing domain

The d= identity selected by Stalwart and the matching s= selector published below _domainkey.

DMARC Author Domain

The visible RFC5322 From domain. A passing SPF MAIL FROM or DKIM d= identity must align with it.

Why the SES MX is not a Stalwart mailbox route

Amazon SES requires a custom MAIL FROM subdomain to publish an MX whose target begins with feedback-smtp and an SPF TXT value that authorizes SES. That MX exists so SES can receive bounce and complaint feedback for its envelope identity. It is not a general mailbox endpoint and does not make that hostname a routable Stalwart server.

Overwriting the SES MX can make SES treat the MAIL FROM domain as unverified or fall back according to its configured behavior. Keeping the SES MX while expecting inbound tenant mail to reach Stalwart has the opposite failure: recipient traffic follows the existing MX, never the new server.

Use a role ledger before editing DNS

1. Inventory each visible From domain, recipient domain, sender, current MAIL FROM domain, DKIM d=/s=, and operational owner. Preserve Google, SES, or other live routes until an intentional migration says otherwise.
2. Allocate a dedicated Stalwart service hostname that is not already an MX, Return-Path, tracking, verification, or application name. Publish its A or AAAA record and configure the sending IP's PTR to return that hostname.
3. Choose the local recipient domain separately. In Stalwart, that domain must exist as an enabled Domain object before the server treats its recipients as local.
4. Allocate a dedicated envelope return domain for the new path. Publish SPF for the actual Stalwart sending identity without copying another provider's include.
5. Generate Stalwart DKIM signatures for the intended visible From domain, publish the exact selectors, and keep old selectors available during rotation.
6. Change recipient MX only after the server, TLS certificate, recipient directory, unknown-recipient rejection, queue persistence, and rollback path pass on the exact target.

Do not use one TXT query as the outbound acceptance test

dig TXT mail.example.com only shows TXT data at that name. SPF is evaluated against the message's SMTP MAIL FROM identity, or HELO in a null-return-path case. DMARC then compares the authenticated SPF domain and every passing DKIM d= with the visible From domain.

A published DKIM key also does not prove that Stalwart used it. Send one controlled message and require the trusted receiver to report the expected sending IP, PTR/EHLO identity, spf=pass, dkim=pass for the observed selector, and dmarc=pass for the visible From domain.

Run load and restart tests only after one message passes

A 50-message burst cannot repair an unroutable hostname, a conflicting MX, missing PTR, or unauthenticated sender. First prove one inbound recipient and one outbound message. Then test a bounded set of controlled recipients, queue backoff, a service restart, duplicate prevention, attachment limits, and per-recipient failure evidence.

For inbound testing, reject unknown recipients during SMTP instead of accepting everything and silently losing it later. For outbound testing, preserve complete SMTP replies and queue IDs without logging message bodies or recipient data.

Public field case

A current public go-live issue proposes testing Stalwart at mail.tinyhumans.ai. On 24 July 2026, public DNS returned Google as the MX for tinyhumans.ai, while mail.tinyhumans.ai returned Amazon SES's feedback-smtp.us-east-1.amazonses.com MX and an SES SPF include, but no A or AAAA answer. Both the apex and mail subdomain published DMARC quarantine policies.

Those mutable public answers do not prove private server state, intended migration ownership, a sending IP, or the selectors used by a current message. They do prove that the proposed hostname already has a live provider role and is not currently a public Stalwart host. Preserve that distinction before checking spam scores or sending a burst.

Run the public MX, SPF, DMARC, PTR and policy checks, then confirm the exact DKIM selector from one controlled message.