Separate Postfix submission authentication from Internet SMTP
Choose a SASL backend, require TLS for credentials, and distinguish application submission from upstream smarthost authentication.
Reviewed
An Internet-facing MX must receive mail from other servers without giving them permission to relay elsewhere. Authenticated application submission is a separate job, normally exposed through a deliberately configured submission service.
Select the authentication direction
Postfix’s SASL guide distinguishes SMTP-server authentication from SMTP-client authentication to an upstream relay. First inspect compiled support:
postconf -a
postconf -A- For application login, configure the supported Dovecot or Cyrus SASL backend and verify its credential source first.
- Configure the submission listener/service overrides and require the documented TLS/authentication policy. Protect the authentication socket and any chroot-specific paths.
- Decide which authenticated identities may use which envelope senders; successful login is not permission to impersonate every domain.
- If using a smarthost, configure client-side authentication and protected password maps separately. Do not reuse a user’s login password as a provider API key.
Verify without weakening TLS
Use an approved account and recipient for an end-to-end application test. Check certificate hostname/trust, authentication success, sender authorization, and the resulting queue identity. Never disable certificate verification to make a deployment test pass.
Also verify unauthenticated submission is rejected and a failed login does not fall back to trusted-network relay. Use a maintained SMTP client for application integration. MailKite’s SDK is a different managed transport, not a Postfix-specific adapter or authentication backend.