Email Delivery Audits and the Multi-Tool Bottleneck

From Fragmented Tools to a Consistent Audit

Following the friction experienced during customer domain reviews, a foundational question arose: could a comprehensive mail security audit be performed using a consistent set of checks rather than moving between several unrelated tools and then trying to reconcile their results?

The problem was not simply that there were too many tools. Running the checks manually took time and energy, and each tool required its own method of gathering information. The results then had to be interpreted together to determine what was actually true, what represented a limitation of the tool being used, and what should ultimately be recommended to complete the audit.

That distinction became important. A tool reporting that something was missing did not necessarily establish that the underlying configuration was missing. It could also mean that the tool had not looked in the right place, used an incomplete set of assumptions, or simply did not support the way a particular vendor implemented the service.

Separating Facts from Tool Limitations

The earlier audit workflow relied on several external web utilities and command-line lookups to establish a baseline. Each provided useful information, but the administrator still had to determine exactly what had been tested and whether the result was sufficient to support a conclusion.

DKIM provided a particularly useful example. A diagnostic tool that checks only a small collection of predetermined selectors can report that DKIM is missing when a valid signing record exists under a selector the tool never considered. In that situation, the tool's result is not necessarily false; it is simply incomplete.

Manual verification through DNS made it possible to distinguish the two. That led to a more useful approach: establish the underlying facts first and then interpret those facts, rather than treating the conclusion produced by an individual diagnostic tool as authoritative.

The First Scripting Approach

Initial exploration focused on native Windows and PowerShell utilities to reproduce the useful portions of the multi-tool workflow locally.

• DNS interrogation: Using Resolve-DnsName and nslookup to pull apex records, MX endpoints, SPF information, and explicit _dmarc records.
• Transport testing: Using Test-NetConnection to verify outbound socket reachability on secure mail submission ports such as port 465 and port 587.
• Selector enumeration: Looping through arrays of common enterprise DKIM selectors such as default, selector1, google, s1, and k1 rather than assuming a single naming convention.

This successfully automated much of the repetitive work, but it introduced another limitation. A collection of local scripts was useful to the administrator running them, but it was still necessary to assemble the results and turn them into something that could be consistently reviewed and reported.

The Pivot to a Web-Based Utility

The next step was to move the useful portions of the process into a server-side PHP application. This became the Domain Mail Security Checker (DMSC).

The goal was not to reproduce every external diagnostic service in a single application. It was to establish a consistent first-pass audit using repeatable checks that could be gathered, interpreted, and reported together.

A web-based utility provided a practical way to normalize user input, perform the relevant DNS queries, test mail connectivity, inspect TLS behavior, discover common DKIM selectors, and assemble the results into a single report without requiring the administrator to manually move information between several tools.

The important improvement was therefore not simply having all of the checks on one page. It was having the checks performed using the same logic every time.

Why Reputation Checks Stayed Separate

One obvious omission from the consolidated audit was DNS-based blacklist and reputation checking. That was deliberate.

Reputation services answer a different question from the structural checks being performed by DMSC. They report what a particular reputation provider currently believes about an IP address or network. They do not establish whether the domain's mail configuration is internally correct.

A domain can have valid SPF, DKIM, DMARC, TLS, and MX configuration while a sending IP has a poor reputation with one or more external providers. The reverse is also possible: a clean reputation result does not prove that the domain's authentication or mail-routing configuration is correct.

Adding DNSBL queries to DMSC would also have introduced another collection of external services with different policies, response formats, availability, and interpretations of what constitutes a problem. That would have increased the amount of information returned without necessarily improving the diagnostic decision.

The decision was therefore to keep the first-pass audit focused on facts that could be gathered consistently and interpreted directly. Reputation checking could remain a separate investigative step when the evidence called for it.

Making the Audit Faster Without Hiding the Work

As DMSC developed, another practical problem became apparent. A technically sound audit can still feel slow when the interface gives the administrator little indication that work has started.

The audit process was subsequently adjusted so that activity became visible more quickly after starting a check. This reduced the large visual delay between requesting an audit and seeing the resulting activity without changing the underlying purpose of the checks.

That was an important distinction. The objective was not to make the process appear faster by hiding work. The objective was to make the progress of the existing work visible sooner.

From Audit Results to Remediation

Once the basic audit process became consistent, another distinction became clearer: finding a problem and fixing it are separate tasks.

DMSC could establish that an SPF record exceeded the applicable lookup limit, for example, but the audit still needed to determine why that happened, what the contributing records were, and what remediation would be appropriate. That work eventually led to a separate experiment around SPF flattening and configuration drift.

The SPF Flattener therefore developed as a remediation workbench rather than as another collection of unrelated audit checks. This kept the initial audit focused on identifying and explaining conditions while allowing a separate utility to work on the more complicated task of producing a usable corrective configuration.

What the Consolidated Approach Changed

The resulting workflow was less about replacing every tool used during an investigation and more about establishing a reliable first-pass baseline.

Instead of beginning with several disconnected results and trying to determine what each tool actually tested, the audit could begin with a consistent set of directly gathered facts. Additional tools could then be used when those facts indicated that a deeper investigation was necessary.

That distinction made the process easier to reason about. It also made the resulting recommendations more defensible because there was a clearer separation between what was observed, what the observation meant, and what should be done about it.

DMSC ultimately became less of an attempt to build one enormous mail diagnostic system and more of a practical audit workbench: establish the facts consistently, identify the areas that require attention, and use more specialized investigation where the initial evidence warrants it.