Work and Experience
Tooling Open-source reference

Email Deliverability Auditor

Scores a sending domain the way inbox providers evaluate it

View the repository
0 API keys
audits a domain from the outside
Client
Public reference project
Engagement
Open-source Python tool
Stack
PythonDNS ResolutionSPF / DKIM / DMARCBulk-Sender RulesCLI
01

Context

Before any migration or bulk send, the sending domain has to be sound or the mail will not land, and most domains that "look configured" are not. SPF records exceed the DNS lookup limit and silently permerror; DKIM signs but does not align; DMARC exists at p=none with no reporting address, observing nothing. None of this is visible by glancing at DNS records; it only shows up when you evaluate them the way a receiving provider does.

This tool automates exactly that evaluation: it resolves the live DNS, walks the SPF include chain against the RFC 7208 lookup ceiling, parses DMARC policy tags and alignment modes, checks MX topology and blocklist state, and returns a severity-weighted score with every finding mapped to the enforced Gmail, Yahoo and Microsoft bulk-sender requirements. The output reads as a remediation plan, not a diagnosis dump.

02

The Challenge

  • The dangerous failures are the silent ones, a record that exists and parses but fails evaluation (lookup-limit permerror, unaligned DKIM, blind DMARC).
  • Raw findings without prioritization are useless to a business owner: a placement-blocking permerror and a cosmetic warning must not look the same.
  • The compliance goalposts are versioned reality, the Gmail/Yahoo rules (and Microsoft's equivalents) are enforced thresholds, and the tool's findings needed to map to them explicitly.
03

Scope and Approach

  1. 01

    Authentication analysis

    Inspects SPF, DKIM and DMARC beyond presence: expands the SPF include chain and counts DNS-querying mechanisms against the 10-lookup ceiling, detects permerror conditions, evaluates DMARC policy strength, alignment mode and rua reporting state, the failure modes that pass a glance and fail in production.

  2. 02

    Reputation and topology checks

    Resolves MX topology and composite blocklist status in the same pass, so reputation issues surface alongside authentication ones and the remediation plan covers both dimensions at once.

  3. 03

    Severity-weighted scoring

    Scores the domain with findings ranked by placement impact, a permerror outranks a missing rua tag, which outranks a cosmetic warning, mirroring the order a professional remediation would actually execute.

  4. 04

    Compliance mapping

    Maps every finding to the enforced Gmail/Yahoo/Microsoft bulk-sender requirements, so the report doubles as a compliance gap analysis against the rules that actually decide placement.

  5. 05

    CLI output for pipelines

    Runs as a CLI with structured output, usable interactively before an engagement or wired into recurring checks, the same tool that audits a prospect's domain in a sales conversation can watch a client's domain in production.

04

Architecture flow

Target domain
input
SPF / DKIM / DMARC
chain expansion + alignment
MX + blocklist checks
reputation
Scoring
severity-ranked
pass
Clean report
issues
Ranked remediation plan
Compliance mapping
Gmail / Yahoo / Microsoft rules
05

Technical Deep Dive

The lookup-limit check

RFC 7208 caps SPF at 10 DNS-querying mechanisms; SaaS sprawl pushes real-world records past it one include at a time until evaluation dies with permerror. The auditor expands the chain recursively and reports the count and the offending includes, catching the single most common silent killer in business sending domains.

Alignment, not just presence

DKIM that signs with the ESP's domain instead of the sender's passes DKIM and fails DMARC alignment, mail authenticates and still gets treated as unauthenticated. The tool evaluates alignment explicitly because presence-checking is how these setups stay broken for years.

Severity model over checklists

Checklist tools emit twenty findings of equal visual weight. The severity model encodes what actually blocks placement versus what merely offends best practice, so a non-specialist reading the report fixes things in the right order.

Blind DMARC is a finding, not a pass

A DMARC record at p=none with no rua address technically "exists", and observes nothing, enforces nothing, and has usually been in that state for years. The auditor evaluates reporting state and policy strength as first-class checks, because a domain flying blind cannot even diagnose its own failures.

MX topology as context

The MX records identify the receiving infrastructure, Microsoft 365, Google Workspace, a custom stack, which contextualizes the rest of the audit: what the tenant can and cannot control, where DKIM delegation should point, and which provider-specific failure modes to check next.

06

Engineering Decisions

Pure DNS-side evaluation

The tool audits what receivers can see from the outside, no API keys, no platform access required. That makes it safe to run against any domain pre-engagement and honest about what external evaluation can and cannot conclude.

Remediation-plan framing

Every finding carries its consequence and its fix. The report is written to be handed to whoever controls DNS and acted on the same day, tooling as the first deliverable of an engagement, not a gadget.

07

Results

  • A scored, severity-ranked view of a sending domain before any migration or bulk send.
  • Catches the silent killers: SPF lookup-limit permerrors, unaligned DKIM, blind DMARC policies.
  • Findings mapped to the enforced Gmail/Yahoo/Microsoft requirements, a remediation plan, not a report.
  • Runs from the outside with zero platform access, safe for pre-engagement audits.
  • A repeatable pre-flight for ongoing sending health, public on GitHub.

Have a system that needs
this kind of work?

Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.

Chat on WhatsApp