DisasterLab
PlaybooksTransactional email stops arriving
Vendorserious35 minutes to prepare

Transactional email stops arriving

Login links, receipts, alerts, invitations, and account messages are rejected, delayed, or sent to spam.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Restore critical message delivery, protect authentication and purchase flows, and separate application, provider, DNS, reputation, and recipient failures.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Preserve message ID, template, recipient domain, submission response, provider event, bounce code, suppression status, complaint, and delivery timestamps.
  • Check queue depth, webhook health, sending domain, SPF, DKIM, DMARC, return path, IP reputation, quotas, and account status.
  • Classify password resets, verification, receipts, alerts, and marketing separately by customer impact and retry safety.

Decisions that change the response

QuestionAct whenAction
Retry messages?The provider did not accept them or the event is temporary and the message remains useful.Retry with the same business idempotency key; never create duplicate charges or security actions.
Switch provider?A tested route has aligned domains, authentication, suppression policy, templates, and event handling.Move only critical streams and preserve recipient consent and bounce state.

Proof that recovery worked

  • Seed inboxes at major domains receive each critical template and provider events reach your application.
  • Authentication records pass and bounce, complaint, suppression, and unsubscribe handling remains intact.
  • Queued messages are reconciled so expired resets and duplicate receipts are not delivered.

Controls to put in place

  • Monitor submission-to-delivery by message class and recipient domain with independent seed accounts.
  • Separate critical transactional mail from bulk reputation and quotas.
  • Keep a tested alternate recovery channel for login and urgent customer communication.
Tabletop drill

Block provider events and reject one recipient domain in staging. Detect the gap, reconcile message state, switch a critical template to a fallback, and avoid expired retries.

Escalate when

Contact the provider when account standing, reputation, shared IPs, or unexplained suppressions are involved; use security review when resets or verification messages were redirected.

What this means

Customers may be locked out or miss important actions even while the application is healthy. Causes include provider outage, reputation, suppression, DNS authentication, quota, or application failure.

Warning signs

  • Delivered volume drops while sends remain constant.
  • Providers return authentication, reputation, quota, or bounce errors.
  • SPF, DKIM, DMARC, PTR, or sending-domain records fail.
  • Customers request repeated login or verification emails.

Recover now

First 15 minutes

  1. Trace one message from application event through provider response.
  2. Check provider status, suppression, quota, and domain authentication.
  3. Offer a secure non-email recovery path for critical access.
  4. Stop repeated resends that damage reputation or create duplicate links.

Today

  1. Fix application, provider, DNS, reputation, or recipient-specific failure.
  2. Replay only still-valid messages with deduplication and expiry.
  3. Contact receiving-provider escalation only after meeting sender requirements.
  4. Inform affected customers through an independent channel.

Verify recovery

  • Test mail reaches multiple major providers and a controlled domain.
  • SPF, DKIM, and DMARC pass and align.
  • Bounce, delay, complaint, and delivery metrics normalize.
  • Old sensitive links have expired.

Prepare now

Access

  • Provider and DNS access does not depend on one person.

Backups and evidence

  • Message ID, event, provider response, and delivery status are traceable.

Contacts and ownership

  • A secondary customer communication channel is available.

Practice

  • Delivery and secure fallback are tested across major mailbox providers.

Common mistakes

  • Treating provider acceptance as inbox delivery.
  • Resending every queued message after recovery.
  • Changing DMARC directly to reject without staged monitoring.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.