A customer says they never received your invoice. Your team sees no obvious bounce message. Before you assume the email landed in spam, run an SMTP connectivity test. It answers a more basic question: can your mail server establish a working connection with the receiving server at all?
SMTP stands for Simple Mail Transfer Protocol. It is the set of rules mail servers use to pass messages between one another. A connectivity test checks whether that conversation can begin, continue securely, and receive the expected server response. The straight answer is that a failed test points to a transport problem, not a content problem.
What an SMTP connectivity test checks
An SMTP connectivity test attempts to reach a mail server through its published mail route and records what happens. A useful test checks the destination's Mail Exchange (MX) record, the server name it returns, the network port, and the server greeting. It may also test encrypted transport.
Most business-to-business mail is delivered through port 25. Your sending mail server connects to the recipient's MX server on that port, identifies itself, and asks whether the recipient address can accept mail. A server that responds with a standard SMTP greeting, often beginning with `220`, is reachable. That does not prove a specific message will reach the inbox, but it confirms the servers can communicate.
When encrypted transport is available, the test may also check Transport Layer Security (TLS). TLS encrypts the connection between mail servers. A TLS test can expose an expired certificate, a name mismatch, unsupported encryption settings, or a connection that drops during negotiation.
Why a connection failure affects more than one email
A connection problem can affect sales follow-ups, appointment notices, password resets, invoices, and client correspondence. The symptoms depend on where the failure occurs.
If your server cannot reach a recipient's mail server, your message may stay in a delivery queue and retry for hours or days. If the recipient's server rejects the connection, your system may generate a delayed-delivery notice or a bounce. If the connection works only intermittently, the issue can feel random to your staff and customers.
This is why it helps to separate connectivity from deliverability. Deliverability asks whether a message is accepted and where it is placed, such as the inbox or spam folder. Connectivity asks whether the sending and receiving systems can exchange mail at the network level. You need both, but they require different fixes.
Common SMTP connectivity test results and the exact next step
The MX record is missing or points to the wrong server
An MX record tells other mail servers where to deliver mail for a domain. If it is missing, malformed, or points to a server name that does not resolve to an Internet Protocol (IP) address, outside servers do not have a dependable route for your email.
The exact fix is to review the domain's DNS records with whoever manages your domain or email service. DNS stands for Domain Name System. It is the public directory that maps domain names to the services behind them. Confirm that the MX record is present, uses the correct priority, and points to a valid mail server hostname.
Port 25 times out or is blocked
A timeout means the test could not establish a connection before the allowed wait period ended. Often, a firewall, internet provider, hosting provider, or receiving server is blocking port 25. Some networks block outbound port 25 to limit abuse, while some mail servers accept connections only from trusted networks.
First, determine whether the block is on your side or the recipient's side. Test more than one well-known recipient domain from the same sending environment. If every connection fails, review your firewall and hosting restrictions. If only one destination fails, the recipient's mail administrator may need to review their inbound firewall or mail gateway settings.
Do not solve this by changing random ports on a production mail server. Port 587 is commonly used for authenticated email submission by people and applications, but it is not a substitute for server-to-server delivery over port 25. The right port depends on what you are testing.
The server responds, then rejects the connection
A server may be reachable but reject your connection with a 4xx or 5xx SMTP response. A 4xx response is usually temporary. Your server should retry later. A 5xx response is generally permanent until something changes.
The response text matters. It may identify a blocked sending IP address, an invalid hostname, too many connection attempts, or a policy restriction. Save the full error message, the time of the test, the source IP address, and the destination server name. Those details give your IT provider or the receiving mail administrator something specific to investigate.
TLS negotiation fails
A TLS failure means both servers reached each other but could not agree on a secure connection. Common causes include outdated server software, disabled encryption protocols, a certificate that has expired, or a certificate name that does not match the server hostname.
The fix depends on which side owns the server. If it is your outbound mail server, update its TLS configuration and certificate. If it is a third-party recipient server, document the failure and test whether the server allows an unencrypted fallback. Do not weaken your own security settings simply to accommodate a single destination without understanding the risk.
MTA-STS, or Mail Transfer Agent Strict Transport Security, can make this more consequential. It allows a receiving domain to publish a policy requiring valid TLS for incoming email. If your server cannot meet that policy, delivery may fail rather than fall back to an unencrypted connection. TLS-RPT, or TLS Reporting, lets domains receive reports about failed TLS connections. These records are useful when you manage a domain's mail security, but they do not replace a direct connectivity test.
Reverse DNS does not match the sending server
Reverse DNS maps an IP address back to a hostname. Many receiving systems expect the sending IP address to have a valid reverse DNS record, also called a PTR record, and for that hostname to align with the server's identity.
A bad reverse DNS setup may not stop every connection, but it can lead to connection rejections or stricter filtering. The exact fix is usually made by the provider that controls the sending IP address, not by editing your normal domain DNS zone. Ask them to set the PTR record to the correct mail server hostname, then confirm that hostname resolves back to the same IP address.
How to run a useful test without creating more confusion
Start with the domain involved in the problem and test its MX route. Record the destination mail server, whether port 25 opens, the greeting returned, and any rejection code. If TLS is offered, record whether the secure handshake succeeds.
Then compare results. Test a second recipient domain. Test from the same email platform or mail server that sent the original message. A test run from your office laptop can be useful, but it may not reflect the network path used by your cloud email provider, copier, customer relationship management system, or website form.
For technical teams, command-line tools can help. A basic connection check may use Telnet or Netcat, while OpenSSL can inspect a TLS session. These tools are diagnostic tools, not a reason to manually send test messages into production. If you are not responsible for the mail server, share the test output with the person who is.
What an SMTP test cannot tell you
A successful connection is good news, but it is only one layer of email health. It cannot prove that your message will arrive in the inbox. A recipient may accept a message and later filter it based on authentication, reputation, message content, or local policy.
That is where SPF, DKIM, and DMARC matter. Sender Policy Framework (SPF) identifies which servers are allowed to send for your domain. DomainKeys Identified Mail (DKIM) adds a cryptographic signature that shows whether a message was altered and connects it to your domain. Domain-based Message Authentication, Reporting, and Conformance (DMARC) tells receiving systems how to handle messages that fail SPF or DKIM alignment.
Brand Indicators for Message Identification (BIMI) is separate from connectivity as well. BIMI can support the display of a verified brand logo in some inboxes, but it depends on stronger authentication and policy requirements. None of these records fixes a blocked port or a failed TLS handshake. They work alongside a healthy SMTP connection.
Use the result to choose the right fix
Treat an SMTP connectivity failure as evidence, not a guess. A timeout calls for network and firewall review. An MX error calls for DNS correction. A TLS error calls for certificate or encryption configuration review. A rejection code calls for the sending or receiving administrator to review the policy named in that response.
If the correction requires changes to DNS, a firewall, a hosted mail server, or reverse DNS, Matano IT can handle the remediation. For a fast view of connectivity alongside your authentication, MX, reputation, and domain records, run MailArrive's free email health check and use the Report Card to prioritize the next fix.