How to Test an Email Automation Before Going Live

Testing an email automation means proving three things before real contacts see it: that the logic routes each contact down the right branch, that every email renders and personalizes correctly, and that the flow behaves under real conditions — unsubscribes, bounces, duplicate entries. You do this with a small set of test contacts, sandbox or preview sends to your own inboxes, and close monitoring of the first live entries. Skipping any of the three is how automations end up sending a demo link to an enterprise lead or "Hi ," to a customer.

This guide is the pillar of our Testing Automations cluster. It covers the whole process end to end; the supporting articles go deeper on individual pieces like webhook steps and time-based triggers.

What you'll set up and what you need

Before you touch the automation, gather four things:

• A test segment of internal addresses. Three to five inboxes is enough: a Gmail address, an Outlook address, and at least one on a corporate domain. Different providers render and filter differently, and you want to see that difference yourself.
• Test contacts with realistic custom field values. Not empty placeholders — a first name, a plan name, a signup date, a last purchase date. Then add a few deliberately awkward ones: a contact with no first name, one with an accented character (Zoë, Łukasz), one with a very long company name, one with no last purchase date at all.
• A way to trigger entry without touching real contacts. A test signup form, a manual tag applied to a test contact, or a direct webhook call. Whichever you use, it should be the same mechanism the real flow uses, so you are testing the trigger and not a simulation of it.
• Access to the automation's activity log. You cannot verify what you cannot see. Every step — entry, wait completion, condition result, send status — needs to be visible per contact.

You will test in three layers: logic (do test contacts route correctly), rendering and deliverability (do the emails look and behave right in real inboxes), and live monitoring (do the first real entries behave as predicted).

If you build in Mailerflow, you can assemble the workflow visually or describe it in a sentence and let the AI automation builder draft the trigger, waits, conditions and emails for review before activation. That draft-then-review model is useful here precisely because you test what you actually see — the drafted structure is the structure you inspect step by step.

Step-by-step: how to test email automation

1. Freeze the automation

Keep it in draft or paused. If your tool supports duplication, make a test copy so you can shorten waits and swap in test-only settings without touching the production version. Verify: the automation shows as inactive and no real contact can enter it.

2. Build a test segment

Create a dynamic segment that contains only your test contacts. In Mailerflow, a dynamic segment on a tag such as test-automation, or on an internal domain field, works well because it updates automatically as you add testers. Verify: the segment count matches the number of test contacts you added, no more.

3. Add test contacts with messy data

Import or create the awkward contacts described above. The point is not realism for its own sake — it is to force every personalization fallback and every condition edge case to fire now, in front of you, rather than in front of a customer. Verify: each contact's profile shows the field values you intended, including the blanks.

4. Trigger entry manually

Fire the entry event — submit the test form, apply the tag, or send the webhook. Verify: the contact appears in the automation's entry log with the correct timestamp and the correct entry trigger. If it does not appear, stop here; nothing downstream is worth testing until entry works.

5. Walk the first branch

Follow one contact through the flow in the log. Check the wait duration is what you configured, then the condition evaluates as expected, then the email is queued or sent. Verify: the log shows each step in order with a completion time, and the condition result matches the field value you set.

6. Repeat for every branch

This is the step people skip. Walk the "no" path, the fallback path, and the no-match path — every branch a contact could take, including the ones you think are unreachable. Verify: for each branch, you have at least one test contact whose log shows that path taken.

7. Check exit conditions and goal events

If the automation should stop when a contact converts, purchases, or replies, test that. Verify: a contact who meets the exit condition is removed from the flow and does not receive the next email.

8. Send to your test inboxes and inspect

Open each email in Gmail, Outlook, and on a phone. Check rendering, every link, every personalization token, and the unsubscribe and preference links. Verify: links resolve to the intended URL with the intended UTM parameters, and the contact with no first name gets a sensible fallback rather than "Hi ,".

9. Test the failure paths

Deliberately break things: point a webhook step at a wrong URL, feed an AI step an empty input field, unsubscribe a contact mid-flow. Verify: the webhook step reports the failure rather than silently dropping it, the AI step degrades gracefully, and the unsubscribed contact stops receiving immediately.

10. Activate and monitor the first real entries

Turn the automation on and watch the first ten to twenty real contacts. Verify: entry counts match the trigger volume you expect, no contact enters twice, and the branch distribution looks plausible.

A note on long waits. If a wait is three days, do not wait three days. Shorten it in the test copy, run the flow, then restore the real duration before activation. Verify the restored value in the live version — this is an easy thing to forget.

A worked example: a 4-branch onboarding automation

This is an illustrative example, not a customer story.

A B2B SaaS onboarding flow with four branches:

Branch A. Test contact: the one with a blank company size. Expected log: entry, email sent, wait, demo link email. What the test caught: the email opened with "Hi ," because the first-name token had no fallback. Fix: set a fallback value ("Hi there") on the token.

Branch B. Test contact: company size set to 4. Expected log: entry, condition true, first tips email. This branch passed cleanly, which is itself information — you now know the baseline works and any later failure is specific to another branch.

Branch C. Test contact: company size set to 250. Expected log: entry, condition true, webhook delivered, calendar email. What the test caught: the webhook fired for a contact with company size 4 as well, because the condition used "contains" instead of "equals" and matched a substring. Fix: change the operator to "equals" and re-run both contacts. In Mailerflow, signed webhooks with retries and delivery logs are where you confirm the step actually delivered rather than merely fired.

Branch D. Test contact: one who receives emails but never opens. Expected log: entry, wait 5 days, no-open condition true, re-engagement email. What the test caught: nothing in the logic, but the subject line was identical to an earlier email in the sequence. Fix: rewrite it before launch.

Four test contacts, four branches, three real bugs found before a single customer was affected.

How to check it actually worked

Verification is a separate activity from walking the steps. After the run, confirm:

• The activity log per contact shows entry time, each step, wait completion, condition result, and send status — in order, with no gaps.
• Delivery, bounce and complaint status for each email appears in analytics, and a hard bounce is suppressed automatically rather than retried.
• Links resolve to the right URL with the right UTM parameters, checked by clicking, not by reading the HTML.
• Segment membership updates after the flow — a contact who finished onboarding should carry the tag the next automation expects.
• Suppression works. A contact who unsubscribes mid-flow stops receiving; a contact who complains is removed.

Here is an automation testing checklist you can copy:

• [ ] Entry trigger fires once and only once per contact
• [ ] No duplicate entries for the same contact
• [ ] Every branch is reachable and was reached in testing
• [ ] Every wait duration is correct in the live version
• [ ] Every personalization token has a fallback
• [ ] Every link tested by clicking
• [ ] Unsubscribe and preference links present and working
• [ ] Webhook step returns a 2xx and is visible in delivery logs
• [ ] Exit condition removes the contact
• [ ] Test contacts removed or excluded from reporting

Common mistakes and fixes

Testing only the happy path. Symptom: the fallback branch sends something broken in production. Cause: only the main path was walked. Fix: one test contact per branch, every branch, no exceptions.

Using real contacts as test contacts. Symptom: open and click rates look inflated for weeks. Cause: colleagues received the campaign as if they were customers. Fix: internal addresses only, and exclude the test segment from reporting.

A contact entering twice. Symptom: someone gets the welcome sequence two days in a row. Cause: no entry restriction. Fix: add an entry condition or an "already received" check.

Waits too long to test. Symptom: the flow ships untested past step three. Cause: nobody wants to wait a week. Fix: shorten waits in the test copy, restore before activation.

"Contains" where "equals" is needed. Symptom: the wrong branch fires for a subset of contacts. Cause: substring matching on a value like company size or plan name. Fix: switch the operator and re-test the boundary values.

Tokens without fallbacks. Symptom: "Hi ," or an empty product name. Cause: the field is blank for some contacts. Fix: set a fallback on every token.

Timezone mistakes on date triggers. Symptom: a birthday or renewal email arrives a day early or late. Cause: the trigger timezone differs from the contact's. Fix: confirm which timezone the trigger uses and test a contact in a different one.

Conflicts with other automations. Symptom: a contact receives two emails within minutes. Cause: they qualify for two flows at once. Fix: test with a contact already enrolled elsewhere, and add mutual exclusion if needed.

Assuming preview equals inbox. Symptom: layout breaks in Outlook or dark mode. Cause: the preview renderer is not the inbox. Fix: send to real Gmail and Outlook inboxes and check both.

FAQ

How many test contacts do I need? One per branch, plus one or two for edge cases like missing fields. For a four-branch flow, four to six is usually enough.

Can I test an automation without sending real emails? You can verify logic and rendering with previews and internal test sends, but you should always send at least one real email to a real inbox before launch — previews do not reproduce provider rendering or filtering.

How do I test a wait step that lasts several days? Shorten it in a duplicated test version, run the flow, then restore the original duration and confirm the restored value in the live automation.

What happens if a contact enters an automation twice? Depends on your settings. Some tools allow re-entry by default, which can mean duplicate emails. Decide deliberately and test it with the same contact twice.

Should I test with my own domain or a subdomain? Test with the domain you will actually send from, so DKIM, SPF and DMARC behave the same way. Mailerflow's guided setup and automatic verification make this checkable before you send.

Next steps

Once this end-to-end pass is clean, go deeper on the pieces that fail most often. The supporting articles in this cluster cover testing webhook steps and their retries, testing time-based triggers across timezones, reviewing AI-generated email copy before it ships, and reading automation analytics so you can tell a logic problem from a deliverability one.

If you are building the flow itself, the AI automation builder in Mailerflow drafts a workflow from a one-sentence description — trigger, waits, conditions and emails — for you to review before activation. That makes the review step in this guide the natural place to catch logic errors early, while they are still cheap to fix.

What to test next:

• Webhook steps, including failure and retry behavior
• Date-based triggers across at least two timezones
• AI-generated subject lines and body copy against your brand voice
• Analytics after the first week of live entries

Describe this automation in a sentence and Mailerflow drafts the workflow for you to review — start free.