Audit

Every email outage we have ever cleaned up started the same way: someone tightened a DMARC policy before they knew who was sending mail on the company's behalf. The audit exists to make sure that never happens to you. Before we change a single enforcement setting, we build a complete picture of every service that sends as your domain, check whether each one authenticates correctly, and write down exactly what needs fixing. Nothing gets blocked during this stage. We only watch and measure.

Why you never tighten a policy first

DMARC at p=reject tells the receiving mail server to refuse any message that fails authentication and alignment. That is exactly what you want against a forged invoice from accounts@yourcompany.com. It is also exactly what breaks your business if your payroll provider, your CRM, or your invoicing tool is sending real mail that you forgot was authenticating against a different domain.

The single biggest cause of self-inflicted email outages is publishing an enforcement policy without an inventory of legitimate senders. The day after you flip to reject, the finance team's automated statements bounce, the marketing newsletter lands in spam, and the helpdesk stops getting ticket notifications. None of that is the receiver's fault. It is the predictable result of guessing instead of measuring.

The trap is that DMARC at p=none can look healthy for months while hiding the problem. SPF does not survive forwarding, so a mailing list or a forwarding rule quietly strips the alignment off mail you assumed was fine. You only see the breakage once the policy starts to bite. The audit surfaces those weak spots while the consequences are still zero, which is the only sane time to find them.

This is also why so many domains that publish DMARC stay stuck at p=none forever. They watch, they see failures they cannot explain, and they freeze. The audit's whole job is to turn that fog into a named list you can act on.

What the audit inspects

We start with what is already published in DNS, because the existing records tell us a great deal about the state of your email authentication before we read a single report.

Current DMARC record

We pull your _dmarc TXT record and read the policy, the reporting addresses, the alignment modes, and the percentage tag. A record like v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com means you are monitoring only and, in many cases, nobody is actually reading the reports that arrive. We also check whether you have one at all. A surprising number of organisations have never published DMARC and have no idea who is spoofing them.

SPF record and lookup count

We count the DNS lookups your SPF record forces. RFC 7208 sets a hard limit of ten. Once an include: chain pushes you past it, the record returns permerror and SPF fails for everyone, including your real mail. We have seen records with eleven lookups that looked fine in a text editor and silently failed in production. Where that is the case, we note flattening as a fix, which resolves those includes down to IP ranges so you stay under the cap. There is more detail on that on our SPF flattening page.

DKIM selectors and key strength

We enumerate the DKIM selectors in use, for example s1._domainkey or a provider-specific selector like google._domainkey, and check the published public key at <selector>._domainkey.yourcompany.com. We record whether each key is 1024-bit or 2048-bit, because weak keys are worth rotating, and selectors are exactly the mechanism that lets you rotate without an outage.

Alignment for each sender

This is the part most checks skip. A message can pass SPF and pass DKIM and still fail DMARC, because DMARC requires alignment: the SPF or DKIM domain has to match the visible From domain. A marketing platform that signs with its own d=sendingplatform.com domain will pass DKIM but fail alignment against From: you@yourcompany.com. We flag every sender in exactly this position. Our guide to alignment explains the mechanics in full.

Subdomain coverage

Spoofers love subdomains you forgot about, such as mail.yourcompany.com or news.yourcompany.com. We check whether your DMARC policy covers subdomains through the sp= tag and whether any active subdomain is sending mail that needs its own attention. An organisational policy at the apex does not automatically protect a subdomain that has its own record, so a forgotten _dmarc.news.yourcompany.com can sit wide open while the main domain looks locked down. We list every subdomain that is sending so none of them gets left behind when enforcement arrives.

How we discover every legitimate sender

You cannot inventory your senders from DNS alone, because DNS only shows what is configured, not what is actually sending. To see the real traffic, we read the reports the receivers send back.

Switching DMARC to monitoring

If you do not already have a working DMARC record with a reporting address, we publish one at p=none pointing the rua= aggregate address at our ingestion endpoint. At p=none the policy changes nothing about how your mail is handled. It simply asks every major mailbox provider to send back a daily aggregate report listing the IP addresses that sent mail claiming to be you, and whether each one passed SPF, DKIM and alignment.

Reading two to four weeks of reports

One day of reports is not enough, because mail is bursty. Monthly invoicing runs, quarterly statements, a payroll cycle, a seasonal campaign: these only show up if you watch long enough. We typically read two to four weeks of aggregate data so the slow and occasional senders surface alongside the daily ones. Our analytics dashboard turns those raw XML reports into a readable picture of who is sending, from which IP ranges, and where authentication is breaking.

Interviewing the team

Reports show the IP addresses, but they do not always tell you which department owns them. So we pair the data with a short conversation. We ask which tools send mail on the company's behalf, because almost every team has more than they think:

• Payroll and HR systems sending payslips and notices
• CRM and sales platforms sending sequences and meeting invites
• Invoicing and accounting tools sending statements and reminders
• Marketing platforms sending campaigns and newsletters
• Ticketing and helpdesk systems sending support replies
• E-commerce stores sending order and shipping confirmations

Matching the named tools against the IP addresses in the reports is how we turn an anonymous list of sources into a sender inventory you actually recognise. The conversation also catches senders that have not fired yet during the watch window: the annual tax pack, the disaster-recovery alerting that only triggers in an incident, the contractor onboarding flow that runs twice a year. Knowing those exist lets us plan for them rather than be surprised by a bounce later.

The audit checklist

Here is precisely what we work through for every domain. Nothing on this list changes your mail flow. Every item is a read or a measurement.

• Existing DMARC record, policy, alignment modes and reporting addresses
• Whether anyone is currently reading the aggregate reports
• SPF record present, syntactically valid, and within the ten-lookup limit
• Any permerror caused by lookup overflow or void lookups
• DKIM selectors in use and the key strength of each (1024 or 2048-bit)
• Whether each active sender passes SPF, passes DKIM, and aligns
• Subdomain policy coverage and any mail sent from subdomains
• MTA-STS and TLS-RPT presence, noted for the later steps
• Two to four weeks of aggregate reports read and the senders identified
• Team interview cross-referenced against the report data

If you want a fast, free first look before we start, run the free scan on your domain. It checks the published records in seconds and gives you a sense of where you stand.

What you get at the end

The audit produces one clear document: a map of your email estate. For every legitimate service that sends as you, it records the sender, its source IP ranges, its current authentication status, and the specific gap to fix.

A typical finding reads something like this: the marketing platform passes DKIM but is not aligned to yourcompany.com and needs its sending domain configured; the invoicing tool authenticates correctly and is ready; the SPF record sits at eleven lookups and returns permerror, so it must be flattened. Every line is a concrete, named action, not a vague warning.

You cannot safely enforce a policy you have not measured. The deliverable turns "we think we know who sends our mail" into a list you can sign off on.

How long it takes and what you provide

The hands-on work is light on your side. The clock is set mostly by how long we watch the reports, not by effort.

From you we need exactly one thing to begin: access to your DNS, so we can publish the monitoring record and read the existing SPF and DKIM entries. You can grant delegated access or simply add the records we provide. That is the whole ask for step one.

Setting up step two

Once the sender map is agreed, the path is clear. Step two takes each gap the audit found and fixes the authentication: configuring DKIM for the platforms that lacked alignment, flattening the SPF record if it overflowed, and bringing every legitimate sender into compliance. We do that work and re-check it against fresh reports before anyone discusses tightening the policy.

Only when the reports show clean, aligned authentication across the board do we move on to enforcement. That sequence, audit, then fix, then verify, then enforce, is what lets us reach p=reject without the outage that catches everyone who rushes it.

Getting started

The audit is the foundation of the whole done-for-you process, and it is deliberately low risk: you give us DNS access, we publish a monitoring record, and a few weeks later you have a complete, evidence-backed picture of who sends as your domain. From there, enforcement is an introductory one-time fee of £200 (normally £500), with ongoing monitoring at £19 per month (normally £39); see pricing for the detail.

If you would rather see the state of your records right now, start with the free scan or create an account. Knowing who sends as you is not the boring preliminary to enforcement. It is the part that makes enforcement safe, and it is where every successful DMARC project begins.