The GMass SMTP Test: What a Passing Connection Does Not Prove

An SMTP relay that will not authenticate fails in one of about four ways, and the error message you get back almost never tells you which. GMass publishes a free connection tester at gmass.co/smtp-test that walks the handshake and reports where it broke, and it works for anyone, including people who have never used GMass to send anything.

That tool is genuinely useful and it is also narrower than most people assume. It answers whether your credentials open a connection. It does not answer whether mail sent through that connection reaches an inbox, and conflating the two is how a team spends a week debugging authentication that was never broken.

Everything below is verified against gmass.co, fetched 15 August 2026. We run Email Bison for sending, so this is a documentation read of somebody else's tool rather than an account of running it in production.

What the tester actually checks

The form asks for the details every SMTP connection needs: hostname, port, username, password, a from address and a to address. GMass's own tool page publishes a small comparison table of common relay settings alongside it, naming Sendgrid, Mailgun, SMTP2GO, Sendinblue, JangoSMTP and GMass's own service against ports 25, 2525, 465 and 587 with their respective security modes, which spans automatic, none, SSL and TLS including TLS-when-available.

That table is the most useful part of the page for a first-time configuration, because the single most common cause of a failed relay setup is a port and encryption mismatch rather than a wrong password. Port 465 expects implicit SSL. Port 587 expects STARTTLS. A client configured for one against a server expecting the other produces a timeout or a handshake error that reads like a network problem and is not.

The test itself proceeds in stages, which is what makes the result diagnostic rather than binary. It opens a connection to the host and port, which validates that those two values are right and that nothing between you and the server is blocking the route. It then presents the credentials, which validates the username and password pair separately from the connection. Finally it attempts a send, which validates that the server accepts your message format and, critically, your chosen from address.

1. Step 1Route

   Host and port resolve and accept a connection, so nothing is blocking the path

2. Step 2Encryption

   The security mode matches what the port expects, SSL on 465 or STARTTLS on 587

3. Step 3Authentication

   The username and password pair is accepted, which is a separate failure from the route

4. Step 4Authorisation to send as

   The server accepts this from address on this account, which is the failure people misread as auth

Reading the settings table, and the three values people get wrong

The relay comparison GMass publishes beside the tool is worth a minute even if you never run the test, because it lays out the three values a connection actually depends on and shows how much they vary between providers.

The hostname is the least interesting and the most often mistyped. Every relay publishes its own, they look similar to each other, and a transposed character produces a connection failure that reads like an outage. Copy it from the provider's documentation rather than from a blog post, because relays do move them.

The port carries the encryption assumption, which is why it cannot be chosen independently. Port 587 is the modern submission port and expects STARTTLS, meaning the connection opens in the clear and is upgraded. Port 465 expects implicit SSL, meaning encryption is established before anything else happens. Port 25 exists for server-to-server relay and is blocked outbound on a great many networks and cloud providers, which is why a configuration that works on one machine fails on another with no change to the settings. Port 2525 is a commonly offered alternative when 587 is filtered.

The security mode has to agree with the port, and GMass's table shows the range providers actually use: automatic negotiation, none, SSL, and TLS-when-available. That last option is the one worth avoiding where a stricter setting exists, because opportunistic encryption silently falls back to plaintext when the handshake fails, and a fallback nobody observed is not something you want on authenticated credentials.

The username is very often the full email address rather than a local part, and on several providers it is an API key identifier rather than a person's login at all. That is the value most likely to be wrong on a first attempt, and it produces a clean authentication failure that looks like a password problem.

The fourth stage is the one that gets misdiagnosed

Route, encryption and authentication failures are annoying and unambiguous. The fourth is neither.

A relay can accept your credentials perfectly and then refuse the message because the from address you specified is not one this account is permitted to send as. Providers enforce that differently: some reject at the envelope, some accept and silently rewrite the header, some accept and later mark the message. The symptom a person sees is a send that fails after login succeeded, which reads exactly like an intermittent authentication problem and gets debugged as one.

Running the test with the exact from address you intend to use in production, rather than a convenient one, is what separates those two cases in about thirty seconds. It is the single highest-value habit in this whole area and it costs nothing.

The same applies to the envelope in general. A relay that permits your from address may still rewrite the return path to one of its own, which is normal and expected on shared infrastructure, and which matters because bounce processing and some authentication checks key on that value rather than on the visible sender. Envelope sender covers the distinction, and it is worth understanding before interpreting a bounce report from a relay you have just adopted.

One further habit is worth building while the test tool is open. Run it once from the machine or container that will actually send in production, not only from a laptop. Outbound port filtering is enforced by networks rather than by servers, so a configuration that authenticates cleanly from an office connection can fail entirely from a cloud host where the port is blocked. That failure looks identical to a credential problem in most application logs, and it is the sort of thing that consumes a day if it is discovered after deployment rather than before.

What a passing test does not prove

This is where the tool's boundary matters, because a green result is genuinely reassuring about the wrong thing.

A successful connection test proves your client can hand a message to a server. It says nothing about authentication of the message itself, which is a different layer entirely. SPF alignment, DKIM signing and the DMARC policy on your domain are evaluated by the receiving side, not by the relay you just connected to. A relay will happily accept mail that every recipient's DMARC check will subsequently fail.

It also says nothing about placement. Whether a delivered message lands in the inbox, the promotions tab or the spam folder is decided by the receiving provider on evidence the relay never sees: your sending domain history, your sender reputation, recipient engagement, complaint rates and content signals. Those are the questions the GMass inbox placement tester is built for, and the two tools answering two different questions is the reason both exist.

The order that saves time is worth stating explicitly, because teams routinely run it backwards. Confirm the connection works. Confirm the domain's authentication records are correct and aligned. Only then investigate placement. Debugging placement while a DKIM record is malformed is a guaranteed waste of a week, and the cold email deliverability guide covers that sequence in full.

Connection testgmass.co/smtp-test and similar

• Host, port and encryption are correct
• Credentials are accepted
• This account may send as this address
• Proves nothing about deliverability
• Free and takes under a minute

Authentication checkSPF, DKIM, DMARC on your domain

• Records exist and parse correctly
• Signing aligns with the sending domain
• Policy is what you think it is
• Evaluated by the recipient, not the relay
• Must be right before placement is worth testing

Placement testSeeded inbox testers

• Where a specific message actually landed
• Inbox, promotions or spam, per provider
• Depends on reputation and content together
• Meaningless while the two checks left of it fail
• Only useful on a message you would really send

Using a relay to exceed a mailbox provider's limits

The reason most people reach for an SMTP relay in a sending context is capacity, and GMass is explicit about this: it markets its SMTP integration as a way to send beyond what Gmail alone permits, by routing through a third-party service.

Worth being clear about what that changes and what it does not. Routing through a relay moves the sending infrastructure, so the provider-level daily cap on a Google Workspace mailbox stops being the binding constraint. It does not move the reputation. Recipients still evaluate the domain in the from address, the authentication alignment on that domain, and the engagement history attached to it. Volume that a mailbox provider would have throttled is volume that recipients can still mark as unwanted, and the relay simply removes the safety rail that was slowing you down.

The architecture that actually holds at volume spreads sending across many mailboxes each behaving conservatively, rather than pushing one identity harder through a bigger pipe. Mailbox providers respond to per-mailbox volume and per-mailbox behaviour, which is why cold email infrastructure treats the mailbox count as the primary lever and the relay as an implementation detail.

Our own practice sits on that side of the line. We run Email Bison across a rotation of mailboxes with conservative per-mailbox volume, one message per campaign, no bumps and no thread replies. A second contact is a new campaign with a genuinely different angle rather than another step under the first, which keeps per-mailbox volume low for reasons that have nothing to do with what any relay would permit.

If the underlying question is how much sending capacity a programme actually needs rather than how to unlock more of it, see what a first campaign looks like.

Features verified as of August 2026. Verify current terms with the vendor before relying on them.