What is SMTP testing?
SMTP testing is the practice of verifying that a mail server accepts connections, negotiates encryption correctly, and authenticates valid credentials. Instead of writing a script that sends a real message and hoping for the best, an SMTP test exercises every protocol step in isolation so you can pinpoint exactly where a problem occurs. When a customer complains that "the contact form is not working", an SMTP test usually answers the question in under ten seconds.
A good SMTP test is more than a TCP ping. It opens a real socket, reads the 220 greeting, sends EHLO, parses the advertised extensions, upgrades the connection to TLS when appropriate, and attempts AUTH with the credentials you supply. SMTPTester returns the raw server responses alongside human-readable diagnostics so you do not have to guess what a 535 5.7.8 reply means.
How SMTP actually works
The Simple Mail Transfer Protocol is, true to its name, deliberately simple. It is a line-based, text-oriented protocol where the client issues commands and the server replies with a three-digit status code plus a human-readable message. The 1xx through 3xx codes are progress indicators, 4xx codes are transient failures, and 5xx codes are permanent failures.
A typical session looks like this. The client opens a TCP connection to port 587. The server responds with 220 mail.example.com ESMTP. The client sends EHLO and the server lists its capabilities — STARTTLS, AUTH LOGIN PLAIN, SIZE 35882577, PIPELINING. The client issues STARTTLS, upgrades to an encrypted channel, sends EHLO again, then authenticates. Once authenticated the client can issue MAIL FROM, RCPT TO and DATA to transfer the message body, then QUIT.
Every modern problem with email delivery — slow handshakes, authentication failures, blocked TLS, throttling — surfaces somewhere in that exchange. The reason SMTP feels mysterious in 2025 is that most application frameworks hide the protocol behind a one-line sendMail() call. SMTPTester pulls the curtain back.
Why email deliverability matters
Inbox placement is a billion-dollar problem. A 2024 industry survey found that the average legitimate sender loses between 8 and 20 percent of its mail to spam folders. For a SaaS company that sends password resets, that translates directly into support tickets and lost trial conversions. For a marketing team it means campaigns that never recoup their cost.
The SMTP layer is your first line of defense. A misconfigured relay will reject mail outright. A working relay that authenticates over an unencrypted channel will eventually have its credentials stolen. A relay that advertises weak ciphers will be downgraded by major providers like Gmail and Microsoft 365. Testing the relay regularly catches these issues before they escalate.
The most common SMTP errors and what they mean
Memorising every SMTP status code is unnecessary, but a handful come up so often that they are worth knowing on sight.
- 421 — Service not available. Usually a temporary throttle. Wait and retry with exponential backoff.
- 450 / 451 / 452 — Transient failures. The recipient mailbox is full, busy, or your IP is being rate-limited. Retry later.
- 501 — Syntax error. Your client sent a malformed command, often a misencoded address.
- 530 5.7.0 — Authentication required. You hit the wrong port or skipped AUTH.
- 535 5.7.8 — Authentication credentials invalid. Almost always a wrong password or a missing app password.
- 550 — Mailbox unavailable. The recipient address does not exist, or your IP is blocklisted.
- 554 — Transaction failed. Your sender domain failed DMARC, or the message tripped a content filter.
SMTP authentication explained
Authentication is the step that proves you are allowed to send through this relay. There are three mechanisms you will encounter in 2025: AUTH LOGIN, AUTH PLAIN, and XOAUTH2. The first two transmit a base64-encoded username and password and rely on TLS to keep them confidential. XOAUTH2 wraps an OAuth access token instead — preferred for Gmail Workspace and Microsoft 365 mailboxes that have disabled password-based SMTP.
For password-based mechanisms always use an app password rather than your account password when the provider offers one. App passwords are scoped to a single application, can be revoked individually, and bypass interactive 2FA prompts that would otherwise block automated systems. Google, Microsoft, Apple, Yahoo, Fastmail and most security-aware providers issue them through their account-settings UI.
How to troubleshoot SMTP issues step by step
When mail stops flowing, work the problem from the bottom up. Start with the network, then encryption, then authentication, then content. Skipping layers is the fastest way to waste an afternoon.
- Reach the host. A connection timeout is always a network problem. Confirm DNS resolves and the firewall allows the destination port.
- Negotiate TLS. If STARTTLS fails, your client likely lacks an up-to-date CA bundle, or the server presents an expired certificate.
- Authenticate. A 535 reply means credentials. A 530 reply means you never authenticated. A 534 reply means the mechanism is too weak.
- Send a test message. Once auth succeeds, send a small message to a Mailgun, Postmark, or Litmus seedlist to confirm delivery.
- Check headers. Inspect the delivered headers for SPF, DKIM and DMARC results. Any "fail" there explains why the message went to spam.
SMTP security best practices
Treat your SMTP relay like any other production credential store. Rotate passwords at least every 90 days, scope app passwords to a single workload, never commit them to source control, and enforce TLS on every connection. If you operate your own mail server, run a recent build of Postfix or Exim and disable plaintext AUTH on port 25 entirely.
Publish SPF, DKIM and DMARC for every domain you send from. SPF authorises the IPs you send from. DKIM cryptographically signs the message so receivers can prove the body has not been tampered with. DMARC tells receivers what to do when SPF and DKIM disagree with the visible From address. A misaligned DMARC record is the single most common reason legitimate mail lands in spam in 2025.
Email sending optimisation tips
High deliverability comes from a few unglamorous habits. Warm up new sending IPs gradually instead of dumping a million emails on day one. Segment transactional and marketing traffic onto separate IP pools so a marketing complaint cannot tank your password-reset deliverability. Honour unsubscribes immediately and visibly — Gmail now requires a one-click List-Unsubscribe header for bulk senders. Monitor bounce and complaint rates daily, and pause sending to any list with a complaint rate above 0.3 percent until you understand why.
On the protocol side, reuse SMTP connections rather than reopening them for every recipient, batch RCPT TO commands to take advantage of PIPELINING, and prefer port 465 with implicit TLS when latency matters. A warm pooled connection sends in roughly 80 milliseconds; a cold socket with a fresh TLS handshake takes four to five times longer.
SMTP configuration guide for popular providers
Most "I cannot get SMTP working" problems are solved by copying a known-good configuration. Here are the canonical settings for the providers we see most often. Use these with SMTPTester to confirm before you ship.
Gmail: smtp.gmail.com 587 STARTTLS email + app password
Microsoft 365: smtp.office365.com 587 STARTTLS UPN + app password
Outlook.com: smtp-mail.outlook.com 587 STARTTLS email + app password
SendGrid: smtp.sendgrid.net 587 STARTTLS "apikey" + API key
Mailgun: smtp.mailgun.org 587 STARTTLS postmaster@domain + key
Postmark: smtp.postmarkapp.com 587 STARTTLS server token (both fields)
Amazon SES: email-smtp.<region>.amazonaws.com 587 STARTTLS SMTP creds
Zoho Mail: smtp.zoho.com 465 SSL/TLS full email + password
iCloud: smtp.mail.me.com 587 STARTTLS Apple ID + app password
Yahoo: smtp.mail.yahoo.com 587 STARTTLS email + app passwordWhen to call it: knowing what a successful test does and does not prove
A green pass from SMTPTester proves that your client can reach the server, that encryption is negotiated, and that authentication succeeds. That is necessary but not sufficient for inbox placement. The remaining work — DNS records, sending reputation, content quality, list hygiene — happens above the protocol layer. Use the relay test to eliminate the bottom-of-the-stack causes, then move on to deliverability monitoring with a tool like GlockApps, Mailtrap or your provider's own analytics.
Keep SMTPTester bookmarked. Run a test every time you rotate credentials, change provider, or hear "an email did not arrive" from a customer. Ten seconds of diagnosis beats an hour of guessing every single time.