An append-only record of who changed what in your workspace, enforced in the database so no one can quietly edit it, including us. It logs every support session email.eu support opens in your workspace, and it records from day one on every plan. A Business feature to read.
Every workspace tool has an answer to "who changed this?" somewhere. Usually it's buried, usually you find out you needed it the week after you needed it. We built ours as a plain, readable log you can open any time: who did what, when, from where. This post is what's in it, what deliberately isn't, and the one entry most tools don't show you.
The audit trail logs the administrative and security actions that change how your workspace is set up or who can get into it. When someone invites a colleague, removes one, or changes their role. When a domain is added, verified or removed. When your plan changes, when single sign-on is configured or its keys are rotated, when a forwarding rule appears, when your branding changes. And the account-security events that matter most: a password reset, an app password created or revoked, encryption at rest switched on or off.
Each entry carries the same few things: who did it, what they did, what it affected, when, and the IP address it came from. The "who" survives the person leaving. If you remove a colleague six months from now, their past entries still read with their name and address, because we store those on the entry itself rather than pointing at an account that no longer exists.
You'll find it under Settings, as a page you page back through in time. Owners and admins can read it. There are no buttons to edit or tidy it, by design, which is the next part.
An audit trail you can quietly edit is not an audit trail. So this one is append-only, and that rule lives in the database itself, not in the application code on top of it. The database rejects any attempt to change or delete an entry once it's written. That holds for your admins, and it holds for us. Nobody clears a line because it's inconvenient.
There's one deliberate exception, and it's worth naming rather than hiding: a future data-retention cleanup, the kind that trims logs older than a set period, is a direct database operation performed on purpose by an administrator, outside the normal running system. Ordinary use, ours included, cannot touch what's there.
Here's the part we care about most. When someone from email.eu opens a support session in your workspace, that action lands in your audit trail like any other, stamped as us and marked with when it started and when it ended. The same goes for the handful of other things our support can do on your behalf, like provisioning a domain or adjusting a billing setting. You don't have to ask us what we did. It's in your own log, next to your team's actions, in the same list.
We think this is the honest version of a promise a lot of companies make loosely. Plenty of providers will tell you they "only access your data when necessary." Fewer will show you, in a record you control and we can't erase, each time they did. That's the difference between trust as a sentence on a page and trust you can check.
It's just as important to say what this log is not, because the wrong assumption here is a privacy problem, not a feature gap.
It is not a record of what your people do inside their mailboxes and files. We don't log who read which email, who opened which document, who joined which call. That surveillance layer is exactly the thing a sovereign workspace shouldn't build, and we didn't. The audit trail is about the administration of the workspace, the settings and access and security decisions, not the day-to-day work happening inside it. Your team's privacy from their own employer's monitoring is a line we hold on purpose.
So if you're looking for per-message read receipts across your company, this isn't that, and we'd gently suggest that what you actually want is a conversation about why.
One practical note. The trail is a Business-plan feature to read, but the recording doesn't wait for the upgrade. We log these actions for every workspace from the day it's created. So when a team moves up to Business, the history is already there, back to the beginning, not starting fresh from the day they upgraded. You're not turning on a camera. You're getting the key to footage that was already being kept for you.
Most small teams will open the audit trail rarely: after a staffing change, during a security review, the first time a new admin wants to understand what the last one did. That's the right amount. It should be quiet infrastructure you're glad exists on the day you need it, not a dashboard you babysit.
The teams who'll live in it are the ones with a reason to: anyone answering to a compliance regime, handling regulated data, or simply operating at a size where "I think Sofie set that up last year" isn't a good enough answer. If that's you, and you want to see exactly how the trail behaves against your own requirements before you commit, talk to us. We'd rather walk you through the real thing than hand you a checklist.