Configure ZoneMTA sending zones and domain signing
Route authorized application traffic to the intended delivery pool and constrain sender-controlled routing choices.
Reviewed
Sending zones let ZoneMTA apply different connection/rate/IP policies to selected traffic. They do not bypass recipient consent, suppressions, IP reputation, or domain authorization.
Define trusted routing policy
- Review sending-zone, plugin, and DKIM configuration in the upstream project.
- Define which authenticated application/tenant may use each zone and source identity.
- Configure only IP addresses actually assigned/routed to the host and align their DNS/PTR/SMTP identities.
- Install/protect the correct domain signing material and set bounded connection/rate behavior for destinations.
Do not trust a public request’s arbitrary zone or sender field as authorization to use a higher-trust pool. Enforce the mapping in a trusted application/plugin layer before delivery is queued.
Verify routing and outcomes
Use a single approved message to confirm selected zone, source IP, signature, queue identity, and destination response. Test that an unauthorized caller cannot switch pool or impersonate another tenant.
Inspect per-destination deferrals and complaints rather than increasing concurrency blindly. Isolating traffic into zones can reduce coupling but does not guarantee reputation isolation or inbox placement. A managed MailKite connection is a different transport choice; changing providers does not automatically carry queue identity, authorization policy, or duplicate-prevention state across systems.