What do I do with the SMTP username and password I was given?

The four fields, and what each one is

Every mail client asks for the same four things under slightly different names. 'Outgoing server', 'SMTP server' and 'sending server' are one field. 'User', 'username' and 'account name' are one field. The values appear on the domain's Sending tab at the moment you create them, and the password appears there once and never again.

The server is the address where your mail is handed to us. It is the same for every customer, which surprises people who expect a hostname on their own domain: what identifies you is not where you connect, it is what you authenticate as when you get there.

The port decides how the connection is encrypted, and the next section is about why 587 is the answer almost every time.

The username is a full address on your own domain. This is the part most often got wrong, because most other services in the world use a short account name. Here the address IS the authorisation: the server compares the domain in your username against the domain you are trying to send as, and a short name would not say which domain it belonged to.

The password belongs to that username. It is generated at creation, shown once, and stored as a one-way hash — so it cannot be shown to you again, and it cannot be read out of our database by anyone who reaches it. That is a deliberate trade: the cost is that a lost password means creating a new one, and the benefit is that a copy of our database is not a set of working credentials for every customer's mail.

A credential belongs to a domain, not to a person. Everyone sending as that domain can use the same one, and revoking it stops all of them at once — which is exactly what you want the day a laptop goes missing.

587 or 465, and why 25 is not on the list

Use 587. The connection opens in the clear and immediately upgrades to TLS with STARTTLS, which is what the standard for mail submission specifies and what every current client does by default. If your client asks you to choose, 'STARTTLS' and 'TLS' in that dialog usually both mean this.

Some older clients, and a number of hosting control panels, offer only a checkbox marked 'SSL'. That means implicit TLS on port 465: the connection is encrypted from the first byte rather than upgrading. It is equally secure and equally supported here. Choose it if 587 is not offered, and do not spend time on the difference otherwise.

What genuinely matters is that encryption is on at all. A client configured with 'None' would put your password on the network in plain text, so it is refused rather than quietly accepted — a refusal you can see beats a leak you cannot.

Port 25 is not an option, and that is not our restriction. Cloud and home providers block outbound 25 almost universally to limit spam, which is precisely why mail submission moved to 587. If a piece of software offers only port 25 for sending, it is old enough that its other assumptions are worth checking too.

Where the values go, by what is sending

In Gmail: Settings, then Accounts and Import, then 'Send mail as', then Add another email address. Gmail asks for exactly these four values and then sends a confirmation code to the address, which arrives wherever that address is routed. The step-by-step, including why the 'Treat as an alias' choice changes what recipients see, is in the guide on replying as your own domain.

In Outlook or Apple Mail: add the address as an account, or as an alias where the client supports one, and put the same four values in the outgoing server section. Both offer to test the settings before saving, and it is worth letting them — a failure at that moment tells you far more than a message that vanishes tomorrow.

In a shop or a website: look for 'SMTP' under notification, transactional or outgoing email settings. WooCommerce, Shopify apps, WordPress plugins and most site builders take the same four fields. Set the 'from' address to the same address as the username unless you have a specific reason not to, because a from address on a different domain is refused.

In your own code: any SMTP library takes host, port, user and pass, and there is nothing special about ours. If you would rather not hold a password in an application at all, the API and the MCP tools send the same mail through a scoped key that can be revoked on its own without disturbing anybody else's client.

The three things that actually go wrong

Authentication is refused. Almost always the username: it must be the full address, and it must be on the domain you are sending as. Retyping the password is the instinct and is almost never the fix — check the username first, and check that nothing has helpfully capitalised its first letter.

The connection authenticates but sending is refused with a domain mismatch. The 'from' address configured in your client is on a different domain from the credential. Change the from address rather than looking for a wider credential: a credential that could send as any domain would be a credential worth stealing, and the boundary is the reason it exists.

It sends, and recipients see a warning or find it in spam. That is not the SMTP settings at all — those clearly worked, because the message went. It is the DNS records, and the setup screen shows each one with its own state so you can see which is still outstanding. Sending starts working before every record is published; looking right to a recipient does not.

SMTP and DNS fail in opposite directions. A broken credential produces an error you see immediately. A missing DNS record produces mail that leaves successfully and is quietly filtered at the other end.

One more, rarer and worth naming: mail that worked for weeks and then stops. That is usually a DNS record removed during unrelated work, and it revokes the credentials on purpose — a domain that no longer proves it is yours is a domain we stop sending for. The setup screen will say so, and re-publishing the record restores it.