---
title: "Testing your email setup - Workflow Transactional Email"
description: "What Test Connection actually checks, how to send a test email, where to confirm a send really happened, and what to do when a test email never arrives."
canonical: "https://docs.workflow-transactional-email.app/testing-your-email-setup"
---

# Testing your email setup

There are two different test buttons in the app and they check very different things. Knowing which is which saves a lot of guessing when an email does not turn up.

> [!WARNING]
> **Test Connection does not send anything**
> **Test Connection** opens a connection to your SMTP server, logs in with your username and password, and hangs up. That is all.
>
> A green result tells you three things: the hostname resolves, the port and encryption are right, and your credentials are accepted. It tells you **nothing** about whether a message will actually be delivered - no email is sent, so nothing can arrive.
>
> A server can pass Test Connection and still refuse, delay, or silently drop the mail you send through it.

## The two tests, side by side

| | Test Connection | Send test email |
| --- | --- | --- |
| Where | Email sender settings | Email layout editor |
| What it does | Logs in and disconnects | Renders your layout and sends a real message |
| Proves | Host, port, encryption and credentials are right | The server accepted the message for delivery |
| Recorded in History | No | **No** - see below |
| An email arrives | No | Yes, if all is well |

## Sending a test email

Open an email layout and use **Send test email**. It renders the layout exactly as a live send would, with your test variables, and sends it through the sender you pick.

If the server rejects it, the error appears on screen immediately. That message comes straight from your mail server and is the single most useful thing to send us if you get stuck.

> [!NOTE]
> **Test emails do not appear in History**
> This is the honest answer to "how can I tell it is being sent?"
>
> **History records sends triggered by Shopify Flow.** A test email is not a workflow run, so it is not written to History. If you send a test and then look in History for it, you will find nothing - and that absence does not mean the test failed.
>
> So when testing, judge the result by:
>
> 1. **The message on screen** right after you press the button. An error there means the server refused it.
> 2. **Whether the email arrives**, including the spam folder.
>
> To confirm the whole path end to end, including History, trigger the actual workflow in Shopify Flow once. That send **is** recorded, with its request, response, duration and any error.

## A test email that never arrives

If the app reported success but nothing landed, the message left us and your mail server accepted it. Work through these in order:

1. **Check the spam or junk folder**, and any quarantine your provider runs. This is by far the most common answer, especially for a first send from a new setup. See [Email deliverability](https://docs.workflow-transactional-email.app/email-deliverability.md).
2. **Check the from-address matches the account you authenticated with.** Many servers accept the login, then silently discard or reject a message claiming to be from a different address.
3. **Wait a few minutes.** Some servers greylist an unfamiliar sender, deliberately delaying the first message from a new source.
4. **Try a different recipient**, ideally on another provider. If it arrives at one address and not another, the problem is on the receiving side, not yours.
5. **Check your server's own outbound log.** Your host can see whether the message was accepted and what happened to it after we handed it over - we can only see the response we got.

## What the common errors mean

These come from your mail server, not from us.

| Message | What it usually means |
| --- | --- |
| `Connection timeout` | We could not reach the host at all on that port. Check the hostname and port, and that the server accepts connections from outside your own network. |
| `wrong version number` | The port and encryption do not match. Port **465** expects SSL; port **587** expects STARTTLS. Getting these the wrong way round produces exactly this error. It can also appear intermittently if the server refuses extra simultaneous connections. |
| `Invalid login` / `535` | The username or password was rejected. If your provider uses two-factor authentication you usually need an app-specific password rather than your normal one. |
| `554` / `all recipients were rejected` | The server accepted your login but refused the recipient or the from-address. |

## When sends work sometimes but not always

If History shows a mix of successes and failures on the same sender, and the failures cluster at moments when several emails go out at once, your mail server is most likely limiting how many connections it accepts at the same time. Shared and small-business hosting often allows only a handful.

Two things help:

- **Try port 587 with STARTTLS** instead of 465 with SSL. Servers frequently handle concurrency better on 587.
- **Ask your mail host what the concurrent connection and hourly sending limits are** on your account, and whether they can raise them.

A send that takes ten seconds or more is also a sign the server is working hard. That is not a problem on its own, but it leaves less headroom when several messages go out together.

## Related

- [Email deliverability](https://docs.workflow-transactional-email.app/email-deliverability.md) - why a successful send can still land in spam.
- [History and troubleshooting](https://docs.workflow-transactional-email.app/history-and-troubleshooting.md) - reading a real send's request, response and error.
- [Send email from Shopify Flow with a custom SMTP server](https://docs.workflow-transactional-email.app/send-email-with-smtp.md) - host, port and encryption settings in full.