The four values
The hostname identifies the submission server, and it is usually distinct from the incoming mail hostname even at the same provider. It comes from the provider's own documentation rather than from the domain's MX record, which points at the servers that receive mail rather than the one that accepts submissions.
The port selects the submission mode. Port 587 is the submission port defined in RFC 6409, where the session upgrades through STARTTLS, and port 465 carries an implicitly encrypted connection recommended for submission in RFC 8314.
The encryption type must match the port. Selecting STARTTLS against 465 fails because that port expects a TLS handshake before any command, and selecting implicit SSL against 587 fails for the mirror-image reason.
The credential is the username and password pair. On most hosted mail the username is the full email address rather than the local part, because one server serves many domains.
Gmail as a worked example
Google publishes smtp.gmail.com as the submission host, accepting port 465 with SSL or port 587 with TLS. Authentication is required on both.
Sign in with the full Gmail address as the username, paired with a 16-character app password generated in Google Account security settings, which Google issues only on accounts that have two-step verification enabled.
The account password does not work. Google blocks account passwords for third-party mail clients on accounts with two-step verification, because an SMTP client cannot complete the second factor, so the app password exists to fill that gap.
General setup rules
Match the sender address to the authenticated account. A From header that does not correspond to the authenticated mailbox or an authorised domain is rejected by many servers outright and fails alignment checks at the receiver even where it is accepted.
Read the credential from the environment rather than the source. A password in a repository is a live sending credential distributed to everyone with read access, and rotating it is the only remedy afterwards.
That is also the split we enforce on our own platform: API keys exist for server-side integration, minted for the machine and living in its environment, while browser sign-in tokens stay short-lived and personal.
Verify with the client's own test send before relying on the configuration. A successful test proves the hostname, port, encryption and credential agree, which is exactly the scope of what a configuration can guarantee.
George's rule is simply to offer a test send before any real send, and the reason it is a rule rather than a suggestion is that configuration errors are silent until they are expensive. The settings look right in a form. Nothing tells you otherwise until a batch goes out.
We learned the specific version of this the hard way. Our own preflight was not verifying that an outgoing message could actually be built with a valid From header before enqueueing hundreds of jobs, so the validation passed and the failure surfaced downstream, once the work was already queued. The lesson generalises past our codebase: a check that validates the settings without attempting the thing the settings are for is not a check.
What preflight covers for us now is deliberately wider than a connection test: domain verification, sender configuration, audience validity, content compliance and a spam score, run as a dry run before anything is queued. The point is to fail on a validation rather than on a send, because a send that fails has already spent reputation.
What configuration does not determine
A correct configuration authenticates a client to one server. It says nothing about whether a receiving system will place the resulting message in an inbox, because that decision belongs to the receiver and happens after acceptance.
Configuration strictness is a server-side choice too, and we set ours deliberately: on Nitrosend's forwarding relay, TLS and exact SMTP authentication are mandatory, the listening port is firewalled to our API host, and unsigned or replayed requests are dropped rather than negotiated with.
Domain authentication is a separate layer entirely. SPF, DKIM and DMARC are DNS records published for the sending domain and evaluated by the receiver, and no client setting substitutes for them.
Our deliverability checks read exactly that layer, SPF, DKIM and DMARC configuration, and report bounce rates alongside, because the settings form on this page cannot tell you any of it.
Acceptance is not delivery. The submission server returning success means it has taken responsibility for the message, and bounces, deferrals and spam filing all happen after that point without notifying the client.
Common configuration failures
A connection that times out rather than refusing is usually a blocked outbound port. Networks and hosting providers block outbound SMTP widely, and the symptom is silence rather than an error message.
An authentication rejection on a previously working setup normally means the credential was revoked or the client fell back to the account password. Regenerating the application-specific credential resolves the ordinary case.
A rejection quoting a policy or a blocklist is a reputation result and not a settings problem. Changing the hostname, port or credential has no effect on it, because the receiving server has already decided about the source address.
Certificate errors indicate a name mismatch or an outdated trust store rather than a wrong port. Disabling certificate validation removes the protection against an active attacker while leaving the underlying misconfiguration in place.
A mismatch between the configured sender and the verified domain deserves its own mention, because it is the error that most often survives a working connection test. The credential authenticates, the message goes out, and the From address belongs to a domain nobody verified. My preferred fix is to validate the template sender against the brand's verified domains at save time and at go-live, warning rather than blocking, so the problem is caught while someone is still editing rather than mid-campaign.
Chong, on our team, closed the other half of that gap. The sender guidance surfaces now show the effective fallback sender, the address mail will actually leave from, with regression tests covering invalid stored and template sender addresses, so a stale green state cannot quietly misreport what a send would do.