An SMTP relay test tells you whether an application, server, or email platform can submit a message through an SMTP server safely and successfully. The useful version of the test does not stop at “port 587 is open”: it verifies TLS, login or IP-based authorization, envelope sender policy, relay restrictions, and whether a message reaches a mailbox with the expected authentication results.

What an SMTP relay test actually proves

SMTP is the protocol used to submit and transfer email. A relay is a server that accepts a message and passes it on toward its recipient. In a production setup, your website, SaaS application, CRM, or server normally submits outbound mail to an SMTP relay; the relay then applies its policies and delivers or queues the message for onward delivery.

A complete SMTP relay test answers five separate questions:

Can the client reach the correct SMTP endpoint and port?
Is the connection encrypted with TLS when your configuration requires it?
Can the client authenticate, or is its source IP authorized to submit?
Will the relay accept the specific envelope sender and recipient combination?
Did a receiving mailbox accept the message, and did SPF, DKIM, and DMARC behave as intended?

Those are different checkpoints. A TCP connection can succeed while authentication fails. Authentication can succeed while the relay rejects an unverified MAIL FROM address. The relay can accept the message with 250 and the recipient provider can later place it in spam, reject it, or defer it. SMTP itself is a store-and-forward protocol, so the server response to your submission and final inbox placement are related but distinct outcomes. (rfc-editor.org)

Know which SMTP service and port you are testing

Before running a command, identify whether you are testing message submission or server-to-server relay. This distinction prevents a common mistake: trying application credentials on a port intended for mail transfer between servers.

Port 587: normal authenticated submission

Port 587 is the standard message-submission port. It is generally the right endpoint for an application, website, local mail client, or background worker that sends mail through a provider. Message submission is deliberately separated from relay so that the submission service can enforce authentication and sender policies. (rfc-editor.org)

In practical terms, use port 587 when your provider gives you settings such as:

Host: smtp.provider.example
Port: 587
Security: STARTTLS
Username: an SMTP username, API-derived SMTP credential, or account name
Password: an SMTP password or token

Port 465: implicit TLS

Port 465 is commonly used for SMTP submission where TLS begins immediately when the TCP connection opens. This is different from STARTTLS: with implicit TLS, the client must begin a TLS handshake before it sends EHLO. Email-submission security guidance describes the use of TLS for submission and access services, while the exact port choices and labels shown in a provider dashboard remain vendor-specific. (rfc-editor.org)

Port 25: server-to-server transport

Port 25 is traditionally used for SMTP relay between mail transfer agents. It may be appropriate for a server you operate that delivers mail directly to recipient MX hosts, but it is not the default choice for a web application submitting mail with credentials. Many networks restrict outbound port 25 to reduce abuse, so a timeout on port 25 does not automatically mean your SMTP credentials or relay configuration are wrong. RFC 6409 explicitly distinguishes relay over port 25 from submission, normally on port 587. (rfc-editor.org)

The TLS modes must match

Use this matching rule:

SMTP endpoint	Expected security mode	Typical client behavior
`:587`	STARTTLS	Connect in plaintext, issue `EHLO`, upgrade with `STARTTLS`, then send `EHLO` again
`:465`	Implicit TLS	Start TLS immediately, then issue `EHLO` inside the encrypted connection
`:25`	Depends on relay policy	Often opportunistic STARTTLS for server-to-server transfer; do not assume it accepts app credentials

After a server accepts STARTTLS and the TLS handshake completes, the SMTP client must discard knowledge obtained before TLS and issue EHLO again. That second EHLO is not optional protocol decoration; it refreshes the advertised capabilities for the protected session. (rfc-editor.org)

Prepare a safe SMTP relay test

Only test a relay you administer or have explicit permission to test. An SMTP server that forwards mail for unauthenticated, untrusted parties can be abused as an open relay, which can lead to spam, blocklist problems, and loss of provider reputation. Your goal is to prove that your authorized sending path works and that unauthorized relaying is rejected.

Collect these values before starting:

SMTP hostname, such as smtp.example.net
Port: typically 587 or 465
Encryption mode: STARTTLS or implicit TLS
Authentication method required by your provider
Authorized SMTP username and password/token, if applicable
A verified envelope sender, such as alerts@example.com
A mailbox you control for the recipient, such as a personal Gmail, Outlook, Fastmail, or test-domain address
The provider’s sender-domain and DKIM setup instructions

Create a unique test identifier so that you can trace the one message through logs, dashboards, and mailbox search. A value such as smtp-relay-test-2026-01-15-a7f4 works well. Put it in the subject and optionally in a custom header.

Do not use a customer address as your first test destination. Use a mailbox you control, and avoid putting credentials, API keys, reset links, or production data in a test message. SMTP command transcripts can contain recipient addresses, server banners, message content, and—if mishandled—credentials.

If you are replacing a provider or connecting a new application, keep the application’s SMTP settings in a secret manager or environment variables rather than committing them to source control. Your relay vendor’s SMTP setup guides should define its exact hostname, TLS mode, credential format, sender-verification rules, and rate limits.

The SMTP conversation you should expect

An SMTP relay test becomes much easier to debug when you understand the transaction sequence. SMTP uses numeric replies: reply classes beginning with 2 indicate success, 3 means more input is required, 4 indicates a temporary failure, and 5 indicates a permanent failure for that attempt.

A successful encrypted and authenticated session commonly looks conceptually like this:

S: 220 smtp.example.net ESMTP ready
C: EHLO app.example.com
S: 250-smtp.example.net
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
... TLS handshake happens ...
C: EHLO app.example.com
S: 250-smtp.example.net
S: 250-AUTH PLAIN LOGIN
C: AUTH ...
S: 235 Authentication successful
C: MAIL FROM:<alerts@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<you@your-test-mailbox.example>
S: 250 2.1.5 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Alerts <alerts@example.com>
C: To: You <you@your-test-mailbox.example>
C: Subject: smtp-relay-test-2026-01-15-a7f4
C:
C: SMTP relay test message.
C: .
S: 250 2.0.0 Queued as abc123
C: QUIT
S: 221 2.0.0 Bye

EHLO identifies the client and asks for Extended SMTP capabilities. A server can advertise extensions such as STARTTLS, AUTH, SIZE, and SMTPUTF8; do not assume every server advertises every extension. SMTP authentication is an extension defined separately from the base SMTP protocol, which is why you should inspect the post-TLS EHLO response before deciding what authentication flow is available. (rfc-editor.org)

The envelope commands are not the same as visible message headers. MAIL FROM establishes the envelope return path; RCPT TO gives the actual delivery target. From:, To:, and Subject: are message headers sent after DATA. A message can have a To: header that differs from its SMTP RCPT TO target, so test both the transport path and the message content deliberately. (rfc-editor.org)

Run a manual SMTP relay test with OpenSSL

OpenSSL is useful when you need to see the TLS negotiation and type SMTP commands yourself. Its s_client utility is a general TLS diagnostic client, and it supports an SMTP STARTTLS mode. (docs.openssl.org)

Test STARTTLS on port 587

Replace the hostname with your relay host:

openssl s_client \
  -starttls smtp \
  -connect smtp.example.net:587 \
  -servername smtp.example.net \
  -crlf \
  -quiet

What to look for before you type any SMTP command:

The command connects instead of timing out or returning Connection refused.
Certificate verification completes successfully in the environment where the command runs.
The certificate name is appropriate for the hostname you configured.
You receive an SMTP 220 banner after the TLS setup.

Then enter the non-authenticated portion of the transaction manually:

EHLO app.example.com
MAIL FROM:<alerts@example.com>
RCPT TO:<you@your-test-mailbox.example>
DATA
From: Alerts <alerts@example.com>
To: You <you@your-test-mailbox.example>
Subject: smtp-relay-test-2026-01-15-a7f4

SMTP relay test sent through STARTTLS.
.
QUIT

Whether this succeeds without a login depends on the relay’s policy. A submission service may reject MAIL FROM, RCPT TO, or DATA until you authenticate; that is often the correct and secure result. Do not regard unauthenticated rejection as a broken relay until you verify the provider’s intended authorization model.

Test implicit TLS on port 465

For an endpoint configured for immediate TLS, do not use -starttls smtp. Connect directly with TLS instead:

openssl s_client \
  -connect smtp.example.net:465 \
  -servername smtp.example.net \
  -crlf \
  -quiet

Once connected, begin with EHLO app.example.com. If you mistakenly use a plaintext SMTP client against an implicit-TLS endpoint, the server will not understand the plaintext EHLO; if you try direct TLS against a STARTTLS-only endpoint, the handshake will fail. That mismatch is one of the fastest ways to produce confusing “wrong version number,” handshake, or connection-reset errors.

Why OpenSSL is not ideal for credentialed testing

You can manually execute SMTP authentication, but it requires handling SASL mechanisms and base64-encoded values correctly. More importantly, entering or pasting a password into a terminal transcript is easy to leak through shell history, screen recording, shared terminal logs, or support tickets. Use OpenSSL for TLS and protocol inspection; use a purpose-built SMTP test client for a real authenticated transaction.

Run an authenticated SMTP relay test with Swaks

Swaks—short for Swiss Army Knife for SMTP—is a flexible, scriptable, transaction-oriented SMTP testing tool. Its documentation describes support for SMTP/ESMTP, TLS, authentication, and related SMTP extensions, making it a better choice than an ad hoc telnet session when you need a repeatable test. (github.com)

STARTTLS example for port 587

This worked example sends one message through a submission relay using STARTTLS. Replace every placeholder before running it:

swaks \
  --server smtp.example.net \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user 'SMTP_USERNAME' \
  --auth-password 'SMTP_PASSWORD_OR_TOKEN' \
  --from 'alerts@example.com' \
  --to 'you@your-test-mailbox.example' \
  --header 'From: Alerts <alerts@example.com>' \
  --header 'Subject: smtp-relay-test-2026-01-15-a7f4' \
  --body 'SMTP relay test message sent with STARTTLS.'

The exact authentication mechanism is relay-specific. LOGIN is shown because it is commonly supported, but your server may advertise or require PLAIN, OAuth-based authentication, a client certificate, or IP allowlisting instead. Read the capabilities returned after EHLO; use only an authentication method your relay documents and advertises.

For port 465, Swaks configuration differs because TLS must begin at connection time. Use the Swaks option intended for TLS-on-connect in the installed version, rather than assuming --tls means the same thing for every port. Check swaks --help or the version’s manual page before automating it; the tool’s major purpose is test flexibility, but command options are software-version-specific. (github.com)

Interpret a successful Swaks run

A useful pass condition includes all of the following:

The connection reaches the intended hostname and port.
TLS is negotiated when required.
The relay returns a successful authentication response when credentials are used.
MAIL FROM, RCPT TO, and the end of DATA receive success-class responses.
The output gives a queue ID or accepted-for-delivery response, if the relay provides one.
The test message appears in the controlled recipient mailbox.

A 250 response after the terminating period means the SMTP relay accepted responsibility for the message. It does not guarantee inbox placement. Continue with mailbox inspection and provider logs before declaring the migration or configuration complete.

Worked example: test a web app relay end to end

Assume a fictional application sends transactional email through smtp.mail.example, using alerts@acme.test as the sender. Its provider specifies port 587, STARTTLS, and username/password authentication.

Step 1: verify basic reachability and TLS

From the same machine, container, or deployment environment that will send production email, run:

openssl s_client \
  -starttls smtp \
  -connect smtp.mail.example:587 \
  -servername smtp.mail.example \
  -crlf \
  -quiet

If the connection times out, investigate egress firewall rules, VPC/network policy, DNS resolution, or provider allowlists before changing credentials. If the certificate fails validation, verify the hostname in the application configuration and look for TLS interception by a corporate proxy or security appliance.

Step 2: send one authenticated message

Store the credential in a temporary environment variable or secret mechanism suitable for your system rather than placing it in a repository. Then send a message with a unique identifier:

swaks \
  --server smtp.mail.example \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user "$SMTP_USERNAME" \
  --auth-password "$SMTP_PASSWORD" \
  --from 'alerts@acme.test' \
  --to 'owner@your-test-mailbox.example' \
  --header 'From: Acme Alerts <alerts@acme.test>' \
  --header 'To: Relay Test <owner@your-test-mailbox.example>' \
  --header 'Subject: smtp-relay-test-acme-a7f4' \
  --body 'This is an authorized SMTP relay test.'

If the relay returns 235 followed by 250 responses for the envelope and final message acceptance, the submission path is working. Save the timestamp, SMTP response, relay queue identifier if present, sending host/IP, and test identifier. Those details are what support teams need if the provider dashboard and recipient mailbox disagree.

Step 3: inspect the recipient mailbox

Search the mailbox for smtp-relay-test-acme-a7f4, including spam and quarantine folders. Open the full message headers and inspect:

Received: lines to confirm the message traveled through the expected relay.
Authentication-Results: for SPF, DKIM, and DMARC outcomes.
The visible From: address and the envelope/return-path domain.
Any recipient-provider warnings, spam classification, or policy notes.

A successful relay test should show that the actual message was accepted by the relay and delivered to the mailbox. A better production-readiness test also shows that the sender identity aligns with your domain-authentication design.

Step 4: test the application itself

A command-line pass does not prove that your application uses the same settings. Trigger a low-risk real application event—for example, a test signup confirmation—to the same mailbox. Compare the app-generated message’s headers, sender, and relay path with the Swaks message.

Differences usually point to one of these configuration problems:

The app is reading an old environment variable.
The background job worker has a different secret or network route than the web process.
The app overwrites From: with a default address.
The library’s TLS setting does not match the configured port.
The sender is verified in one provider account or region but not the account/region your app uses.

Test relay policy without creating an open-relay risk

A relay must know who is authorized to submit mail and for which senders. Authorization might be based on SMTP AUTH, source IP allowlisting, a private network, mutual TLS, a local Unix socket, or a combination of these controls.

The safe policy test is not “can I make a random host send to a random external domain?” Test your own server with a controlled recipient and compare authorized versus unauthorized behavior.

The two checks to run

Authorized path: authenticate with valid credentials, use an approved envelope sender, and send to a mailbox you control. The relay should accept the transaction.
Unauthorized path: from an untrusted context or without credentials, attempt the same controlled external recipient flow only if you are authorized to test that policy. The relay should reject it unless your policy intentionally permits that source IP or network.

A rejection such as 530 Authentication required, 535 Authentication credentials invalid, 550 Relaying denied, or another 5xx policy response is usually evidence that the relay is protecting itself. Exact wording and enhanced status codes vary by server implementation, but the distinction remains: a 4xx response suggests retry may make sense, while a 5xx response signals a condition that must be changed rather than retried blindly. (rfc-editor.org)

Do not use third-party “open relay test” sites or probe systems outside your authority merely to validate configuration. It adds little diagnostic value compared with a controlled test and can violate service terms or trigger security monitoring.

Verify sender identity after the relay accepts mail

A relay test can pass and still produce poor deliverability. Recipient systems evaluate the identity of the message and the sending infrastructure, not just whether your relay accepted a command sequence.

SPF

SPF is published in DNS as a TXT record and identifies which servers are authorized to send mail for a domain. A generic illustrative record looks like this:

example.com. TXT "v=spf1 include:spf.provider.example -all"

The include mechanism is provider-specific; never copy it from an unrelated vendor. Your domain should have one coherent SPF policy that accounts for every system allowed to send using the relevant envelope domain. Adding a new relay often requires updating the existing SPF record rather than creating a second separate SPF TXT record. Google’s setup guidance specifically says to identify all email senders and update SPF when you add a new mail server or third-party sender. (support.google.com)

DKIM

DKIM adds a cryptographic signature to an email. The public key is published under a selector in DNS, while the relay or sending platform signs the message with its corresponding private key. A DKIM TXT record resembles this structure:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

The selector, key type, and public-key material come from the sender platform. A relay that modifies signed content after DKIM signing—for example, by appending a footer—can break the signature, so check the received message’s Authentication-Results: rather than assuming a published record proves a valid signature. (support.google.com)

DMARC

DMARC tells recipient systems what to do when mail claiming to be from your domain does not pass aligned SPF or DKIM checks. A cautious starting record can look like this:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none requests monitoring rather than quarantine or rejection. It can be appropriate while you inventory all legitimate senders, but it is not the same as enforcing protection. After reviewing reports and fixing unknown senders, organizations may choose a stronger policy based on their risk tolerance. DMARC action values include monitoring/delivery, quarantine, and reject. (support.google.com)

Reverse DNS and TLS

If you deliver directly from your own IP, confirm that the IP has a valid PTR/reverse-DNS record and that its hostname resolves forward appropriately. For high-volume senders to personal Gmail accounts, Google states requirements around SPF, DKIM, DMARC, valid forward and reverse DNS, and TLS. Even at lower volume, these controls are useful signals of a legitimate sending setup. (support.google.com)

Run basic DNS checks from a terminal:

dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short
dig TXT _dmarc.example.com +short
dig -x 203.0.113.25 +short

Treat these commands as configuration checks, not final delivery proof. The definitive check is a new message received through the actual relay, with the headers showing the expected results.

Diagnose common SMTP relay test failures

Connection timeout or connection refused

A timeout usually means the network path is blocked or unreachable: incorrect hostname, DNS problem, firewall rule, cloud security group, provider IP allowlist, or outbound-port restriction. Connection refused more often means a reachable host is not listening on that port. Confirm the hostname, port, and network egress policy before rotating credentials.

TLS handshake or certificate error

First verify the port/mode pairing. Use STARTTLS on 587 only when the relay offers it; use immediate TLS on 465 only when the provider documents implicit TLS. Next verify the configured hostname matches the certificate and that the runtime has a current CA bundle. TLS is designed to provide confidentiality and integrity protections, but those protections depend on validating the correct peer identity rather than merely encrypting a connection. (rfc-editor.org)

`535` authentication failure

Check the credential type. A dashboard login password may not be an SMTP password; a provider may require a generated SMTP credential, API token, app password, or OAuth workflow. Also confirm that the server advertises the mechanism you configured after TLS, and make sure you are testing the same account, region, tenant, and host used by the application.

`530` authentication required or `550 relaying denied`

This usually means the client reached the relay but has not met its authorization policy. Add the correct authentication configuration, use the authorized network path, or register the source IP if the relay uses allowlisting. Do not “solve” it by switching to port 25 or disabling encryption without confirming the relay’s documented policy.

`550` sender rejected or domain not verified

Many email platforms restrict MAIL FROM or visible From: addresses to verified domains and identities. Confirm the exact domain and subdomain, then make sure the application is not overriding the sender address. If your test uses alerts@sub.example.com but only example.com or a different sender identity is verified, the relay may reject it or rewrite it.

`250 accepted`, but nothing is in the inbox

Search spam, junk, quarantine, and all mail folders using the unique test ID. Then inspect the relay’s event log using the queue ID or message ID. If the relay accepted the message but the recipient system later deferred or rejected it, the provider’s delivery event will usually reveal the destination response. If it was delivered but classified as spam, examine authentication results, domain alignment, message content, sending IP reputation, and recipient engagement separately from the SMTP connection.

Automate SMTP relay testing without sending unnecessary mail

A one-off manual test is useful during setup. A repeatable check is better for a critical transactional-email path.

Build a small test that runs from the same network context as your production sender and records these fields:

Test identifier and UTC timestamp
SMTP hostname, port, and configured TLS mode
Whether TLS negotiation succeeded
Authentication result, without logging secrets
SMTP result for MAIL FROM, RCPT TO, and final DATA
Queue/message identifier returned by the relay
Final delivery event, if the provider exposes webhooks or an events API
Authentication results from a controlled inbox sample

Use a dedicated sender and recipient for monitoring, such as smtp-monitor@example.com to smtp-monitor@your-test-domain.example. Keep the cadence modest and comply with provider limits. The purpose is to detect a broken credential, DNS change, egress firewall change, certificate failure, or sender-policy regression—not to generate mail volume.

For application health checks, distinguish between synthetic SMTP acceptance and business-message delivery. The first confirms that your relay accepts a controlled message. The second confirms that your templates, queues, background workers, unsubscribe logic, sender identity, and event handling still work together.

SMTP relay test checklist

Use this checklist before marking an SMTP integration complete:

Conclusion

The best SMTP relay test is an end-to-end proof, not a port scan. Start by matching the relay’s port and TLS mode, inspect the SMTP conversation, send a controlled authenticated message with Swaks, and verify the received message headers and delivery events.

When it fails, locate the stage: network reachability, TLS, authentication, sender authorization, recipient acceptance, relay queueing, or mailbox delivery. That staged approach prevents the most common mistake in email troubleshooting—treating every failure as an SMTP-password problem when it may be DNS, TLS mode, sender verification, policy, or deliverability.

FAQ

What is the fastest SMTP relay test?

For a quick TLS check, use openssl s_client -starttls smtp -connect HOST:587 -servername HOST. For a real authenticated submission test, use Swaks with the relay hostname, port, TLS mode, authorized sender, controlled recipient, and the authentication mechanism your provider documents. (docs.openssl.org)

Can I test SMTP with telnet?

You can use telnet or netcat for a plaintext SMTP conversation, but they do not provide a robust way to test modern TLS and authenticated submission. OpenSSL is better for manually inspecting TLS, while Swaks is better for repeatable SMTP transactions with authentication. (docs.openssl.org)

Does `250 Queued` mean the email was delivered?

No. It means the SMTP relay accepted the message for processing. Confirm final delivery by checking relay events and a mailbox you control, including spam and quarantine folders.

Should an SMTP relay accept mail without authentication?

Only if it has another intentional authorization control, such as a trusted source IP, private network, or local submission path. A public submission endpoint that relays arbitrary unauthenticated mail is unsafe; test that unauthorized external relay attempts are rejected within your authorized test scope. (rfc-editor.org)

Why does my SMTP test pass but my production emails go to spam?

SMTP acceptance tests transport and authorization, not inbox placement. Inspect received headers for SPF, DKIM, and DMARC, verify the sender domain and reverse DNS where relevant, and review your provider’s delivery events and recipient feedback. Gmail’s sender guidance requires authentication controls and, for qualifying bulk senders, additional requirements including DMARC and TLS. (support.google.com)

SMTP Relay Test: Commands, TLS, Auth & Delivery Guide