How should senders log deliverability metrics?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
You've just had a deliverability dip. Open rates dropped, complaints ticked up, and you need to figure out what happened. If your logs only say "sent 50,000 emails, 92% delivered" you're going to struggle. That summary tells you something went wrong. It doesn't tell you where.
Good deliverability logging is about capturing enough detail that you can reconstruct the story after the fact.
What to log per send
For every campaign or message stream, you want to capture these fields at minimum:
- Recipient domain or provider bucket (e.g. Gmail, Outlook, Yahoo, others) so you can spot provider-specific issues
- Bounce counts split by type (hard vs. soft) and the actual SMTP error codes returned, not just a bounce flag
- Delivery timestamps so you can see if messages took hours to arrive, which often signals throttling
- Complaint counts from feedback loops, tagged back to the campaign that generated them
- Opens and clicks at the campaign level, and ideally at the segment level too
- Any SMTP rejection messages verbatim, not parsed. The raw error text is what you'll Google when something breaks
The segment-level detail matters more than it looks. If a hard bounce spike hit one specific list segment you imported last month, aggregate logging will hide that entirely. You'd just see an overall bounce rate and have no idea where to start digging.
What granularity actually means in practice
"Log at the right granularity" is advice you'll hear a lot. What it means concretely: you want to be able to filter your data by campaign, by date, by recipient domain, and by event type independently. If those four filters work, you can isolate almost any issue.
For example, if your complaint rate jumps, you should be able to answer these questions within a few minutes: Which campaign triggered it? Which list segment were those recipients from? Which mailbox providers filed the complaints? If your logs can't answer those three questions, they're not granular enough. (This is also why keeping raw compliance-grade logs matters for more than just operations.)
How long to keep it
Most senders keep 90 days of event-level data for day-to-day troubleshooting. Trend analysis and compliance review usually need 12 months of summary data. If you're operating in a regulated space, check your specific requirements, because some jurisdictions set their own retention floors.
Still the practical tension is storage cost versus investigative value. Raw event logs for a high-volume sender get large fast. One reasonable middle ground: keep full event-level data for 90 days, then roll it into daily aggregates for long-term storage. You lose the ability to drill into individual events after 90 days, but you keep your trend data indefinitely at a fraction of the cost.
What most ESPs actually give you
ESPs like Postmark, Twilio SendGrid, and Mailgun expose webhooks for delivery, bounce, complaint, and click events. Pull those into your own data store rather than relying solely on the ESP's dashboard. Dashboards get reset, accounts change, and you may switch ESPs eventually. Your logs should live somewhere you control.
If you want a second set of eyes on how your performance is tracking, our SOS hotline is free and we're happy to look at what you're seeing.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
