Happy-path email tests miss the expensive failures
A staging test that confirms “the API returned 200” does not prove what happens when the provider times out after accepting data, returns a 421, sends duplicate webhooks or delivers events out of order. Those are the conditions that create duplicate notifications, lost password resets and retry storms.
Model temporary and permanent states separately
A 4xx-style temporary failure should normally enter a bounded retry path. A 5xx permanent recipient failure usually should not. Your application should make that distinction explicitly rather than treating every send failure as “retry later.” The same principle applies to provider APIs that expose structured error classes instead of raw SMTP.
Test idempotency when delivery state is unknown
Timeouts are dangerous because the sender may not know whether the provider accepted the message before the connection failed. Retrying blindly can produce duplicates. Use stable message identifiers and application-level idempotency so an uncertain network result does not become multiple user-visible emails.
Webhook order is not guaranteed by your business logic
Delivery, bounce and complaint events can be retried or arrive late. Your state machine should tolerate duplicate event IDs and reject an older event from overwriting a newer terminal state unless that transition is explicitly valid. Chaos fixtures make these edge cases reproducible in CI.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.