Delivery evidence
Trace the message from product event to recipient outcome
Separate product generation, provider acceptance, authentication, mailbox placement and user action; each stage needs different evidence.
Domain identity
Authenticate the sending domain and align visible identity.
- Check
- SPF, DKIM, DMARC, DNS and TLS
- Failure
- Provider signs with an unrelated domain
- Evidence
- Delivered header and provider diagnostics
Message stream
Separate transactional, support and promotional behavior.
- Check
- Purpose, From identity and expected volume
- Failure
- Marketing complaints affect password-reset traffic
- Evidence
- Stream-specific reputation and ownership
Content and consent
Send what the recipient expects with truthful identity and choices.
- Check
- Trigger, disclosure, unsubscribe and accessibility
- Failure
- Generated urgency or hidden unsubscribe
- Evidence
- Rendered message and consent record
Bounce and complaint
Stop harmful retries and keep account state understandable.
- Check
- Hard bounce, soft bounce, complaint and suppression
- Failure
- Invalid address is retried indefinitely
- Evidence
- Provider event and suppression test
User recovery
Do not make email the only invisible route back into the product.
- Check
- Resend, address correction, support and expiry
- Failure
- User cannot distinguish delay from invalid request
- Evidence
- Timed end-to-end mailbox tests
Operating principle
Measure delivery by message purpose, not one global rate
A receipt, magic link and newsletter have different urgency, consent and recovery expectations. Combining them hides whether the product’s most critical messages work.
Define success and terminal failure for each stream. Monitor authentication, provider rejection, bounce, complaint and user-visible completion while keeping personal data out of unnecessary telemetry.
- Authenticate every sending domain
- Separate critical streams
- Honor suppression and unsubscribe
- Test real mailbox journeys
Applied example
Failure example: magic links share a campaign stream
Login links and promotional messages use the same sender configuration. A campaign generates complaints, and mailbox providers begin delaying authentication messages.
- The application still reports provider acceptance
- Critical and optional streams share reputation
- Users retry and create more messages
- A non-email recovery path is missing
Plain answers
Questions to resolve before shipping
Does a 200 response from the email API mean delivered?+
No. It usually confirms provider acceptance. Authentication, routing, mailbox filtering, bounce and user access remain separate stages.
Should we publish SPF, DKIM and DMARC?+
Follow current receiver and provider requirements for your sender profile. Domain authentication is a foundational deliverability and anti-spoofing control.
Can we log full message content for debugging?+
Minimize sensitive content. Prefer message IDs, categories and provider diagnostics with access and retention appropriate to the data.