SMTP Settings Explained: Host, Port, Credentials and Connection Errors
Find the right SMTP host, port, encryption and credentials, diagnose failures by stage, and understand when your application needs an email API.
TL;DR
- An SMTP connection needs a provider-supplied host, port, encryption mode and authentication method. Your From address is a separate message field.
- Find those settings in the documentation or account configuration for the service that actually sends your email. Do not infer the SMTP host from your website domain or inbound MX record.
- Diagnose connection, TLS, authentication and sender-authorization failures separately. Replacing a password will not fix a blocked port.
- MailBlastr currently sends through its HTTPS API. If an application accepts only a direct SMTP connection, choose a provider that supports it or use a supported API integration.
What is an SMTP server address?
An SMTP server address is the hostname your application or mail client connects to when submitting a message to a mail service. It identifies a network destination, not a mailbox.
For example, a fictional configuration might connect to smtp.example.net while sending a message whose visible From address is receipts@example.com. Those values have different jobs. The username may be a provider-defined identifier, and the password may be a generated credential rather than the password used to read an inbox.
The service's documentation is the source for the correct connection settings. A domain's MX records normally describe incoming mail routing; they do not automatically reveal the authenticated submission endpoint your application should use.
Collect the complete configuration
Record the following values together. A partial screenshot showing only the hostname is often insufficient to diagnose a failure.
| Setting | What it controls | Where to confirm it |
|---|---|---|
| Host | The server to connect to | Provider documentation or account settings |
| Port | The service endpoint on that server | The provider's supported submission ports |
| Encryption mode | How the secure connection starts | The instructions for the selected port |
| Authentication method | How the client proves it may submit mail | Provider authentication guidance |
| Username and secret | The actual credentials for that method | Your authorized credential configuration |
| From address | The sender shown in the message | Your verified sender/domain settings |
Some services use passwords, generated SMTP credentials or API keys in a password field. Others support an authentication flow such as OAuth. Do not assume that a normal mailbox password is accepted simply because a form labels the field “password.”
Keep secrets in your application's server-side configuration or a suitable secret store. Redact them before sharing a diagnostic report. A screenshot of an authentication error should not include the credential that caused it.
Match the port to the encryption mode
The port and encryption setting need to agree with the provider. An implicit TLS endpoint expects a TLS handshake immediately. A STARTTLS connection begins with the SMTP exchange and upgrades to TLS before protected operations proceed.
Do not solve a handshake error by disabling certificate verification or allowing credentials to travel over an unencrypted connection. First check that the client is using the mode documented for that endpoint and that its trust configuration and clock are correct.
For a concrete provider example, Resend's SMTP documentation currently specifies smtp.resend.com, username resend and an API key as the password. It lists port 465 for implicit TLS and 587 for STARTTLS, alongside other supported ports. A verified domain is required. These are Resend's settings, checked in September 2026; they are not a universal SMTP configuration or MailBlastr credentials.
Our SMTP versus email API guide explains the broader integration choice if your application can use either interface.
Configure the application that will actually send
Identify where the configuration runs. Settings on your laptop do not necessarily control the production worker, scheduled job or deployed application. Confirm the environment variable names the software reads and whether a restart or deployment is needed for a change to take effect.
In a hosted application, check that outbound connections to the selected endpoint are allowed. If a connection times out before authentication, inspect the network path and hosting restrictions before rotating credentials.
Use a controlled test recipient you own or are authorized to contact. Start with a simple message and a verified sender. Add templates, attachments and application-specific options only after the basic connection works. This isolates the failing stage and avoids sending repeated test messages to customers.
Diagnose the failure by stage
The same “email failed” label can hide very different problems:
| Observed stage | Possible issue to investigate | Evidence to collect |
|---|---|---|
| Host cannot resolve | Misspelled host or DNS problem | Configured hostname and resolver error |
| Connection times out | Network restriction or unavailable endpoint | Host, port, timestamp and deployment environment |
| TLS negotiation fails | Wrong mode, trust problem or unsupported configuration | Redacted TLS error and documented endpoint settings |
| Authentication is rejected | Invalid credentials, wrong authentication method or disabled access | Provider error code and credential scope, without the secret |
| Sender is rejected | Unverified or unauthorized From identity | Exact sender domain and verification status |
| Submission succeeds but mail is missing | Later delivery, filtering or recipient-side issue | Provider message identifier and delivery events |
Do not treat an accepted submission as proof of inbox placement. Use the delivered-but-not-received checklist to follow the next stage when the receiving server accepted a message but the user cannot find it.
Use MailBlastr through its supported interface
MailBlastr currently exposes its sending workflow through the HTTPS API and SDKs; its direct SMTP listeners are not deployed. This limitation is also called out in the Auth0 integration documentation.
If your software supports an HTTP hook or server-side extension, use the send-email API reference to evaluate that integration. If it only provides an SMTP hostname-and-password form, an API key cannot magically turn that form into an HTTPS client. Use a supported SMTP service or change the integration through an extension the application actually supports.
Do not run an improvised public relay to bridge the gap without understanding authentication, abuse controls, queueing and delivery operations. The decision should be based on the application's supported interfaces and the responsibility your team is prepared to operate.
Keep a useful configuration record
Document the provider, environment, host, port, encryption mode, credential owner and last successful controlled test. Store only a reference to the secret, not the secret itself. Record how to rotate it and who can verify the sending domain.
When moving providers, update sender authorization and event handling as well as the connection fields. Follow the email migration checklist so that a successful connection does not conceal lost suppressions, missing bounce events or a changed retry policy.
Frequently asked questions
How do I find my SMTP host?Identify the service your application uses to send mail, then check its official connection instructions or your authorized account configuration. Your website hostname and incoming-mail MX are not dependable substitutes.
Is the SMTP password my email password?Not necessarily. The provider may require a generated credential, API key or another authentication method. Follow its current instructions and keep the secret out of client-side code.
Should I use port 465 or 587?Use a port and encryption mode supported together by your provider and client. Do not choose one independently of the other or disable TLS checks to make a mismatch work.
Can I put a MailBlastr API key into an SMTP-only application?No. MailBlastr currently uses its HTTPS sending interface. Use a supported API integration or a provider with a deployed SMTP endpoint.