Operate Haraka authenticated submission and outbound queues
Configure submission authentication and signing deliberately and diagnose queued delivery without enabling public relay or duplicating sends.
Reviewed
Haraka has an outbound delivery engine and can serve as an authenticated submission service. Its getting-started guide explains that messages marked for relaying, such as by an authentication plugin, enter outbound processing.
Constrain the submission path
- Choose the documented authentication plugin and credential source for the installed release.
- Configure the intended submission listener, trusted TLS, and sender/relay authorization.
- Configure the supported signing plugin and protect private DKIM keys for each authorized domain.
- Persist queue state appropriately and monitor delivery failures, queue age, and disk capacity.
Authentication success must not become unrestricted permission to impersonate every hosted sender. Keep public MX recipient acceptance separate from application submission policy.
Verify queue ownership and failure handling
Use one approved application message and track its submission/queue identity through logs to delivery or bounce. Test invalid credentials, unauthenticated relay, and a temporary destination failure.
Do not delete the queue or resubmit application messages merely because delivery is delayed. An uncertain connection can hide a successful acceptance; reconcile existing evidence before another send. Keep configuration, keys, and queue recovery in the operational backup plan. If using MailKite instead for managed sending, treat it as an explicit transport change, not a Haraka-specific SDK adapter or automatic duplicate-safe failover.