Building Audit Evidence: A Guide for Enterprise Teams

The Audit Evidence Gap: Why Configuration Alone Falls Short

Most email authentication programs reach a functional state and stop. SPF records are published. DKIM keys are rotated when someone remembers. A DMARC policy is set to p=quarantine or p=reject. The team moves on.

The problem surfaces at audit time. An auditor reviewing email security controls may ask for:

• A current inventory of all domains and their authentication posture
• Evidence that policies are enforced, not just declared
• Logs showing ongoing monitoring activity
• Evidence that unauthorized senders are detected and acted on

None of these exist automatically. They require deliberate collection and maintenance. A business can have a technically sound authentication setup and still fail an audit – simply because it has no evidence.

This is the audit evidence gap. Closing it is an operational and governance problem, not a technical one.

What Audit Evidence Actually Looks Like

Before building an audit evidence collection workflow, define what each of these needs to contain.

Configuration Inventory

A configuration inventory is the foundation of audit evidence. It documents the current authentication state of every domain the company sends email from.

For audit purposes, this should include:

• Domain name
• SPF record (current value, last modified date, authorized senders)
• DKIM selectors in use (per domain, per sending system)
• DMARC policy (p= value, rua= and ruf= addresses)
• Policy owner (department or team)
• Last reviewed date

This domain inventory needs to be versioned. A snapshot from today has limited audit value unless it demonstrates a consistent posture over time.

Policy Change Documentation

Every change to an SPF record, DKIM key, or DMARC policy needs to be documented: What changed, when, who authorized it, and why. This matters most when moving from p=none to p=quarantine to p=reject. Enforcement progression should be deliberate and staged, with each step producing a documented sign-off.

Monitoring Logs

DMARC aggregate reports show, per reporting period, which sources sent messages claiming to be from your domain and whether those sources passed or failed SPF and DKIM alignment. These reports contain structured data about every sending source, not just failures.

For audit evidence, teams need:

• Archived aggregate reports across a defined review period
• A record of how reports were reviewed, by whom, and what actions resulted
• Documented escalation paths for authentication failures above a defined threshold

A DMARC aggregate report sitting unread in a mailbox doesn’t constitute monitoring. Auditors typically ask whether reports were acted on, not merely received.

Multi-Tenant and Delegated Domain Scenarios

Enterprise organizations rarely operate a single domain. Subsidiaries, acquired businesses, and regional brands each have their own domain portfolio. In delegated models, individual divisions may own their authentication independently.

This creates two audit evidence problems.

1. Visibility fragmentation. When each domain is managed separately, no single view captures the company’s authentication posture. A request for email authentication status across all domains can’t be answered with one report.
2. Ownership ambiguity. When a domain is authenticated but no team is named responsible for maintaining it, that’s a governance gap. Auditors treat undocumented ownership as a control failure, even when the technical configuration is sound.

For multi-tenant environments, the evidence requirement extends to demonstrating that every domain in scope, including recently acquired domains and those under delegated management, is covered by a consistent monitoring and review process. Maintaining DMARC compliance across domains requires a centralized view. Individual domain checks done ad hoc aren’t sufficient.

Building the Workflow

Step 1: Domain Inventory and Baseline

Start with a complete list of every domain the business owns, regardless of whether it sends email. Domains that don’t send email still require a DMARC record with a p=reject policy to prevent spoofing. Gaps in the non-sending domain inventory are audit findings.

For sending domains, document the full sender inventory: Every third-party platform, SaaS tool, CRM, and ticketing system that sends on behalf of the domain.

Step 2: Policy Review and Documentation

For each domain, document the current DMARC policy and the justification. A domain at p=none should have a documented reason, such as active remediation, a known forwarding issue under investigation, or a legacy system awaiting decommissioning. Undocumented p=none policies read as inaction to an auditor and are treated as audit findings.

Step 3: Monitoring Cadence and Reviews

Establish a formal monitoring cadence: Who reviews aggregate reports, how often, and what the review covers. Monthly is practical for most enterprise environments. High-risk domains warrant weekly review.

Each review cycle should produce a documented output: A brief record of what was reviewed, whether any new or unauthorized senders appeared, and what action, if any, was taken. This doesn’t need to be elaborate.

Step 4: Cross-Domain Verification Checks

Schedule periodic verification across the full domain inventory to confirm that the DNS records match the documented configuration. Records drift. Senders are added without updating SPF. DKIM keys are rotated, but old selectors are left active. The gap between what’s documented and what’s actually published in the DNS are audit findings.

Step 5: Documentation for Non-Technical Stakeholders

The compliance team’s job isn’t just to collect audit evidence, but to translate it into documentation that a board, audit committee, or external regulator can review.

This means:

1. A summary authentication posture report covering the full domain portfolio
2. A documented escalation path for authentication failures

How Sendmarc Can Help

Maintaining audit evidence across dozens or hundreds of domains consumes time that stretched security and IT teams don’t have.

Sendmarc provides a centralized view of authentication posture across a full domain portfolio, updated continuously. SPF results, DKIM status, and DMARC enforcement level are visible in a single interface.

For compliance and IT teams mapping current authentication posture ahead of an audit cycle, start with the domain inventory. Use the Sendmarc Platform to see where your domain portfolio stands today.