The audit log

22 June 2026 · 14 min read

What the audit log is for

Your DMARC Engine account does something most software accounts do not: it controls live DNS for your domains. The records it manages decide whether the world's mailbox providers accept, quarantine or reject your mail. When someone in your organisation moves a policy to p=reject, rotates a DKIM key, adds an include to your SPF record or invites a new admin, the effect is real and immediate. The Audit Log is the permanent, read-only record of those actions: who did what, to which resource, when, and from where.

This guide covers the Audit Log page at /audit: what it records, how to search and filter it by user and by action, how to read a single entry, how the export works, and why this log matters for security investigations and for compliance evidence. Everything here is in the dashboard at https://app.dmarcengine.com, so sign in and follow along.

The audit log is an administrative feature. It sits alongside the rest of your account-level controls, the same family as the Security tab and the Team tab. If you have not set up your organisation and brought colleagues in yet, read team and roles first; the value of an audit log grows with the number of people who can act in the account. New to the platform entirely? Begin with getting started.

A quick distinction before you start. The Audit Log at /audit records actions taken inside your DMARC Engine organisation: domain changes, record changes, member changes and so on. It is not the same as the login activity list on the Security tab, which shows your own sign-in history, nor is it the aggregate report data, which comes from mailbox providers and describes mail in flight rather than actions in the dashboard. Three different logs, three different jobs.

Finding the Audit Log

In the dashboard, open the Audit Log from the left-hand navigation, or go straight to the path /audit. The page is reserved for administrators. If you hold the editor or viewer role, you will not see it in the navigation, because the audit log can expose the actions of other members and is therefore an admin-only view. If you expected to see it and cannot, check your role on the Team tab: an existing admin can promote you, or you can ask an admin to pull the entry you need.

The page is laid out simply, top to bottom:

• A row of controls across the top: a Search bar, a User filter, an Action filter and an Export button.
• A single table of activity below, sorted with the most recent action first.
• Pagination controls at the foot of the table.

That is the whole page. There is no separate detail screen to drill into; everything you need to read an action is in its row. The rest of this guide walks through each control and then through the columns of the table.

What the audit log records

The audit log captures the meaningful, state-changing actions taken in your organisation. In broad terms, that means anything that changes your configuration, your DNS or your people. The kinds of events you will see include:

• Domain lifecycle: adding a domain, verifying it, and deleting it.
• Record and policy changes: editing or publishing a hosted record, and moving a domain along the enforcement journey, for example taking a policy from p=none to p=quarantine and on to p=reject. See hosted DMARC for what those changes do.
• Service setup and edits: configuring or changing SPF, DKIM, MTA-STS and BIMI, including DKIM key rotation and SPF flattening changes (see how SPF flattening works).
• Team and access changes: inviting a member, changing someone's role, and removing a member.
• Security changes: enabling or disabling two-factor authentication, and similar account-protection events covered in security and 2FA.
• API key activity: creating and revoking API keys.
• Notification and alert configuration: adding or changing the channels described in setting up alerts and monitoring and change alerts.

The point of recording all of this in one place is that you never have to reconstruct what happened from memory or from a chain of emails. If a record changed and you want to know who changed it, the audit log is the single, authoritative answer.

The log is append-only and read-only. There is no edit or delete control anywhere on the page, by design. An audit log you can edit is not an audit log; the value of the record is that it cannot be quietly altered after the fact, even by an admin. Entries are written as actions happen and they stay as written.

The columns: how to read an entry

The table has six columns. Reading an entry is a matter of reading left to right across one row. The columns are:

Timestamp

When the action happened. Times are shown in your organisation's timezone, which you set on the Organization tab in Settings (see team and roles for where that lives). Getting the timezone right matters here more than almost anywhere else in the product: when you are reconstructing a sequence of events during an investigation, "just before 14:00" needs to mean the same thing to everyone reading the log. The table is sorted by timestamp with the newest entry at the top, so the most recent activity is always what you see first.

User

Who performed the action. This is the member's name or email as it appears on your Team tab. It tells you the human being (or, for programmatic actions, the API identity) responsible for the entry. When you are answering the question "who did this?", this is the column that answers it.

Action

What was done, shown as a short, colour-coded label. The colour coding is there so you can scan a long list quickly and pick out the kind of action without reading every word: creating, updating and deleting actions are visually distinct, so a deletion does not hide in a wall of identical-looking text. Treat the colour as a fast first read and the label text as the precise answer. The Action column is also the basis of the Action filter described below.

Resource

What the action was performed on. This is the object the action touched: a specific domain, a record, a team member, an API key and so on. Read together, the Action and Resource columns give you the sentence: this user updated this domain's DMARC policy; this user removed this member; this user created this API key.

Details

The specifics of the change, the part that turns "a record was updated" into something you can actually act on. Depending on the action, Details carries the extra context: which field changed, the relevant values, or the identifier of the affected object. When you are investigating, this is the column you read most closely, because it is where the substance of the change lives.

IP Address

The network address the action came from. This is the column that distinguishes "our consultant working from the usual office" from "a login from a place none of us recognise". It will not, on its own, prove who someone is, but a familiar address alongside a familiar user is reassuring, and an unfamiliar address alongside a sensitive action is exactly the kind of thing you want to notice and follow up. Pair it with the login activity on the Security tab when you are running something down.

Searching the log

The Search bar at the top filters the table to entries that match your text. Type a term and the table narrows to matching rows. Search is the right tool when you already know roughly what you are looking for: a particular domain name, a specific member, a keyword from an action or a value that would appear in the Details. It is the quickest way to jump from "something happened to example.com" to the handful of rows that mention it.

Search works alongside the two dropdown filters rather than instead of them. You can type a domain into Search and also set the User filter to one person, and you will see only that person's actions that match your search term. Combining the three controls is how you go from thousands of entries to the precise few you care about.

Filtering by user

The User filter is a dropdown that limits the table to actions performed by one member of your organisation. Choose a name and the log shows only their entries. This is the filter you reach for when the question is about a person rather than a thing:

• "What has this new editor done since they joined?" Set User to that editor.
• "Show me everything our outgoing contractor touched before we remove them." Set User to the contractor, then read down the list before you revoke their access on the Team tab.
• "Did anyone other than me change this last week?" Leave User unset to see everyone, then scan the User column.

Reviewing one member's history is also a healthy periodic habit, not only an incident response. Before you promote someone to admin, a glance at their recent actions tells you how they have been using the access they already have.

Filtering by action

The Action filter is a dropdown that limits the table to one type of action. This is the filter for the question "show me every time X happened, whoever did it". Common uses:

• Filter to deletions to review every domain or member removal across the whole organisation.
• Filter to policy or record changes to see the history of how your configuration has moved, which pairs naturally with the enforcement journey.
• Filter to team or role changes to review how access has shifted over time.
• Filter to API key creation and revocation to keep programmatic access accountable.

Because the Action column is colour-coded, the filter and the colours reinforce each other: pick the action type you care about, and the rows that remain are all the same colour, which makes a focused review fast and hard to misread.

Pagination, and a word of caution about filters

The audit log can grow long, so the table uses server-side pagination at 50 rows per page. The newest 50 actions are on the first page; older activity continues onto further pages, reachable with the pagination controls at the foot of the table. Server-side pagination means each page is fetched as you ask for it rather than the whole history being loaded into your browser at once, which keeps the page fast even when your organisation has a great deal of history.

There is one behaviour worth understanding clearly, because it is easy to misread otherwise. When a filter you apply would span more than one page of results, the dashboard shows a warning. The reason is that some filtering happens on the rows currently loaded in your browser, so a filter can match entries on the page you are viewing while other matching entries sit on pages you have not loaded. The warning is telling you, honestly, "there may be more matches than you can see here".

Treat the warning as a prompt to narrow, not as a problem to ignore. If you see it:

• Add another filter. Combining Search, User and Action is the most reliable way to bring a result set down to a single page where what you see is genuinely all there is.
• Tighten your search term. A more specific term (a full domain, a full email) cuts the result set faster than a broad one.
• Use the export when you genuinely need the complete set across every page, as described next.

In short: when no warning is showing, the filtered rows in front of you are the complete picture. When the warning is showing, narrow further or export before you draw a conclusion, especially in an investigation where "I did not see any others" must actually mean there were none.

Exporting the log

The Export button produces a file of the audit log for use outside the dashboard. Export is what you reach for when you need the record somewhere other than the screen:

• Compliance evidence. Auditors for SOC 2, ISO 27001, GDPR and similar frameworks routinely ask for proof that you can show who changed what and when. An exported audit log is exactly that evidence, in a form you can attach to a control or hand to an assessor.
• Investigations. When you are reconstructing an incident, having the relevant entries in a file lets you sort, annotate and share them with colleagues or with an external responder without giving everyone dashboard access.
• Retention and archival. If your own policies require you to keep a copy of administrative activity for a set number of years, exporting on a schedule gives you that archive.

Because the export reflects the data you have filtered to, it also gives you a clean way around the multi-page warning above: set your filters, export, and the file contains the complete matching set rather than only the page on screen. Handle exported files with the same care you would any security record. They name your people and their actions, so store them somewhere access-controlled, not a shared drive that anyone can open.

When the log is empty

You will occasionally see one of two empty states rather than a table of rows. They mean different things, so read which one you have:

• "No activity yet" appears when there is genuinely nothing to show: a new organisation that has not yet taken any recordable action. As soon as someone adds a domain, changes a record or invites a member, entries start to appear. There is nothing to fix here; the log is simply waiting for its first event.
• "No matching entries" appears when there is activity, but none of it matches the filters you have set. This is your cue that Search, User or Action is too tight, or that you have combined filters that no single entry satisfies. Clear a filter or two and the rows will return.

The distinction is useful in practice. If you are sure a member did something and you see "No matching entries", the action almost certainly exists and your filter is hiding it; widen the filter. If you see "No activity yet", the action was never recorded at all, which is itself a finding.

Why the audit log matters

It is tempting to treat an audit log as a box-ticking feature you only open when an auditor asks. It is more useful than that, for two distinct reasons.

Security. An audit log turns "we think nothing bad happened" into "we checked, and here is exactly what happened". If a domain's policy is suddenly weaker than you left it, the log tells you whether a colleague changed it for a good reason or whether you have a problem. The IP Address and User columns together let you spot an action that does not fit: a sensitive change from an unfamiliar address, a member acting outside their normal pattern, an API key created at an odd hour. Reviewing the log regularly, not just after an incident, is one of the cheapest security habits available to you, and it pairs naturally with switching on two-factor authentication for everyone (see security and 2FA) and keeping your admin count small (see team and roles).

Compliance and accountability. Email authentication does not exist in a vacuum; it usually sits inside a broader compliance posture. Frameworks that govern how you handle data and access expect you to be able to demonstrate accountability for changes to important systems, and DNS that controls mail trust is an important system. The audit log is the artefact that demonstrates it. Beyond formal audits, the same record keeps an honest organisation honest: when everyone knows that publishing a record or removing a member is logged with their name against it, changes get made more carefully and explained more readily.

A practical rhythm works well: review the log briefly after any significant change, do a slightly fuller pass on a regular cadence (filtering by Action to deletions and role changes is a good ten-minute review), and export on whatever schedule your retention policy requires. Done that way, the audit log stops being something you scramble to read after a problem and becomes something that quietly tells you a problem is brewing before it lands.

Where to go next

• Decide who can reach the audit log and who can change records in the first place: team and roles.
• Harden the accounts whose actions the log records: security and 2FA.
• Understand the policy changes that show up most often as entries: the enforcement journey and hosted DMARC.
• Get alerted to important changes as they happen, not only in hindsight: monitoring and change alerts and setting up alerts.
• Check the current state of any domain's published records from outside the dashboard with the free DMARC checker, SPF checker, DKIM checker, MTA-STS checker and BIMI checker.
• New to the terms in this guide? The glossary and the requirements page explain the underlying concepts and the standards behind them.