What Is SMTP? A Plain-English Guide for Admins

SMTP is the protocol that actually moves outbound email. If a user can read mail but can't send, or a server is queuing messages and never delivering, you're almost always looking at an SMTP problem rather than a mailbox problem. The fix usually lives in three places: the right port, working authentication, and DNS records that let the receiving server trust you. This page explains what SMTP is, where it sits next to IMAP and POP3, and how it shows up during a migration.

What SMTP is#

SMTP stands for Simple Mail Transfer Protocol. It is defined in RFC 5321 and has been the standard for sending email since the early 1980s. When you click Send, your mail client opens an SMTP connection to a submission server. That server then opens further SMTP connections to the recipient's mail servers to relay the message onward. Every hop between mail servers on the public internet is SMTP.

SMTP only moves messages in one direction: out. It does not store mail, it does not let you list folders, and it does not let you mark anything as read. Those jobs belong to IMAP or, on legacy systems, POP3.

Submission vs relay#

SMTP plays two roles, and confusing them is the source of a lot of "why won't this send?" tickets.

• Submission is a user's mail client handing a message to their own provider. This happens on port 587 with STARTTLS, or on port 465 with implicit TLS. Submission always requires authentication.
• Relay is one mail server passing a message on to another mail server. This happens on port 25. Relay is unauthenticated by design and is filtered heavily to fight spam.

Most cloud and residential networks block outbound port 25 entirely, which is why you cannot run a mail server from a laptop and why your monitoring scripts have to use port 587 with credentials.

Ports, TLS and authentication#

You only need to remember three numbers:

• 25 — server-to-server relay. Plaintext, sometimes upgraded with STARTTLS.
• 465 — submission with implicit TLS. The connection is encrypted from the first byte.
• 587 — submission with STARTTLS. The client connects in plaintext and then upgrades to TLS before sending credentials.

For authentication, modern providers want OAuth2 (Microsoft 365, Google Workspace) or a provider-issued app password. The classic AUTH LOGIN with the account password still exists for legacy IMAP/SMTP hosts, but most major providers have switched it off. If your test script returns AUTHENTICATIONFAILED against a Microsoft 365 mailbox, basic auth is almost certainly the cause.

How SMTP relates to DNS#

Receiving servers will only accept your mail if DNS says they should. Three records do most of the work, and all three need to be correct before mail flows reliably from a new tenant.

• The recipient's MX record tells you where to deliver mail for that domain.
• Your own SPF record lists which servers may send mail using your domain.
• Your DKIM keys let receivers verify the message wasn't altered in transit.
• Your DMARC policy tells receivers what to do when SPF or DKIM fails.

Skip any of these during a cutover and you will see mail land in spam or bounce with policy errors that look nothing like an SMTP problem at first glance.

SMTP during an email migration#

Migrations copy historical mail over IMAP, not SMTP. So SMTP shows up at two specific moments.

First, during pre-cutover testing. You configure the new mailbox in a test client and try to send a message to an external address. If that works, SMTP submission and authentication are healthy at the destination.

Second, immediately after cutover. Once MX is flipped, the world starts trying to relay mail to the new servers. If SPF or DKIM is wrong, those inbound deliveries will arrive but land in junk, and outbound replies from the new tenant may be rejected by strict receivers.

Common SMTP errors you'll see#

• STARTTLS handshake failed — usually a TLS version mismatch or a stripped TLS by a middlebox.
• Relay access denied — you're trying to relay through a server that doesn't trust your IP or your auth.
• Message too large for destination — recipient size limit, not yours.
• Too many simultaneous connections — your script is hammering submission; throttle and reuse the connection.