Administration

Audit log

The audit log is the record of who has signed in to the mailboxes on your domains, when, from where, and whether they succeeded. It is the first place to look when an account behaves oddly, and the quickest way to tell a forgotten password apart from somebody guessing one.

Sign-ins only

This log covers authentication, not everything that happens in the workspace. Creating a mailbox, changing a plan or deleting a message are not recorded here.

What the audit log records

Every successful sign-in to a mailbox on a domain you administer.
Every failed attempt, together with the reason it failed.
Which route was used — an email address and password, or single sign-on from the wider NevTan suite.
Where it came from — the IP address, and the browser or mail app that made the attempt.
Newest first, so the most recent activity is always at the top.

What you can see depends on your role:

Admins see attempts against mailboxes on their own domains, and nothing beyond them.
Super admins see every domain on the platform, with an extra Domain column to tell them apart.
An admin with no domain yet sees an empty table — there is nothing to record until mailboxes exist.

Open the audit log

Go to the admin area: Sign in as an admin and open the administration screens. See Admin overview & roles if you are not sure whether you have access.
Choose Audit Log: It sits in the admin sidebar, below Payment History.
Read from the top: The newest attempts load first, 25 at a time. Use the controls at the foot of the table to move through the pages or show 50 or 100 at once.

What each column shows

Column	What it shows
When	The date and time of the attempt, in your own time zone rather than the server's.
Account	The address the attempt was made against — including addresses that do not exist, where somebody guessed one.
Domain	Which domain the mailbox belongs to. Shown to super admins only, since an admin is already looking at their own.
Role	Whether the account is a user or an admin.
Result	Success or Failed. Resting on a Failed marker shows why it failed.
Method	Password, or SSO for a sign-in carried over from another NevTan app.
IP address	The address the attempt came from, which is what identifies an unfamiliar location.
Device	The browser or mail app that made the attempt, shortened to fit. Rest on it to read the full description.

Four reasons appear against a failed attempt:

Incorrect password — the address was right and the password was not.
Account is inactive — the mailbox exists but has been switched off, so the sign-in was refused regardless of the password.
Email not verified — the account was created but its address has never been confirmed, so it cannot sign in yet.
Locked after repeated failed attempts — five wrong passwords inside fifteen minutes, after which sign-in is refused for that account until the fifteen minutes are up.

A single lockout fills several rows

Every attempt made while an account is locked is recorded too, so one person locking themselves out and retrying shows up as a run of Locked after repeated failed attempts entries rather than a single one. Count the Incorrect password rows before it to see how the lock was reached.

Finding a particular sign-in

Search by address or IP. The box accepts either, and matches part of one — typing priya finds every attempt against an address containing it.
Filter by result to show only successful or only failed attempts. Failures alone are the useful view when you are looking for trouble.
Filter by method to separate password sign-ins from SSO.
Combine them. The filters narrow each other, so failed password attempts for one address is a single query.
Show more rows at once — 25, 50 or 100 per page, from the control under the table.

Dev login in the method list

The method filter also offers Dev login. It belongs to local development builds and never reaches a live workspace, so it will not match anything in your log.

Looking into a suspicious sign-in

A few patterns are worth recognising:

Repeated failures against one address, especially from a single IP, suggest somebody working through passwords rather than a colleague mistyping theirs.
Failures spread across many addresses from the same IP suggest guessing at which mailboxes exist.
A success from an unfamiliar address or location is the one that matters most. Check with the person before assuming the worst — travel and mobile networks both move an IP around.
Attempts against an inactive account mean somebody still has credentials for a mailbox you have switched off.
A run of lockouts is the protection doing its job — guessing stops at five attempts per quarter of an hour. It still tells you the account is being targeted, and the person who owns it is locked out meanwhile.

If an account does look compromised:

Change the password: Reset it from Create & manage mailboxes. The person is asked to choose a new one of their own at their next sign-in.
Switch the mailbox off if you need time: An inactive mailbox refuses every sign-in, whatever the password, and the refusals keep being recorded here.
Check what else held access: A password change does not stop an API key that was issued earlier. Revoke any the account no longer needs — see API keys.

What it does not cover

Administrative changes are not recorded. Mailboxes created or removed, roles granted, domains added and subscription changes all happen outside this log.
Message activity is not recorded. Mail read, sent, deleted or forwarded leaves no entry here.
There is no date filter on the screen. Narrow by address, result and method, then page back through the results to reach an older period.
There is no export. The log is read in the browser; it cannot be downloaded as a file.
The trail begins where auditing began. Attempts made before the log was switched on for your workspace are not in it.

For how roles and access are granted in the first place, see Admin overview & roles. For what a person can do about their own account, see Security & privacy.

Previous: Storage & usage

Next: Your mailbox & folders