Setting up SMTP authentication without breaking sending

SMTP authentication fails for boring reasons: the port and encryption mode do not match, the username is not the full address, or an account password is being used where the provider requires a generated credential. Here is the configuration that works, and how to prove it before you point production at it.

Get the port and mode pairing right first

Set these as a pair. A client configured for STARTTLS against 465, or for implicit SSL against 587, produces handshake errors that look like credential problems and are not.

Credential rules differ by provider

• Full address as the username. Always, including on hosted domains. you@yourdomain.com, never you.
• Generated app passwords where required. Google requires two-step verification on the account before an app password can exist, which is why the option appears missing for people who have not enabled it. Yahoo requires an app password for third-party clients outright.
• OAuth where it is offered. Google and Microsoft both support token-based authentication, and Microsoft has been phasing out basic authentication across Exchange Online including SMTP AUTH — so for a Microsoft 365 tenant, confirm whether password authentication still works for you at all before building on it.
• API keys at ESPs. SendGrid, Mailgun, Postmark and Amazon SES issue SMTP credentials that are not your account login. Treat them as scoped secrets, create one per integration, and give each the minimum permission that works.

One credential per integration is the rule that saves you later: revoking a shared secret breaks everything at once, usually at the worst moment.

Verify the session by hand

Before you trust a configuration, run it:

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf
EHLO test.example
250-AUTH PLAIN LOGIN XOAUTH2
250-STARTTLS
AUTH LOGIN
334 VXNlcm5hbWU6
<base64 username>
334 UGFzc3dvcmQ6
<base64 password>
235 2.7.0 Authentication successful

What to take from it: the AUTH list tells you which mechanisms are even possible, and a 235 is proof the credential works independently of your application's code. If the EHLO response has no AUTH line, you are on the wrong port or the server requires the upgrade first.

Then interpret failures by code rather than by the client's wording:

A 5xx is permanent. Automatic retries against it are pointless and, on some providers, trigger protections that obscure the real fault.

Where to keep the secret

1. Environment variables or a secret manager, never in source control or a shared document.
2. Separate credentials per environment. A staging system holding production SMTP credentials will eventually send something you did not intend.
3. Rotation on personnel change, and whenever a credential has been pasted anywhere you cannot audit.
4. Least privilege. If the provider can issue a send-only key, use it rather than one that can also read mailboxes or change account settings.
5. Audit what holds access. On Google Workspace and Microsoft 365, admins can list and revoke third-party application access centrally; use that rather than trusting an inventory spreadsheet.

Authentication working is not sending working

A 235 proves the server will accept mail from you. It says nothing about whether receivers will trust it. Two separate checks:

• Session level: the openssl run above.
• Domain level: send to a mailbox on another provider and read the headers. You want spf=pass, dkim=pass with header.i naming *your* domain, and dmarc=pass with header.from aligned. A pass on a bounce subdomain with a different visible From domain is an alignment failure, and it is the most common reason authenticated mail still lands in spam.

Beyond that, placement depends on reputation, list quality and volume shape, none of which authentication touches. Watch your spam rate against Google's 0.30% threshold — aim under 0.10% — and measure placement with seed mailboxes rather than inferring it from a successful send.

What not to do

• Do not authenticate over an unencrypted session. Base64 is encoding, not protection.
• Do not disable certificate verification to resolve a connection error.
• Do not use port 25 for application submission. It is widely blocked and not the submission port.
• Do not reuse one credential across tools and environments.
• Do not loop on a `535`. Fix the credential; retries can lock the account.
• Do not conclude from a successful test send that deliverability is fine. Accepted mail includes mail filed in spam.

How MailPilot helps

MailPilot connects mailboxes over OAuth for Gmail, Google Workspace, Outlook and Microsoft 365, and over SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom hosts — validating port, encryption and credentials at connection time so a bad pairing surfaces immediately. It then checks SPF, DKIM and DMARC alignment on the sending domain, warms the mailbox with real conversations, and measures inbox placement per provider.