What a Mail Server Logs – and for How Long

A deleted email is gone. The record that it was delivered is not. Every message leaves several lines in a log file on every server it touches — and those have a lifetime of their own, unrelated to the message.

What one such line contains

The full set per message

A single delivery usually produces three to five lines connected by a shared queue identifier. Taken together they contain:

The message text is not among them on an ordinarily configured server. It would sit badly there in any case: logs are read for troubleshooting, often by people who are not permitted to read the mail.

The subject line is a borderline case. It is not logged by default but can be switched on, and some spam filters do it of their own accord, because they are not auditable without it. Anyone taking over a system should therefore check rather than assume.

Both sides log the same transaction

This is regularly overlooked: a delivery produces entries on both servers. The sending one records that it delivered; the receiving one that it accepted. Both operators thereby record that a message of a certain size passed between two addresses at a certain time.

Add intermediate stations — a spam filter, a forwarder, a sending provider — and each of them records the same thing again. To the sender this is neither visible nor controllable.

Here too: transport encryption changes nothing about it. TLS protects the contents of the connection, not the fact that it took place — the server accepting the message decrypts it, after all. What the various mechanisms are each good for is covered elsewhere.

How long this is kept

There is no fixed answer, but there is a settled range. Two requirements pull in different directions.

Operations need the data briefly. Most questions a log answers arrive within a few days: "did my mail from yesterday get through?" For tracking down recurring delivery problems, two to four weeks is usual.

Data protection law requires a limit. IP addresses and email addresses are personal data. They may be processed for a defined purpose — operating and securing the service is one — and must be erased once that purpose is served. Unlimited retention "just in case" is not an admissible justification.

In practice this comes out at 7 to 30 days, with a longer period only for separately justified cases such as records of repelled attacks. What matters is less the exact number than that one exists, that it is documented, and that the deletion actually runs.

What this means for the sender

• Deleting only affects the content. Removing a message from the mailbox does not remove the note that it arrived. That sits in a file no user has access to.
• The connection data regularly outlives the message. With short-lived mailboxes the message is gone in days; the log line can stand for longer.
• To find out what is stored, read the privacy notice. A decent provider names categories and periods there. A missing statement is itself a piece of information.

And for the operator

1. Set a retention period and enforce it technically. A rotation that genuinely deletes files after n days rather than merely renaming them — otherwise the data is still there, just with a number in the filename.
2. Do not log more than necessary. Subject lines and headers in the clear are rarely required and turn an operational file into an extract of the correspondence.
3. Restrict access. Whoever is chasing a fault needs the log. Whoever is not, does not.
4. Document the periods, in the record of processing activities and in the privacy notice. That is the work you postpone at setup and regret at the first subject access request.

A log is an operational tool, not an archive. The difference shows in whether somebody set a period — or whether the files simply keep growing.