# SMTP server settings explained: host, port, TLS, and credentials > Configure an SMTP server correctly by mapping host, port, encryption, username, password, From address, and timeouts—and diagnose the errors caused by mixing those fields. - **Category:** Developer guide - **Published:** August 4, 2026 - **Reading time:** 17 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/smtp-server-settings](https://emailbump.com/blog/smtp-server-settings) SMTP settings are the connection details an application or mail client uses to submit outgoing email: server hostname, port, TLS mode, authentication method, username, and secret. The From address, reply address, timeouts, and sender-domain policy complete the configuration. Copy these values as one provider-issued set; mixing a host from one service with a port or credential from another will not work. > **A typical secure SMTP configuration** > > Use the provider's submission hostname, port 587 with required STARTTLS or port 465 with implicit TLS, provider-issued credentials stored server-side, and a From address on a verified domain. Do not guess the host from your website or MX record. ## The seven SMTP settings that belong together ### SMTP connection tuple ```text SETTING EXAMPLE WHAT IT CONTROLS Host smtp.provider.example Server your app connects to Port 587 Submission service on that host TLS mode STARTTLS required When encryption begins Authentication SMTP AUTH How the client proves authority Username provider-issued value Account/project identity Password scoped SMTP secret Credential; not necessarily mailbox password From address receipts@example.com Visible sender; must satisfy provider policy Also configure connect/command timeouts, certificate validation, and a Reply-To only when replies should go somewhere different from the visible From address. ``` Dashboards use inconsistent labels. SMTP server, outgoing server, address, hostname, and relay host usually mean the same field. SSL, TLS, encryption, secure, STARTTLS, and use_tls can describe different handshake modes. Read the email provider's instructions beside the library or product configuration form instead of translating labels by intuition. ## SMTP is outgoing; IMAP and POP are incoming ### Do not mix mail protocols ```text SMTP Submit and relay outgoing messages smtp.provider.example IMAP Synchronize folders and mailbox state imap.mailbox.example POP3 Download messages from a mailbox pop.mailbox.example HTTP Provider-specific send or mailbox API https://api.provider.example An SMTP service can send without providing an inbox. An IMAP mailbox can receive without being an appropriate bulk/application sender. ``` When a form asks for an “SMTP email address,” it may mean the username, the visible From address, or simply the mailbox being configured. Those are separate values. Use the provider's documented username in the authentication field and the verified sender in the From field; never assume both must be the same email address. ## Use the submission host—not your MX record MX records tell other mail servers where to deliver inbound mail for a domain. They do not advertise a supported authenticated submission endpoint for your application. Your website host, domain registrar, inbound mailbox, and outbound email provider may all be different companies. Copy the SMTP hostname from the sending provider's settings page and preserve that exact hostname for certificate validation and SNI. - Correct: smtp.provider.example copied from the provider's SMTP page. - Usually wrong: example.com merely because it is your From domain. - Wrong: the recipient domain's MX hostname; it is not your authenticated relay. - Risky: a raw IP address, because TLS certificate names normally validate the documented hostname. ## Match the port to the TLS mode ### Safe submission choices ```text PORT CONNECTION MODE COMMON CLIENT LABELS 587 SMTP greeting, then required STARTTLS STARTTLS, TLS, secure=false + requireTLS 465 TLS handshake from the first byte SSL/TLS, implicit TLS, secure=true 25 Primarily server-to-server relay Not the normal app submission choice 2525 Provider-specific fallback Use only when that provider documents it 587 and 465 can both be secure. The port and handshake mode must agree. ``` On 587, the client connects in SMTP mode, issues EHLO, requests STARTTLS, validates the certificate, issues EHLO again, and authenticates. Configure the upgrade as mandatory. On 465, TLS begins immediately. A cleartext client on 465 or an implicit-TLS client on 587 commonly produces connection resets, wrong-version errors, or unreadable protocol responses. ## Understand the SMTP username and password An SMTP username can be a mailbox address, fixed provider word, account ID, project ID, or generated token name. The password can be a dedicated SMTP credential, app password, API key accepted for SMTP, or OAuth token. Use exactly the credential type the selected service documents. Do not reuse a human account password unless the provider explicitly requires that flow and protects it appropriately. - Store the secret in server-side secret storage, not source code, browser JavaScript, mobile configuration, or a committed .env file. - Scope credentials to the smallest project and capability available and use separate production and staging credentials. - Require TLS before authentication so a client cannot transmit authority over a clear connection. - Rotate by creating and testing a new credential before revoking the old one; observe both versions during the overlap. - Treat a 535 response as an authentication failure, not a signal to retry the same secret indefinitely. ## From, envelope sender, and Reply-To are different ### Sender identities ```text VISIBLE FROM Acme Receipts What the recipient sees; DMARC aligns authentication to this domain. ENVELOPE MAIL FROM bounce+message@bounce.example.com Where delivery-status notifications return; commonly provider-controlled/aligned. REPLY-TO support@example.com Optional destination for human replies when it differs from From. SMTP USERNAME project_4821 Authenticates submission; may not be an email address at all. ``` A successful login does not grant permission to use any From address. Providers normally require domain verification and may restrict senders by project. Authentication proves the client may use the SMTP account; SPF, DKIM, and DMARC establish message-domain identities for receiving systems. ## Email Bump SMTP settings example ### Application configuration ```text SMTP_HOST=smtp.emailbump.com SMTP_PORT=587 SMTP_STARTTLS_REQUIRED=true SMTP_USERNAME=emailbump SMTP_PASSWORD= EMAIL_FROM=Acme EMAIL_REPLY_TO=support@example.com # The From domain must be verified for the selected project. # TLS is required before the server offers authentication. ``` Email Bump project keys are already bound to a project, so the normal username is emailbump. An all-access key can require a project ID as the username when the From domain cannot identify one project. Use the live SMTP page in the dashboard as the source of truth rather than copying credentials from an article. ## Map the same settings into common libraries ### Nodemailer on port 587 ```typescript import nodemailer from "nodemailer" const transport = nodemailer.createTransport({ host: process.env.SMTP_HOST, port: 587, secure: false, // TLS does not start at TCP connect requireTLS: true, // STARTTLS must succeed auth: { user: process.env.SMTP_USERNAME, pass: process.env.SMTP_PASSWORD, }, connectionTimeout: 5_000, greetingTimeout: 5_000, socketTimeout: 15_000, }) ``` Library options are not portable names. For example, secure=false in Nodemailer on 587 does not mean “send unencrypted”; requireTLS forces the STARTTLS upgrade. In another framework, use_tls=true may represent that same path. Confirm the generated connection behavior, not only the checkbox label. ## Test one layer at a time ### SMTP troubleshooting order ```text 1. DNS Does the documented hostname resolve? 2. NETWORK Can this runtime reach the exact host and port? 3. TLS Does the handshake mode match and certificate validate? 4. EHLO Does the server advertise the expected extensions? 5. AUTH Are username, credential, scope, and account state correct? 6. MAIL FROM Is the envelope sender permitted? 7. RCPT TO Is this recipient accepted under provider policy? 8. DATA Is message syntax and size accepted? 9. EVENTS What happened after provider submission? Preserve the exact reply and stage. “SMTP failed” is not a diagnosis. ``` OpenSSL can inspect reachability and TLS without embedding a production password: use -starttls smtp on 587 and a direct TLS connection on 465. Do not paste credentials into terminal recordings or public support tickets. A successful socket proves neither sender verification nor destination delivery. ## Common SMTP settings errors - Connection timeout: wrong host/port, DNS failure, egress firewall, or infrastructure restriction. - Wrong TLS version or unexpected record: implicit TLS and STARTTLS modes are reversed. - Certificate name mismatch: raw IP, alias, interception, or wrong provider hostname. - 530 Must issue STARTTLS first: the client tried to authenticate before encryption. - 535 Authentication failed: wrong username format, secret, scope, revoked key, or disabled SMTP access. - 550 Relay denied or From not permitted: login succeeded, but sender/project policy failed. - 552 Too large: total encoded message exceeds provider policy; attachments expand under MIME/base64. - 250 accepted but no inbox arrival: submission worked; inspect provider delivery events and remote responses. ## Production SMTP checklist - Copy host, port, TLS mode, username, and credential from one current provider screen. - Validate the provider hostname and certificate; never disable verification in production. - Keep credentials server-only, scoped, rotated, and separate by environment. - Use a verified From domain and configure SPF, DKIM, DMARC, and aligned return paths. - Set connect, greeting, command, socket, and total-operation timeouts. - Queue important message intent outside the request path and give each message a usefulness expiry. - Treat a timeout after DATA as ambiguous because the server may already have accepted the message. - Store the provider message ID and process authenticated delivery, bounce, and complaint events. ## Frequently asked questions ## How do I find my SMTP server settings? Open the outgoing email provider's SMTP or integration page and copy its host, port, TLS mode, username, and generated secret. Do not infer the host from your website, From domain, registrar, or MX records. If the service only exposes an HTTP API, it may not offer SMTP at all. ## Is my SMTP username my email address? Sometimes, but not universally. It can be a mailbox address, account name, fixed provider value, project ID, or token identity. The SMTP username is also separate from the visible From address. Follow the provider's field mapping exactly. ## Should SMTP use port 465 or 587? Use a provider-supported combination. Port 587 normally uses mandatory STARTTLS; port 465 uses implicit TLS from the first byte. Both can be secure when configured correctly. The existing SMTP ports guide covers the protocol and diagnostics in depth. ## Connect an existing application without exposing a new API surface Use Email Bump's authenticated TLS submission endpoint with a verified domain, then inspect accepted messages and delivery outcomes in the same project. - TLS-required SMTP submission - Project-scoped credentials - Delivery, bounce, and complaint events [Learn more](https://emailbump.com/docs/smtp) ## Complete the SMTP setup - [SMTP ports](https://emailbump.com/blog/smtp-ports-25-465-587-2525) — Choose correctly between 25, 465, 587, and provider-specific 2525. - [Email sent vs delivered](https://emailbump.com/blog/email-sent-vs-delivered) — Understand what submission and receiver events actually prove. - [Email sandbox](https://emailbump.com/blog/email-sandbox-testing) — Contain SMTP from local development, CI, QA, and staging. - [Bounce handling](https://emailbump.com/blog/email-bounce-handling-guide) — Interpret downstream recipient-server responses after submission. ## Sources - [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409) - [RFC 8314: TLS for Email Submission and Access](https://www.rfc-editor.org/rfc/rfc8314) - [RFC 4954: SMTP Authentication](https://www.rfc-editor.org/rfc/rfc4954) - [Email Bump SMTP documentation](https://emailbump.com/docs/smtp)