Cancel an Email Campaign Without Assuming Recall
Identify the execution owner and remaining queue before preparing a correction.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 3
Identify the sending system, cancel the supported campaign state and reconcile affected recipients before preparing a correction in Migma.
When cancelling a Migma campaign, first identify its current execution state and the system that owns the send. Cancellation may prevent future work; it does not justify saying that every recipient was protected or that already sent mail was recalled.
Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 14, 2026.
Migma's send guide documents cancellation for scheduled campaigns. We recommend starting in that campaign's controls when Migma owns the schedule. The cited guide does not define a universal cancellation contract for every in-progress state, so an incident record must preserve what the actual system reports.
Establish ownership before clicking twice#
A draft prepared in Migma may later be sent by another platform. Record the creative version, campaign, destination platform, scheduled time and current status. A cancellation in the design system cannot be assumed to stop an independently scheduled destination campaign.
Do not create a replacement campaign while cancellation is still uncertain. That turns one ambiguous queue into two. Assign one operator to the stop action and another, where available, to the evidence record. Avoid having multiple responders repeatedly submit conflicting actions.
Resend's August 18, 2026 Cancel Broadcast API announcement provides a concrete historical example. A scheduled broadcast returns to draft when cancelled; a queued broadcast stops its remaining queue while already sent messages are unaffected. Those are Resend's documented states, not interchangeable Migma status labels. This is evergreen incident guidance, not a new release today.
Use a state-dependent response#
| Observed state | First objective | Evidence needed before the next action |
|---|---|---|
| Scheduled, not started | Prevent scheduled execution | Cancellation acknowledgement and refreshed state |
| Queue running | Stop remaining work where supported | Operator action, response, queue state and timestamp |
| Some messages accepted downstream | Bound the affected population | Recipient-level outcomes and known reporting delay |
| State unavailable or timeout | Resolve whether the stop took effect | Readback or provider confirmation; do not infer success |
| Completed | Assess correction needs | Actual sent content and affected recipients |
These rows are an operational model, not a promise that each vendor offers a matching button. If the platform cannot stop an active send, escalate through its documented support path and record that limitation plainly.
A fictional incident transcript#
At 10:00, an operator notices that a campaign links to the wrong event date. At 10:01, the sending system acknowledges a supported queue cancellation. At 10:05, refreshed records show 1,800 messages already sent, 6,000 prevented, 150 failed before send and 50 still unresolved out of 8,000 queued recipients.
The reconciliation is 1,800 + 6,000 + 150 + 50 = 8,000. The unresolved 50 remain unresolved. They must not be counted as prevented merely because the cancellation request succeeded. Later delivery events may change the classification of sent messages without increasing the number that the queue was allowed to start.
The counts are invented and their sum was checked locally. The example shows why “cancelled” is an incident action, not a complete recipient outcome report.
Decide who needs a correction#
Read the exact email that left the system. A harmless internal campaign name error may need no recipient communication. A wrong event date could require a correction for the affected people. The decision should follow the actual mistake and exposure, not an automatic resend of the entire original list.
Migma's recipient results provide a documented place to inspect individual outcomes for Migma sends. If another platform owns delivery, use its records as well. Preserve report timestamps and avoid claiming that server acceptance proves a person read the message.
Draft any necessary correction in Migma using only confirmed facts: the wrong statement, the correct statement and the action the recipient should take. Keep its audience approval separate from approval of the copy. Never restore unsubscribed or otherwise ineligible recipients to send a marketing correction.
Close the incident with remaining uncertainty visible#
Save the stop request, acknowledgement, final observed state, affected population, correction decision and owner. If a provider cannot resolve a subset, retain that uncertainty in the record and choose a response appropriate to the consequence.
This differs from capacity waiting recovery, where an intended campaign pauses at a limit. Here the objective is to stop an unwanted continuation. No cancellation, provider call, campaign send or inbox recall was tested for this article. Rehearse the state-reading portion with a draft before relying on the runbook during a live mistake.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.