Test Modes (Safe Sending)

Last updated July 7, 2026

Super Speedy Emails has three top-level send modes. Switching between them takes effect immediately, applies to every send the system makes (campaigns, automations, newsletter, confirmations — everything), and is recorded on every log row so you can see in reports which mode each message was sent in.

Use these to develop, test, and rehearse without actually sending real email.

Table of Contents

The three modes
The admin banner
What gets recorded
Switching back to live: the safety story
The CLI shortcut for tests
Suggested workflow
Related

The three modes

Set under SSE Emails > Settings > Sending > Mode:

Live

Real emails go out. Default mode in production.

Log-only

The send pipeline runs end-to-end except the wp_mail() call itself. Every step that would happen still happens:

Audience resolution
Suppression checks
Queue enqueue and drain
Per-recipient log row creation
Merge tag resolution
Webhook subscription tracking

…but no message is actually sent. Each sse_email_log row records test_mode = log_only and status = sent for accounting (the send succeeded as far as SSE is concerned).

This is the mode the automated test suite uses. It’s also the mode you’d use to:

Rehearse a big newsletter blast and confirm the audience count, suppression mask, and merge tags look right
Develop new automations without spamming yourself with placeholder content
Migrate from MailPoet/MailerLite and run a dry sanity-send before going live

Redirect

Every message is sent for real via wp_mail() — but to a single configured email address instead of the real recipient. The original recipient is still recorded on the log row, but the To: header is rewritten.

Set the destination address in SSE Emails > Settings > Sending > Redirect recipient. Leave it blank to fall back to live (no redirect).

Use redirect mode for:

Testing the actual MailGun delivery path end-to-end
Seeing what an email looks like in your inbox (rendering, link tracking, From address)
QA-ing automations: every step in a 7-day drip lands in your inbox while you’re testing, instead of being lost into the void

The redirect happens inside SSE’s sender (SSE_Sender::send()) — it rewrites the recipient to your test address just before the wp_mail() call (the original recipient is preserved on the log row), so the rest of the pipeline behaves like a normal send.

The admin banner

When SSE is not in Live mode, an orange banner appears at the top of every WP admin page:

⚠️ SSE is in test mode (log_only) — no real emails will be sent. Switch to live mode under Settings.

This exists because the easiest way to lose money / brand trust is to forget you switched to test mode and assume your scheduled newsletter went out. The banner is intentionally hard to ignore.

If you don’t see the banner, you’re in live mode. If you see it, double-check before sending anything important.

What gets recorded

Every log row carries a test_mode column with one of three values:

live — real send
log_only — pipeline ran, no wp_mail call
redirect — sent, but the recipient was rewritten

Reports can be filtered by this column. Pre-launch verification:

wp db query "
  SELECT test_mode, status, COUNT(*)
  FROM wp_sse_email_log
  GROUP BY test_mode, status
"

This shows you which modes you’ve been running in and how many sends each accounts for. Right before going live, you’d expect to see log_only rows from your testing and zero live rows yet.

Switching back to live: the safety story

Switching from log_only to live is one option-change. No re-deploy needed.

There is no automatic dedup between a log_only rehearsal and a subsequent live send. If you compose a campaign, send it in log_only mode, then switch to live and click send again on the same campaign, the same recipients get one real email — because they got zero emails the first time (log_only).

💡 Where this gets tricky: if you reset a sent campaign to draft and re-send, recipients get two emails. The first send was real (whatever mode it was in). See Sending Campaigns for the status guard and reset-to-draft semantics.

The Status Guard prevents accidental double-sends from a single campaign row. It does not prevent you from creating a new campaign that targets the same audience.

The CLI shortcut for tests

The test suite needs SSE to be in log_only mode. Running tests against a live install would actually send fake mail to fake addresses, which is exactly what you don’t want.

The test runner (/.tests/run-tests.sh) takes a --auto-mode flag that:

Reads the current sse_test_mode option
Switches to log_only for the duration
Runs the tests
Restores the original mode at the end

This is so you can keep your production site in live mode but still run tests from the shell occasionally.

The bootstrap will refuse to run if sse_test_mode = live and --auto-mode was not passed — it errors out with bootstrap: sse_test_mode is 'live' — refusing to run tests.

Suggested workflow

Practical sequence for going live with a new feature:

Develop in log_only. Build the campaign / automation / list. Verify audience counts and merge tags using the queue + log tables.
Switch to redirect mode, with the destination set to your own email. Send the campaign. Check the email in your inbox: subject, body, From, links, unsubscribe footer.
Switch to live. Verify the banner is gone. Send a fresh test broadcast to yourself only (via the Send test to me button on the campaign editor). Confirm it arrives at your real address.
Send to the real audience.

Each step takes 10 seconds. The whole sequence is ~5 minutes. It’s worth doing every time, because the alternative (sending to thousands of people with a broken link, wrong From: address, or unresolved merge tag) is much more expensive.

MailGun Setup — how live mode reaches your mail provider
Sending Campaigns — the send-to-self test button and reset-to-draft
Tracking & Reporting — filtering reports by test_mode