Secure OpenSMTPD submission and upstream relay access
Separate authenticated application listeners from Internet MX traffic and protect smarthost credentials and TLS configuration.
Reviewed
An MX listener receives mail for your domains. A submission listener authenticates your applications/users. A relay action may then authenticate to an upstream service. Configure those three boundaries deliberately rather than opening a trusted relay to make one client work.
Configure listeners and credentials
- Use the installed release’s smtpd.conf reference for listener TLS/auth options and credential tables.
- Give the submission service a trusted certificate for the hostname clients actually use and require the intended authentication/TLS behavior.
- Match authenticated/local application traffic to the authorized action, keeping public MX rules limited to accepted destinations.
- For a smarthost, configure the documented relay URL and protected authentication table. Restrict file access and avoid putting passwords into public command histories.
Use smtpd -n to check the resulting file before a controlled reload. Do not copy older accept-style examples into a build using current match/action syntax without checking compatibility.
Test both permission directions
Confirm an approved client can submit from its intended identity and a non-authenticated client cannot relay to an unrelated domain. Then check upstream authentication and destination delivery separately.
An SMTP client connection test is not proof of final delivery. Track the envelope/queue outcome and avoid an application resend after an ambiguous timeout until you know whether the original was accepted. MailKite’s sending SDK is an independent service path, not an OpenSMTPD-specific adapter package.