What an email security log is for
- Understanding a decision. A customer complains that a message never arrived: the log says whether it was rejected, quarantined or delivered, and for what reason.
- Proving that a message was stopped. After a fraud attempt, the company can show that the message was blocked and when.
- Investigating after an incident. Who in the company received the same campaign? Since when has this lookalike domain been writing?
- Feeding a SIEM. A security monitoring tool cross-references the filter’s decisions with sign-ins, workstations and the network.
Filtering log. The record of the filter’s decisions: date, sender domain, score, reason, decision. It is not a copy of the mail. Retaining the messages themselves is the job of the email service and, if needed, of legal archiving.
What a decision contains
In Klytic MTA, every decision is explained. The score and reason appear in the headers of the delivered message, under Klytic-specific names: X-KlyticMTA-Status for the decision, X-KlyticMTA-Score for the score, X-KlyticMTA-Reason for the reason. An administrator can therefore read, on the message itself, why it was delivered. This is true in both plans.
The Advanced plan adds logs presented as compliant with the CIS and NIST frameworks, exportable to your SIEM. The difference between the two plans is therefore clear:
- Essential: the decision is explained, message by message, in the headers.
- Advanced: the decisions also form a log you can send to your own tool, to retain it and cross-reference it with other sources.
Day-to-day reading of these decisions is described in Reading and exporting a filter decision.
Two clocks not to confuse
The filter’s technical clock
It is known and set by the product. For Klytic MTA:
| Data | Duration |
|---|
| Sender, recipients, subject, body, attachment names, after normal delivery | Purged after 2 days by default; adjustable period |
| Timestamp, sender domain, scores, decision, analysis metadata | Retained after the purge |
| Dangerous message in quarantine | Complete and encrypted for the validity of the release link, 7 days |
| Queued message (mailbox server unreachable) | Encrypted until delivery or until the delay expires |
The practical consequence: a month after the events, the filter knows that a message from a given domain was quarantined, with what score and what reason. It no longer knows who sent it to whom, or what it said. If an audit is looking for the content, it must look in the mailbox or in the archive.
Beware of a common confusion: the 30-day backup announced for Klytic Mail mailboxes concerns the mailboxes, not the gateway logs. These are two services and two durations.
The clock chosen by the company
It depends on the purpose. No text sets a single retention period for an email filtering log. The framework is that of the GDPR: data is kept for as long as the purpose justifies it, and this is documented.
A useful benchmark: for logging access to and operations on personal data processing, the CNIL recommends a period of between six months and one year, longer in certain justified cases. This recommendation is not prescriptive, and it applies primarily to access logs, not to a filtering log. It also points out that logs should not retain data beyond the period set for the data itself.
In practice, the long retention period applies to the export, in your SIEM: that is where you set retention, access and deletion. The filter itself keeps little.
Example: three months after a fraud attempt
A hypothetical case. In January, several employees of a company receive a fake message from their CEO. In April, the insurer asks what happened. What can be shown?
- In the filter: the date, the lookalike domain that wrote, the score, the reason (lookalike domain, display-name spoofing) and the quarantine decision for each message. No longer the recipients’ addresses or the text, purged long ago.
- In the SIEM, if the company has the Advanced plan and retains the export longer: the same log, with whatever the company’s policy chose to keep, cross-referenced with sign-ins at the time.
- In the mailboxes: nothing, since the messages were stopped beforehand.
The proof therefore rests on the decision, not on the content. If the company wants to keep more, that decision must be made before the incident, by setting the export’s retention period.
Who has access to the logs
- The Klytic MTA administrator reads the decisions for their domains, and receives the export to the SIEM with the Advanced plan.
- The user sees their own quarantine, through the link they receive, whether or not they have a Klytic mailbox: see Quarantine, false positives and reporting.
- In your SIEM, your own access rules apply: limit reading to the people in charge of security.
A security log itself contains personal data, if only domains and times: it must be protected and purged accordingly.
Best practices
- Write down the purpose: diagnosis, proof, investigation, monitoring.
- Set the export’s retention period accordingly, and enter it in the record of processing activities.
- Restrict access and log who consults the logs themselves.
- Do not turn the log into a mail archive: keep the metadata, not the message bodies.
- Test a real search: find the decision made on a message from three months ago.
Phone recordings follow a different logic and different retention periods: see how long to keep recordings.
Frequently asked questions
Can you find the content of a message filtered a month ago?
Not in the filter, if it was delivered: the content is purged after the short period. Look for it in the mailbox or in the archive.
How long should logs be kept?
It depends on the purpose, which must be documented. The CNIL recommendation on logging gives an order of magnitude of six months to one year.
Is export to a SIEM included in Essential?
No, it is part of Advanced. Essential explains each decision in the headers.
Do I need Klytic Mail to have these logs?
No. They are produced by Klytic MTA, whatever email service sits behind it.
Where Klytic stands
Klytic MTA explains each decision with a score and a reason in the headers, in Essential as in Advanced. Advanced adds logs exportable to your SIEM and the DMARC console.
Technical retention is limited: no long-term retention of the delivered message, purge of personal analysis details after 2 days by default, dangerous message kept encrypted for the lifetime of the release link, encrypted queue. Long-term retention, if you need it, takes place in your own tool, from the export.
The service is available without Klytic Mail. It can be deployed in the Klytic cloud, on a dedicated instance or on your servers.
This page describes a general framework. The retention period applicable to your organization depends on your purposes and, where applicable, on sector-specific obligations.
Legal status as of October 11, 2026. No text consulted sets a retention period specific to email filtering logs. The CNIL recommendation of November 18, 2021 on logging is not prescriptive.
Sources
Consulted in October 2026.
- CNIL, “La CNIL publie une recommandation relative aux mesures de journalisation” (The CNIL publishes a recommendation on logging measures, November 18, 2021): recommended retention period of six months to one year for logging access to a processing operation, possible extensions if justified, non-prescriptive recommendation. cnil.fr
- Klytic, Klytic MTA page: decision explained in the headers (Essential and Advanced), CIS / NIST logs exportable to a SIEM (Advanced), modules in the Essential and Advanced plans, options, deployment modes, activation via the MX record. klytic.com
