Domain name audits: who owns the work after the report?

Ask the question at your next leadership meeting: “who is responsible for our domain names?”. You will get a silence, then three answers. The office manager, who pays the renewal. The agency, which bought the campaign domain. The developer, who touched DNS once and has since left. Three people, therefore nobody. That is why your domain portfolio has never been cleaned: not through neglect, but because cleaning it is nobody’s job.

The day you ask anyway, you are told that “DNS is up to date”. That sentence says neither which domains were looked at, nor what is missing, nor who is dealing with it. A domain name audit worthy of the name gives an answer a leader can verify and ask for again six months later. The method comes down to two things: a dated inventory, and an owner against every name.

To make it concrete, I return to the fictional small company from Email impersonation: your forgotten domain is writing to your customers. Its campaign domain, campaign.example, must never send a message. We follow this one domain from a bare configuration to the next check. Illustrative data; assessments calculated with the engine of dns-posture, a free, open source tool I published on npm, documented on GitHub, which works with OVHcloud and Cloudflare. It is meant for the technical team. Its reports are meant for you.

Everything starts with a dated observation. The team reads the configuration at the provider, and keeps a backup. An old file can be reassessed offline, but it describes the domain as it was, not as it is. The gap between the two is where the problems hide.

For campaign.example, the observation is short: the domain contains only an entry identifying its DNS server. Nothing declares who may send messages in its name, nothing says what to do with those that borrow it. From the records present, the tool classifies it as dormant.

Then comes the moment no tool will do for you, and this is where the owner steps in. Someone has to confirm that no invoice, no application, no campaign uses this domain to send. Not assume: confirm. Because the opposite mistake is expensive. An unknown mail provider in the configuration is not rubbish to delete, it is a use to track down, often that of a tool subscribed to without a word, like those accesses that outlive their tools. That is why dns-posture protects live email against automatic hardening by default. A domain without an owner is a domain on which nobody dares answer that question. So nobody touches anything. So nothing gets cleaned.

dns-posture produces three outputs: a readable report, a CSV for the spreadsheet, JSON for automation. They list the domains, their scores, the failing controls, their severity and remediation guidance. The table below is a simplified reading of two controls, not a screenshot.

Control on campaign.example	First observation	After the simulated correction
Authorised sending server rule, SPF	Missing (spf.present: fail)	Present, no sending authorised (pass)
Rejection policy for unauthenticated messages, DMARC	Missing (dmarc.reject: fail)	Rejection requested (pass)

In this minimal example, the baseline 1.1.0 score moves from 45/100 to 85/100 after adding the SPF and DMARC rules documented with the example. Be careful with that figure. It counts configuration controls satisfied. It does not say that 85% of attacks are blocked, nor that you are “85% safe”. Other controls still fail and are read one by one.

What you can take away, and ask for again in six months, fits in one line: sending is now explicitly prohibited on the campaign domain, the evidence is archived, and every remaining finding has a name against it. That last point changes everything. A report without an owner is a photograph. A report with an owner is a to-do list.

The fear that stops people cleaning is legitimate: nobody knows what depends on what any more, so nobody touches anything. The answer is not courage, it is procedure. A plan first: which records are affected, which must be kept. Application requires an explicit instruction, a backup of the current state, and a final read back from the provider. At the first error, writes stop on the domain concerned. Delegated subdomains and existing redirects have their own safeguards, so that a local correction does not cut off a service nobody remembered.

For an email domain that genuinely sends, the work is of a different kind: identify the legitimate senders, configure the services involved, including message signing. The tool does not turn a live domain into a silent one on its own. Nor is it a service that watches what your customers receive.

The final read confirms a state at your DNS provider. It does not prove that every recipient already applies the new rule: propagation and email handling happen elsewhere.

A week later, a contractor works on the campaign. He changes something in the zone, he leaves. In the fictional continuation of our example, the DMARC rule has gone. Nobody did it on purpose. Nobody noticed either: a successful audit ages at the speed of your last contractor.

A periodic check that reads the provider again finds the failure. Reassessing last week’s backup would have shown the same report as before, now misleading about the current state. The organisation is modest: a scheduled task reads the domains, produces the reports, archives each result with its date. The CSV serves human review. The JSON lets a small script compare with the previous period and send a notification when a control flips. dns-posture has no built-in scheduler or alerting: the team sets that up around it, and plugs it into the rest of its production monitoring and alerting.

The weekly cadence is an organisational choice, not an ANSSI rule. Add a check after every third-party intervention. And one requirement teams forget: if the read fails, the monitoring must say “no recent observation”, not redisplay the old report. A silence that looks like success is worse than an alert.

This monitoring covers configuration. The DMARC reports that email operators send you are about something else: the messages they actually processed. dns-posture neither collects nor analyses them.

What the company gets is not clean DNS. It is a review it can demand again: a known scope, a dated observation, precise findings, an owner per finding, and a check replayed after each correction. The rule that disappears becomes an item to deal with instead of staying hidden behind the memory of a successful audit.

The tool was not born of theory. It draws on retained logs: 61 domains backed up, 51 distinct domains with an application reported without error, 138 deletions and 147 creations recorded. Those logs prove neither attacks avoided nor time saved. They only say that cleaning involves a lot of writing and deleting, hence the work on backups, safeguards and the read-back.

If you do only one thing after this article, do not run the audit. Name the owner. The audit will follow, because someone will now have a reason to ask for it. Without an owner, this year’s report will join last year’s, and nobody will know what changed between them.

The guide to email impersonation risk places these controls within ANSSI’s recommendations. The team will find the tool on npm and the reproducible reporting and periodic monitoring example on GitHub.