How long should you actually keep email logs? A compliance-driven answer
We've argued before that 7-day log retention is too short to debug real problems. This post is the other half of the answer: how long you're allowed to keep email logs, and how to pick a number that satisfies both your engineers and your DPO. Email log retention compliance comes down to one GDPR principle, storage limitation: personal data is kept no longer than necessary for the purpose you collected it for. The law doesn't hand you a number. It hands you a test, and you have to write the number down yourself.
Email logs are personal data
There's no way around this. A delivery event contains a recipient email address, a timestamp, and an outcome. That's personal data under GDPR even if you never store message content. So every event row you keep needs a purpose, and when the purpose expires, the row has to actually go, not move to a bucket nobody audits.
It helps to separate the data classes, because they justify different windows. Event metadata (delivered, bounced, complained) supports debugging and deliverability. Message content supports customer support disputes, and is the most sensitive class. Suppression entries are the odd one out: keeping a hard-bounced address on the suppression list is itself a compliance and deliverability obligation, so it outlives the event that created it.
Picking a defensible number
The purpose test produces a range, not a point. Debugging a delivery issue rarely needs events older than a support ticket's lifetime; in practice complaints surface up to a few weeks after the send, which is why 7 days fails and why 90 days covers the realistic window with margin. Billing or contractual disputes can justify longer, but usually for aggregates and invoices, not per-recipient event rows. Beyond a year, you should be able to say precisely which obligation forces you to hold recipient-level data, because "it might be useful" is exactly the answer storage limitation forbids.
Whatever number you pick, write it into your record of processing activities and your privacy policy, and make the deletion job real. A stated 90-day policy with a table that still holds two years of events is worse in an audit than an honest 365-day policy that's enforced.
What this looks like in Envello
Envello makes the retention window a setting instead of a plan feature. Every account defaults to 90 days of event logs and can configure anything from 7 to 365 days. The deletion is enforced by retention jobs that actually remove expired data, which means the number in your settings is the number your DPO can put in the processing record. Because the window is yours to set, the same infrastructure serves a startup that wants maximum debugging headroom and a regulated customer whose policy caps event retention at 30 days.
One consequence worth stating plainly: when your window expires, the data is gone, including for us. Support can't recover an event past your configured retention, and that's the point. A provider that can quietly restore "deleted" logs is a provider whose deletion you can't cite in an audit.
The one-paragraph policy
If you need a starting point, this survives most reviews: "Email delivery event metadata is retained for 90 days to support delivery debugging and deliverability monitoring, then deleted. Suppression list entries are retained while the suppression is active. Aggregated, non-personal sending statistics are retained indefinitely." Adjust the number to your actual support patterns, put it in the processing record, and configure your provider to enforce it rather than trusting a calendar reminder.