Trace Exim routing and delivery transports

In Exim, ACL acceptance, address routing, and transport execution are different decisions. A recipient can pass SMTP policy yet later fail because no router produces a valid delivery path.

Inspect the route before sending

Use the address-testing mode described in the Exim specification. Replace the placeholder with a controlled test address:

exim -bt test-recipient@example.com

This is a routing diagnostic, not a real message submission. Its result does not prove SMTP ACL behavior, successful authentication, or final mailbox delivery.

1. Identify the first applicable router and its domain/local-part preconditions.
2. Check alias/redirect expansion and whether it leads to local delivery or a remote transport.
3. Verify the selected transport’s mailbox path, LMTP/SMTP target, or smarthost configuration.
4. Inspect retry behavior and authenticated upstream credentials separately from recipient matching.

Keep credentials in protected configuration and follow the package’s regeneration/validation procedure. Do not paste one generic router into an existing configuration without understanding ordering.

Prove the full path

After approved changes, test a controlled accepted message and retain its Exim message ID through the delivery logs. Test the negative route too: an unintended domain must not gain relay rights because a broad router now matches it.

If an application needs structured incoming JSON, add a deliberately authenticated processing layer. Exim routing flexibility does not itself supply a provider-compatible webhook or MailKite SDK endpoint.