SMTP authentication (RFC 4954) lets a submission client identify itself to the MTA before sending. It uses SASL mechanisms — PLAIN, LOGIN, CRAM-MD5, XOAUTH2 — negotiated after the STARTTLS handshake.
Mechanisms
- PLAIN / LOGIN. Username and password sent in the clear at the SASL layer — safe only inside TLS. The practical default.
- CRAM-MD5. Challenge-response, avoids sending the password. Rarely useful now that TLS is universal.
- XOAUTH2. OAuth 2.0 bearer token instead of a password. Used by Google and Microsoft for delegated sending.
TLS and authentication
Never advertise or accept AUTH before STARTTLS on port 587. Port 465 (SMTPS) wraps the whole session in TLS from the outset. Port 25 is server-to-server and should not require AUTH.
Authentication vs IP allow-listing
Some setups skip authentication and rely on IP allow-listing at the MTA. This is acceptable for machine-to-machine relays in a controlled network. For anything traversing the public internet, authenticate.
Related articles
- SPF ExplainedHow Sender Policy Framework works, how to author a record correctly, and how to avoid the common failure modes.
- DKIM ExplainedDomainKeys Identified Mail — how signing works, selector strategy, key length and rotation, and what DKIM cannot do.
- DMARC GuideHow DMARC ties SPF and DKIM together, staged policy rollout from monitor to reject, and how to use aggregate reports.
- Google Postmaster GuideHow to set up Postmaster Tools, what each metric means, and how to interpret the reputation graph.
- PowerMTA OptimizationVMTA design, queue tuning, per-domain policy, and the configuration mistakes that quietly cost inbox rate.
- IP Warm-upHow to warm a new IP without wasting weeks or torching reputation. Volume curves, segmentation, and when to stop.