What Is SMTP and How Does It Work? SMTP vs PHP mail()

SMTP (Simple Mail Transfer Protocol) is the standard set of rules that mail servers use to send email to each other and accept email from your apps. When you press Send, your mail app or website hands the message to a sending server over SMTP, that server looks up where the recipient's domain receives mail, and passes the message to the receiving server, again over SMTP. Websites that skip a proper SMTP login and use the server's built-in PHP mail() function instead are the most common reason contact form and order emails land in spam or never arrive.

This guide is for business owners and site managers who keep hearing "you need SMTP" and want to know what that actually means before paying for it or setting it up.

#What SMTP does, in plain words

SMTP is the delivery part of email, and only the delivery part. It covers how one computer tells another "I have a message from this sender, for this recipient, here it is", and how the other side answers yes, not now, or no.

The current standard is RFC 5321 (opens in a new tab), published by the IETF. It describes a simple conversation: the client says hello, names the sender, names each recipient, sends the message, and the server replies to each step with a three-digit code. A relay, in the RFC's words, is a system that receives mail from one SMTP client and passes it on to another server, changing nothing except adding trace headers.

Two other protocols sit beside SMTP and often get mixed up with it:

• IMAP lets a mail app read and organise mail that stays on the server, so your phone and laptop show the same inbox.
• POP3 downloads mail to one device, usually removing it from the server.

So when Outlook asks for "incoming" and "outgoing" servers, incoming is IMAP or POP3 and outgoing is always SMTP. My guide to setting up business email in Outlook, iPhone and Android walks through those screens.

#How an email travels from sender to inbox

Every email takes the same basic route, whether it comes from you in Outlook or from a WooCommerce store sending an order confirmation.

1. Your app or website connects to a submission server. This is the server run by your email provider or sending service. RFC 6409 (opens in a new tab) reserves port 587 for this job and says the submission server must, by default, refuse mail from a session that has not logged in. RFC 8314 (opens in a new tab) adds port 465 for submission with encryption from the first byte.
2. The submission server looks up the recipient's MX record. MX (mail exchanger) records in DNS say which servers accept mail for a domain. RFC 5321 section 5.1 describes this lookup, including the fallback when a domain has no MX record at all.
3. It connects to the receiving server on port 25 and delivers. RFC 5321 says the SMTP port, assigned by IANA, is port 25. This is server-to-server traffic.
4. The receiving server runs its checks. It looks at the sending server's IP address, SPF, DKIM and DMARC, content and reputation, then files the message in the inbox, the spam folder, or rejects it.
5. The recipient reads it in Gmail, Outlook or a phone app, using IMAP, POP3 or the provider's own app.

If anything goes wrong at step 3 or 4, the receiving server answers with an error code, and the sending server either retries later or sends a bounce message back to the sender.

#What the reply codes mean

Every SMTP reply starts with a digit that tells you the outcome. These come from section 4.2 of RFC 5321.

When you see an error like "550 mailbox unavailable" or "535 authentication failed", that first digit already tells you whether waiting will help. My guide to SMTP errors and how to fix them goes through the common ones one by one.

#How websites send email: PHP mail() vs SMTP

Most websites send email in one of two ways. The default is to hand the message to the web server's own mail program through PHP's mail() function. The better way is to log in to a real SMTP server, or a sending service's API, and send it from there.

WordPress is a good example because so many business sites run on it. The source code of wp_mail() (opens in a new tab), the function every form plugin and WooCommerce uses to send email, shows three things a site owner should know:

• It uses the PHPMailer library, and by default tells it to "use PHP's mail()", so the message goes to the server's local mail program.
• If nothing else sets a sender, the From address is built as wordpress@ followed by your domain, with "WordPress" as the name.
• Its own documentation says "A true return value does not automatically mean that the user received the email successfully."

That last point catches many people out. A form plugin can show "Thank you, your message was sent" while the email quietly dies on the server or in the recipient's spam filter. WordPress provides a hook, phpmailer_init, that SMTP plugins use to switch PHPMailer from mail() to a proper SMTP login. That is all an SMTP plugin really does.

#Why the default mail function lands in spam or gets blocked

Mail sent through PHP mail() usually fails for reasons that have nothing to do with the message itself. The receiving server simply cannot tell that your web server is allowed to send for your domain.

There is no login and often no authentication. Google's email sender guidelines (opens in a new tab) require every sender to set up SPF or DKIM for the sending domain, use TLS, and have valid forward and reverse DNS (PTR) records for the sending IP. A shared web server rarely meets all of these for your domain. Its IP is usually not in your SPF record, it does not sign with your DKIM key, and its reverse DNS points to the host's own name.

The IP address is shared. On shared hosting, hundreds of sites may send from the same IP. If one of them sends spam, the reputation of that IP drops for everyone.

Cloud servers often cannot send at all. Many cloud platforms block outbound port 25, which PHP mail() relies on to deliver mail directly:

• DigitalOcean's support page says SMTP ports 25, 465 and 587 are blocked on Droplets (opens in a new tab) by default, and recommends a third-party email service.
• Google Cloud's documentation says connections to destination port 25 are blocked (opens in a new tab) when the destination is outside your network, while ports 587 and 465 are not restricted.
• Microsoft Azure blocks outbound port 25 on virtual machines for most subscription types and recommends an authenticated relay on port 587.
• AWS throttles port 25 traffic from EC2 by default; Amazon SES's documentation (opens in a new tab) says to request removal of the limit or use a different port.

On these servers, a site using PHP mail() may show no error at all, while every message sits in a queue or is thrown away.

The From address does not match. Mail from wordpress@ your domain, sent by a server that is not authorised for that domain, fails DMARC alignment checks, which is a strong spam signal.

#What switching to SMTP changes

Moving a website from PHP mail() to authenticated SMTP, or a sending service, fixes the structural problems above. It does not fix bad content or a bad list, but for forms, orders and password resets it is usually the whole fix.

The settings themselves (host, port, username, encryption) are covered in my guide to SMTP settings, ports and encryption. If you are building an app rather than a WordPress site, also read SMTP vs email API, because an HTTP API is often the better fit there.

#Do you need SMTP for your website?

If your website sends any email that matters, yes. That includes contact form notifications, WooCommerce order and account emails, booking confirmations, password resets and admin alerts. The only sites that can live without it are those that send nothing at all.

You do not always need a paid service. Many sites send through the business mailbox they already have, such as Google Workspace or Microsoft 365, within those providers' sending limits. Stores and apps that send more, or that need logs and bounce tracking, are better served by a transactional sending service.

#When to get help

You can switch a small WordPress site to SMTP yourself with a plugin and your mailbox password, and many owners do. It is worth getting help when:

• Order or password reset emails have already gone missing and customers are complaining.
• Your site is on a VPS or cloud server where mail ports may be blocked.
• You need SPF, DKIM and DMARC set up without breaking your existing business email.
• You run several sites, a store, or an app that sends to many people.

My SMTP and transactional email setup service covers choosing a sending service, connecting it, setting the domain records and testing every email your site sends. If your mail is arriving but landing in spam, the email deliverability service is the closer fit, and the wider question of mailboxes on your own domain is covered in my domain and business email setup guide.