SMTP Server Setup Guide for Cold Email

To send cold email over SMTP you need four things working together: an authenticated SMTP endpoint (a mail server or a relay service), a sending domain with correct DNS records, encryption on the connection (TLS), and a client or sequencer that submits messages using the right port and credentials.

The minimum checklist looks like this:

Get any one of these wrong and mail either fails to send or lands in spam. The rest of this guide walks through each piece. If you are unsure which port to use, our SMTP ports explained guide breaks down 25, 465, 587, and 2525 in detail.

There are two ways to send. Running your own mail server (Postfix, Exim, or a self-hosted stack) gives you full control but puts you in charge of IP reputation, blacklist hygiene, and patching. Using an SMTP relay (the submission endpoint of Google Workspace, Microsoft 365, or a transactional provider) offloads the infrastructure but limits volume and configuration.

The deeper trade-offs of running your own box are covered in self-hosted email server and the distinction between the two endpoints in SMTP relay vs SMTP server. For cold outreach specifically, raw SMTP from a fresh IP almost always underperforms real provider mailboxes, which is why most senders use Google Workspace or Microsoft 365.

Use the submission ports, not port 25. Port 25 is for server-to-server relay and is blocked outbound by most residential and cloud providers to limit spam. For a client or sequencer submitting authenticated mail, the choices are:

• Port 587 with STARTTLS is the modern default per RFC 6409. The connection starts in plaintext, then upgrades to TLS before credentials are sent.
• Port 465 with implicit TLS opens an encrypted connection immediately. It was deprecated, then re-registered for submission in RFC 8314, which now recommends implicit TLS.
• Port 2525 is an unofficial fallback some relays offer when 587 is blocked by a network.

Never submit authenticated mail without TLS. Sending credentials over plaintext exposes them on the wire. If a provider offers only port 25 for submission, that is a red flag.

Modern providers no longer accept a plain account password over SMTP. You will use one of three mechanisms:

App passwords. Google Workspace and Microsoft 365 let you generate a single-purpose password for SMTP clients when basic auth is still permitted. This is the simplest path for a sequencer that supports SMTP credentials.

OAuth 2.0 (XOAUTH2). The preferred and increasingly required method. The client exchanges a token rather than a static password. Microsoft has been retiring basic authentication for Exchange Online, so OAuth is the durable choice. See Microsoft 365 SMTP settings for the exact host, port, and auth flow.

API keys. Transactional relays authenticate with an API key over SMTP AUTH or via an HTTP API.

A failed login returns a 535 5.7.8 authentication error. If you see that, regenerate the app password, confirm the username is the full email address, and verify the account is licensed for SMTP. The full catalog of failures is in common SMTP errors and fixes.

Authentication records are what stand between your mail and the spam folder. Google and Yahoo require SPF, DKIM, and a DMARC policy for bulk senders, and treat missing records as a strong negative signal. The four records you need:

Start with the SPF record setup, then DKIM setup, then DMARC setup. If you want the full picture of how the three interlock, read email authentication SPF DKIM DMARC explained. Stay under the SPF 10-lookup limit, and start DMARC at p=none so you can monitor reports before enforcing.

For server-to-server delivery you also want a PTR (reverse DNS) record matching your sending hostname. Many receivers reject mail from IPs without valid forward-confirmed reverse DNS.

Once the server, ports, auth, and DNS are in place, connect your sending tool. Most sequencers accept either native provider integration (recommended) or raw SMTP credentials.

Native integration uses OAuth to connect Google Workspace or Microsoft 365 directly. This is more stable and respects provider sending limits cleanly.

SMTP connection requires you to enter host, port, username, and password. A typical Google Workspace configuration:

Host: smtp.gmail.com
Port: 587
Encryption: STARTTLS
Username: [email protected]
Password: <app password>

After connecting, send a test message to a seed inbox and check the headers with Gmail's Show Original view. Confirm SPF, DKIM, and DMARC all show PASS. Respect the per-mailbox daily caps documented in email sending limits for Google and Microsoft; exceeding them triggers rate-limit errors and reputation damage.

A new domain and a new sending identity have no reputation. Sending a few hundred cold emails on day one from a fresh setup is the fastest way to the spam folder or an outright block. Ramp gradually.

These figures are guidance, not guarantees; engagement signals matter more than raw numbers. The full process is in the cold email warmup guide and domain warmup best practices. Monitor reputation throughout with Google Postmaster Tools.

Raw SMTP from a self-built server can work for transactional mail, but cold outreach is judged on inbox placement, and that depends on reputation you cannot buy overnight. A fresh IP, an unsigned hostname, or a single misconfigured record can sink an entire campaign.

Managed providers solve the reputation and configuration problem. InboxKit provisions real Google Workspace, Microsoft 365, and Azure mailboxes on US IPs, and configures SPF, DKIM, DMARC, and MX automatically through Cloudflare in under 60 seconds. Its InfraGuard monitoring runs blacklist checks every six hours, watches your DNS, and auto-pauses sending if something breaks, which removes the most common cause of cold-email failure: silent misconfiguration. It connects to 24-plus sequencers natively, so you skip manual SMTP credential entry entirely.

The trade-off is control versus reliability. If you need fine-grained server control, self-host. If you need cold email to land, real mailboxes with managed DNS win. Pricing and slot counts are in InboxKit pricing.

When mail fails to send or lands in spam, work through this list in order:

1. 1Connection refused or timeout. Port 25 is blocked, or you are using the wrong port. Switch to 587 or 465.
2. 2535 authentication failed. Wrong username, expired app password, or basic auth disabled. Regenerate credentials or move to OAuth.
3. 3TLS handshake errors. Mismatched encryption mode for the port (implicit TLS on 587, or STARTTLS on 465). Match the mode to the port.
4. 4550 relay denied. The server will not relay for your domain or recipient. Authenticate, or confirm the relay allows your domain.
5. 5Mail sends but goes to spam. Check SPF, DKIM, and DMARC pass; check the domain and IP against blacklists with check domain blacklisted; and review why cold emails go to spam.
6. 6Sudden delivery drop. Run a blacklist removal check and review reputation in Postmaster Tools.

Each numeric reply maps to a defined meaning, explained in SMTP error codes explained.