What an email sending audit trail should record

A message log is not an audit trail#

Google Workspace, Microsoft 365 and most sending services keep a message log or trace: which message left which server, when, and the response the next server gave. That answers "did it leave?". It does not answer the questions people actually ask after an incident:

• Who prepared this message, and on whose behalf?
• Was it reviewed, by whom, and was what they approved the same as what was sent?
• Which rule allowed it to go without review?
• Who changed that rule, and when?

An audit trail records the decisions around a send, alongside the transport facts. If approvals are part of how you send, design them so each one names the exact version it covered; if AI agents send for you, the trail also has to say which agent acted and for whom (see AI email governance).

The fields to capture#

Accepted is not delivered#

When a mail server or sending API accepts a message, it has taken responsibility for it (in SMTP, the receiving server's 250 reply). That is all. The message can still bounce later, land in spam, or be held by the recipient's filters. Some providers report later events such as bounces or deliveries back through webhooks or delivery status notifications; many report nothing.

An honest audit trail records exactly what was known: "accepted by the provider at 10:42", and later events only if the provider reported them. Image-based open tracking is an estimate at best, because mail apps differ in whether and how they load images. Do not let a dashboard turn "accepted" into "delivered", or a pixel load into "read".

What to leave out#

More people look at an audit trail than at the mail itself, and it is kept longer. Keep it to metadata unless you have a specific reason to keep content:

• Store message bodies in the mail system, not in the audit log.
• Mask sensitive values in findings: "a payment card number ending in 1111", not the number.
• Never log passwords, tokens or keys, even in error messages.

Make it trustworthy#

A record that its subject can edit proves little. Make the trail tamper-evident:

• Append-only: entries are added, never changed or deleted, enforced by the system rather than by convention.
• Verifiable exports: seal each export with a hash and a signature so anyone holding the file can check it was not altered.
• A second copy: stream events to a separate system, such as your SIEM, run by different people.
• Deliberate retention: keep entries as long as your legal, contractual and investigation needs require, and no longer, because logs contain personal data too.

A quick checklist#

• Every send names its actor: person, agent and owner, workflow, or API key
• Approvals record the exact version approved, the approver and the time
• Policy and permission changes are logged with who, when, IP address and browser
• Provider responses are stored as accepted, refused or failed, never as delivered
• Message bodies stay out of the audit log; sensitive findings are masked
• The log is append-only and exports can be verified offline
• Events are copied to a second system
• Retention is written down and applied

How SecureThread does it#

SecureThread keeps an append-only audit log of security-relevant actions, with the IP address and browser user agent, for 365 days by default. Exports of up to 100,000 events are sealed with a SHA-256 hash and an Ed25519 signature that anyone can check offline, and events can be streamed to a SIEM's HTTPS collector. Each AI agent has an activity list of its requests, outcomes and refusals that shows message details, never message bodies. Sending history says accepted where a provider accepted a message and never calls it delivered; read how it reports sending figures.