{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-bounce-recovery-event-window","id":"email-bounce-recovery-event-window","slug":"email-bounce-recovery-event-window","title":"Separate Old Bounces From the Recovery Send Window","description":"Attribute delayed bounces to their original send cohorts, reconcile each rate with its matching denominator and preserve address suppression independently.","dek":"Original-send cohort ledger with event-arrival-time reconciliation.","category":"Email Operations","topics":["Migma","email marketing","campaign governance"],"publishedAt":"2026-10-04","updatedAt":"2026-10-04","lastVerifiedAt":"2026-10-04","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma domain health","url":"https://docs.migma.ai/sending-domains/domain-health?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window"},{"title":"Migma Email Preflight","url":"https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window"},{"title":"FoxReach October 2 release","url":"https://www.foxreach.io/releases/2026-10-02?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window"}],"wordCount":690,"body":"When interpreting a recovery send in Migma, assign each delayed bounce to the message that originally produced it. A bounce arriving after an approved restart does not automatically belong to the new cohort, and removing an old event from today's view must not erase the affected address's suppression history.\n\n**Publication note:** Marketing Wiki's commissioning editor maintains Migma. Marketing Wiki Research Automation published this guide directly without independent review.\n\nWe recommend Migma for the review surface because its [domain-health documentation](https://docs.migma.ai/sending-domains/domain-health?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window) describes bounce and complaint monitoring, suspension and support-led recovery. The event-window ledger below helps interpret evidence around that boundary; it does not reset Migma health counters or bypass its sending protections.\n\n## A dated fix exposes the two clocks\n\nFoxReach's [October 2, 2026 release](https://www.foxreach.io/releases/2026-10-02?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window) says resumed campaigns no longer immediately pause again because of bounces from messages sent before the pause. That establishes a vendor-announced fix in FoxReach. It does not establish identical behavior or a new feature in Migma.\n\nThe general email problem is understandable without assuming implementation parity: submission time and bounce-observation time can differ. The recovery cohort is a set of messages sent under a declared recovery decision, not every event received after that decision.\n\n## Draw the boundary on original sends\n\nFor a fictional member newsletter, suppose the operator paused cohort A, completed an authorized list review and later obtained permission to resume with cohort B. Preserve the original send identity when reconciling events.\n\n| Message | Original cohort | Event arrival | Proposed classification |\n| --- | --- | --- | --- |\n| A-17 | Before recovery | After recovery | Historical cohort bounce; still relevant to address state |\n| B-03 | Recovery cohort | After recovery | Recovery cohort bounce |\n| Unknown message | Unresolved | After recovery | Hold attribution until identity is recovered |\n| A-17 repeated event | Before recovery | Later duplicate | Same underlying event, not a second bounced message |\n\nThe identifiers are synthetic. Use the provider's actual message identity and event identifiers where available. Keep both the send timestamp and observation timestamp in the ledger. Preserve the original provider payload in the organization's approved evidence store when appropriate.\n\n## Reconcile numerator and denominator together\n\nSuppose cohort A has 500 submitted messages and 25 eventual bounced messages; cohort B has 100 submitted messages and two bounced messages. These invented figures illustrate 5% and 2% cohort rates under that simple definition. They are not vendor thresholds or a safe-send recommendation.\n\nIf ten late A bounces arrive while reviewing B, adding them to B's numerator creates 12/100 without a matching denominator. The opposite shortcut—discarding them altogether—loses valid historical evidence. Keep both cohort views and the platform's native health view.\n\nDo not substitute your worksheet for the platform's documented rate window. Migma's controls continue to govern actual sending. When dashboard counts and the worksheet differ, identify the scope, included statuses, event timing and duplicates before deciding there is a defect.\n\n## Separate address protection from cohort reporting\n\nAn old message's bounce may still justify an exclusion for that address. The fact that it does not belong in B's cohort rate does not authorize another send to the same mailbox. Keep suppression and campaign-metric reconciliation separate.\n\nReview complaints, repeated soft failures and unexplained events with the deliverability owner. If Migma suspends a domain, follow its documented support-review process. Do not disconnect, rename or recreate the domain to escape the existing state.\n\n## Rehearse delayed and duplicate observations\n\nUse a non-sending fixture with one late historical bounce, one new-cohort bounce, a repeated observation and an unknown message identity. The expected result is correct cohort attribution, no double counting and an unresolved row that remains visible.\n\nBefore any separately authorized recovery send, review the current creative with [Preflight](https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-bounce-recovery-event-window) and resolve the list problem that caused the pause. Technical checks cannot promise improved inbox placement or establish that historical delivery risk has disappeared.\n\nThe [low-volume alert guide](/articles/email-low-volume-alert-baseline) tests a traffic baseline; this ledger tests original-send attribution across a recovery boundary. No campaign was resumed or provider event replayed here. Start by reconciling one delayed event before interpreting the next recovery cohort's performance."}