Why it is usually not your account password
Providers stopped accepting account passwords from third-party clients because an SMTP client cannot complete a two-step verification challenge. A second credential type was required to keep those clients working.
Google blocks account passwords for mail clients entirely on accounts with two-step verification, documented under app passwords.
Microsoft has scheduled basic authentication for client SMTP submission for deprecation, pointing at OAuth instead, per its device and application guide.
Smaller providers and self-hosted servers frequently still accept the mailbox password, so the answer genuinely depends on the provider rather than being universal.
Application-specific passwords
An app password is a generated credential, typically 16 characters, scoped to one application and revocable on its own. It authenticates through the ordinary PLAIN or LOGIN mechanism, so no client changes are needed.
Revocability is the security property that matters. A leaked app password is contained to the application it was issued for, whereas a leaked account password compromises everything.
Generate one per application rather than reusing a single credential. Sharing one across several systems removes the isolation that makes them worth using.
Most providers display the value once. Copy it into an environment variable or a secrets manager immediately, since the credential cannot be retrieved later, only regenerated.
OAuth tokens
OAuth replaces the password with an access token obtained through an authorisation flow, carried over the XOAUTH2 mechanism defined alongside SMTP authentication in RFC 4954.
A token is scoped, expiring and revocable in ways a password is not, which is why both Google and Microsoft are steering toward it.
The cost is implementation. OAuth requires registering an application, handling a refresh flow and storing tokens, which is more work than a password field. For anything expected to keep working long-term against a major provider, that work is unavoidable.
Scoped credentials also change how you have to test them. George, our CEO, found our own SendGrid connection check probing an endpoint that demanded a broader scope than sending needs, so a valid least-privilege Mail Send key returned a 403 and was reported invalid. The fix was probing an endpoint any valid key can read, where an invalid key still fails cleanly with a 401. A credential check has to be scoped as narrowly as the credential it is checking.
Handling the credential safely
Never commit it. A password in a repository is a live sending credential distributed to everyone with read access, and rotating it is the only remedy once it is there.
Read it from an environment variable, a platform secret store or an encrypted configuration file. Deployment tooling universally supports this, so there is no case where hardcoding is the only option.
We draw the same line on our own platform. Server-side integrations run on API keys minted for the machine, and a short-lived browser sign-in token is never the thing a production sender should hold, because it expires mid-run and authenticates a person rather than a service.
Transmit it only inside TLS. PLAIN and LOGIN both send the credential base64-encoded, which is not encryption, so authentication must follow STARTTLS on port 587 or run on an implicitly encrypted connection on 465.
Serious servers enforce that from their side too. On Nitrosend's own relay there is no plaintext path to fall back to: TLS and exact SMTP authentication are mandatory, and an unsigned or replayed request is rejected instead of retried.
Rotate on staff departure and on any suspected exposure. Per-application credentials make this cheap, since revoking one does not disturb the others.
What the credential does not do
A valid password authenticates you to one server as one mailbox. It carries no information about sending limits, which are applied per mailbox and sized for a person rather than an application.
It also says nothing about whether mail arrives. Authentication to the submission server is a separate question from the domain authentication that receivers evaluate, and a correctly authenticated client sending from an unauthenticated domain still gets filtered.