guides
Email Deployment Guide: Test Campaigns and Application Email
Learn what email deployment means, how to check a campaign or application email before release, and what to do about failed sends, retries and rollback.
Use with your tools
Email deployment usually means sending a finished email campaign to its intended audience. That includes choosing recipients, checking the message, approving it and sending or scheduling it. Campaign Monitor's glossary uses the term for this campaign send.
Application teams also release changes to the systems that send email: a password-reset template, a sender domain, a provider integration or a retry worker. Those changes need an additional check: does the customer still complete the task the email supports?
In both cases, a successful send request is only the start. The message can still bounce, arrive in spam, contain the wrong link or reach the wrong audience. Test the delivered email before the full send, and decide how to stop further messages if something goes wrong.
What changes when you deploy email?
A campaign deployment releases a particular message to a selected group. An application release changes how messages are created or sent over time. The distinction tells you what to test and what you can undo.
| Deployment | Example | The check that matters |
|---|---|---|
| Campaign send | A newsletter scheduled for subscribers | The approved version goes to the correct segment at the intended time |
| Transactional template | A revised password-reset email | The delivered link works for the requesting account and expires as intended |
| Sender or provider change | Moving receipts to a different sending service | Actual messages authenticate and delivery events reach your application |
| Queue or retry change | Replacing an email worker | One event produces the intended message, without duplicate sends |
These changes can fail outside the part of the system you edited. A campaign's segment may update between approval and send time. A template can contain a valid URL that points to staging. A worker can submit the same message twice after losing the response to its first request. Previewing the HTML will not catch any of those errors.
Pre-deployment checklist
Start with the version you intend to send, including its actual sender, recipient selection and links. If someone changes those after approval, repeat the affected checks.
Check the audience and message together
For a campaign, inspect the segment rules and exclusions, then review representative contacts. Check that unsubscribed or suppressed contacts are excluded and that overlapping segments will not receive unintended duplicate copies. Confirm the schedule's timezone and whether the audience is fixed now or recalculated at send time; Mailchimp's scheduling documentation shows why that setting can change the final recipient count.
Send a test using representative personalization data, including a missing first name or other optional field. Open the delivered HTML and plain-text versions. Click the primary link, check that images and attachments load, and verify that reply, unsubscribe and preference links lead to the intended destinations. A preview populated with one complete contact record can conceal a broken fallback.
For application email, trigger the action through a test account. Request a password reset, for example, then follow the delivered link and confirm it changes the password for that account. Also check the expected rejection of an expired or already-used token. The email arriving is one assertion; the application accepting the right action is another.
Check delivery and authentication separately
Send through the provider and sender identity you are validating. Inspect the received message's authentication results, including whether SPF or DKIM passes with the alignment needed for DMARC. A correct-looking DNS record is useful evidence, but it does not show which domain signed a particular message. The email header analyzer helps inspect that received copy.
A provider's delivery event and an inbox-placement result answer different questions. Acceptance by the receiving server does not tell you whether the email went to the inbox or spam. Use inbox placement testing for that check, and treat the tested mailbox results as a sample rather than a promise for every customer.
Repeating these checks becomes awkward when every run shares a personal inbox: old messages can be mistaken for the latest test, and several people may inspect different versions. MailSlurp is an email testing platform with isolated inboxes, APIs for checking received messages, and separate inbox-placement tests. You can give each application test its own address and inspect the message generated by that exact run.
Example email deployment runbook
Suppose you are releasing a revised password-reset email. Keep the current version available, and have someone who can pause the email worker present for the release. The person approving the copy and the person able to stop sends may be different people; both need to know what will change.
- Save the current template and configuration. Record the version being replaced and how the worker selects it. Check whether queued jobs already contain rendered HTML or select a template when they run; this determines whether changing the template affects those jobs.
- Run the flow with a test account. Use an isolated inbox, request one reset and verify the recipient, subject and link. Complete the reset, then check the token cannot be reused. Keep production customer addresses out of the test.
- Release to a small, defined group if your system supports it. Route internal test accounts through the new version first. Confirm that the actual production sender and provider produce the expected email before expanding it.
- Check receipt and completion. Compare event-to-inbox time with the token's lifetime, inspect authentication and check whether the reset completes. If a link expires in ten minutes, an email arriving after that deadline is a failed flow even when the provider reports delivery.
- Expand only while those checks pass. Stop the rollout for a wrong recipient, invalid link or duplicate reset message. Investigate rising bounces or delivery delays against the normal behavior of that workflow before continuing.
A campaign follows the same test-and-approve sequence, but its release unit is the audience and scheduled send. Confirm the final segment and version before scheduling, and check the provider's cancellation window beforehand. Do not assume a send can be paused after it has started.
Sender and auth changes deserve extra caution
A sender migration affects more than one template. Inventory the workflows using the old sender, configure the new provider's required DNS records, and send controlled messages through it before moving traffic. Keep the old sending path available until the new path and its delivery events have been checked.
Inspect both the visible From domain and the domains used for SPF and DKIM. For messages to personal Gmail accounts, Google's sender requirements distinguish requirements for all senders from the additional requirements for bulk senders. Follow the requirements for your traffic rather than assuming one passing authentication check covers everything.
If a migration breaks authentication, use the SPF verification guide or DKIM lookup guide to trace the relevant DNS record. Reversing a DNS edit is not an immediate rollback: cached answers can remain in use until they expire. Verify newly received messages after the change instead of relying on the DNS control panel alone.
Monitoring after release
Watch the whole send path: application events waiting for email, provider submissions, delivery or bounce events, and the customer's resulting action. Record a template or release version with your application's send record so a problem can be traced to the changed messages.
For a password-reset flow, alert on failures such as a growing queue, delivery later than the token's lifetime, or an unexpected rise in invalid-link errors. For a campaign, inspect bounce reasons, complaint reports and the affected recipient segment. Do not choose a universal bounce threshold without considering the audience and its normal behavior; the bounce troubleshooting guide explains how to interpret the responses.
Do not resend just because the request timed out
A timeout can mean you lost the response after the provider accepted the message. Amazon SES explicitly documents that a request can occasionally return an error even though the email was accepted; retrying can send a second copy.
Before submitting again, inspect the provider's activity or events and your application's send record. Correlate them with a stable event identifier or provider-supported tag, including when no message ID came back in the response. Use the provider's documented idempotency feature where available and preserve the same key for the same logical send.
If acceptance remains unknown and the provider offers no reliable deduplication, hold that job for reconciliation instead of automatically switching providers or submitting a fresh copy. An application-side record prevents many duplicate jobs, but by itself cannot prove whether a remote provider accepted a request whose response was lost.
Rollback planning
Rollback can stop future messages or restore a previous template. It cannot reliably retract an email already delivered to another mailbox. Mailchimp's cancellation documentation describes a limited stop-delivery feature for eligible sends and warns that additional recipients may receive the campaign while cancellation takes effect.
When you find a defect, pause new submissions first and identify which messages are queued, accepted or already delivered. Then choose the repair for that state:
- Unsent jobs: correct or discard the affected jobs before resuming. A template rollback may not change HTML that was already stored in the queue.
- Accepted messages: check the provider's cancellation capability and delivery events. Do not enqueue replacement copies while the original delivery is unresolved.
- Delivered messages: fix destinations you control, such as a broken landing page, where appropriate. If a correction email is necessary, target the affected recipients and explain the correction clearly.
After restoring a version or sender, trigger a new test through the repaired path and inspect the result. Before resuming a paused queue, check whether its tokens, offers or scheduled notices are still valid. Releasing yesterday's backlog can create a new problem even when the template is now correct.