Mail Deliverability Audit: six-layer sender auth diagnosis

    1

    Six-layer mail auth audit: SPF lookup and void budgets, DKIM wildcard selectors, DMARC p/sp/np under RFC 9989, PTR, bounce triage, aggregate reports.

    $42

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIMuseMuseDotsDots+21 more

    Mail Deliverability Audit: six-layer sender auth diagnosis

    Example session with this skill installed

    A customer says the verification code never arrived. SPF passes on every checker I have tried and the DKIM key is 2048-bit, so I am being told to rewrite DNS. Tell me which of the six layers is actually failing before I touch a record.

    • Read your context and instructions
    • Compiled the mail deliverability audit

    Verdict

    layer 0 - and it is not your records. Your resolver answered "no SPF record" for the domain. The authoritative nameserver answers with 60 TXT records and SPF is one of them.

    The walk, in order, stopping at the first FAIL

    LayerWhat it checkedResultVerdict
    L0 local resolveris the recursive answer complete16 TXT records came back, none v=spf1; authoritative has 60[FAIL]
    L1 SPFcount, syntax, lookup budget, void budget, fallback qualifier, leftover ptr9 of 10 lookups, 1 void, ends ~all[ OK ]
    L2 DKIMselector probing, key length, p= revocation, t= / h=2048-bit, not revoked, selector explicit[ OK ]
    L3 DMARCtree walk, p/sp/np coverage, rua external authorisationp=reject, no sp=, rua authorised[ OK ]
    L4 infrastructureMX, null MX, MX host addresses, apex addresses2 MX, both resolve[ OK ]
    L5 sending sourcewith --send-ip: is this IP authorised, PTR / FCrDNSPTR matches the HELO name, authorised by an include: term[ OK ]
    L6 extension recordsDNSSEC DS, MTA-STS, TLS-RPT, BIMI, CAAMTA-STS absent, CAA present[WARN]

    Exit code 2: something in the report is a FAIL. Nothing in this table is a reason to edit the zone, and that is the whole point of walking the layers in this order.

    What L0 actually says

    "16 records came back" and "the record I asked for came back" are two different facts. The first version of this check treated them as one: a large provider returns 16 TXT records that are all verification strings, so the report flatly declared the domain had no SPF record while the authoritative nameserver held 60. The check now asks the authoritative server only when the recursive answer is missing the record being asked about, and never for DKIM selectors - "not found" is a normal answer at that layer, and chasing a dozen selectors upstream is dozens of queries for nothing.

    The consequence is worse than one wrong field: if the resolver silently drops records, every other lookup made through it is equally untrustworthy - including the ones that made SPF "pass" on those checkers.

    Next steps, in this order

    1. Reproduce it by hand from a network that is not yours: dig +short TXT example.com @1.1.1.1. Every item in the report carries the one command that settles it, so no line has to be taken on trust.
    2. Fix the resolver, not the zone. Re-run the same command; if L0 flips to [ OK ] and the rest of the table is unchanged, the only thing that was broken was the vantage point.
    3. Then take the one real item, L6: publish MTA-STS. The template is templates/mta-sts.txt; it needs a record at _mta-sts plus HTTPS hosting of the policy, and it does nothing until both exist.
    4. If a bounce code is what you actually have in hand rather than a domain, run bounce_triage.py --code "550 5.7.15" - same discipline, keyed by the exact code.

    Read-only throughout: not one message is sent, there is no bulk test and no seed list, no DNS record is changed, and no selector name is guessed.

    Connects securely to your tools. The creator never sees your data.

    About this skill

    'The customer never got the verification code' is not one problem. It is four: hard rejection at auth, delivered but spam-foldered, forwarded into a broken chain, or an address that does not exist. Only two of those have anything to do with DNS, and editing SPF to fix the other two is the most expensive mistake in this domain, because one bad record stops mail for a whole domain, including other people's verification codes.

    This skill enforces the order that actually works: layer 0 resolver integrity (your own recursive resolver can silently drop records while reporting a clean answer, and we measured exactly that on several major domains), then SPF lookup budget and void lookups, then DKIM selectors and key strength, then DMARC p/sp/np coverage and external rua authorization under RFC 9989, then infrastructure (MX, PTR / FCrDNS), then extension records (MTA-STS, TLS-RPT, BIMI, CAA). A FAIL at any layer stops the walk.

    Domain expertise baked in: permerror is not pass (11 lookups against the RFC 7208 limit of 10), the second lock almost nobody checks is void lookup ≤ 2, mx counts as one term while the receiver resolves every MX host, a wildcard DKIM selector returning 'v=DKIM1; p=' means this domain does not sign rather than 24 separate failures, and p=reject with a leftover pct=25 becomes a full reject on newer receivers.

    Includes three scripts (six-layer audit, bounce-code triage, DMARC aggregate-report forensics that rejects DOCTYPE / ENTITY outright), a 33-entry failure library, and four record templates.

    What it does not do: no SMTP client, no bulk sending, no seed tests, no live blocklist lookups, no DNS changes. Read-only by construction.

    Read-only: does not send mail or modify DNS. Requires manual RDAP lookups for IP attribution. Does not perform live blocklist lookups. Only you can verify domain ownership for Postmaster tools.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before any payment.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 6 days ago

    Requires

    Your
    Rdap
    Python

    Permissions

    Terminal / Shell
    Network Access
    Read Files
    Write Files

    Allowed Hosts

    mta-sts.your.com
    rdap.org

    Terminal / Shell: the audit is a set of CLI scripts plus the dig/host commands the triage tree tells you to run. Read Files: it reads the DMARC aggregate report files the operator drops in a directory. Write Files: it writes the findings report and the parsed aggregate summaries next to those files. Network Access: it resolves DNS records (UDP with TCP fallback) for the domain you name - SPF, DKIM selectors, DMARC, MX, PTR, MTA-STS, TLS-RPT, BIMI, CAA. It sends no mail, changes no DNS, and opens no connection to any other host. base64 decoding appears only when it reads the p= public key out of a DKIM record, because RFC 6376 defines that value as base64 - it decodes nothing from the package.

    Listed6 days ago

    What's inside

    Frequently Asked Questions

    This skill moves beyond simple record lookups by performing a deep RFC-compliant audit of your DNS infrastructure, specifically identifying 'silent killers' like SPF lookup budget exhaustion and DMARC alignment gaps that standard prompts often miss.

    The skill provides a suite of standalone Python scripts (auth_audit, bounce_triage, and dmarc_report) designed to work in any environment with a Python interpreter, requiring no external libraries or OS-level DNS utilities.

    No, the tool operates on a 'read-only' principle to ensure safety; it diagnoses issues and provides actionable insights without the risk of accidentally locking your domain out by modifying live DNS records.

    The bounce triage tool is designed to categorize SMTP error codes—such as the common Gmail '550 5.7' errors—to determine if a failure is due to your authentication setup, your sender reputation, or recipient-side issues.

    Yes, the DMARC forensics module is built to process and reconcile XML and GZ aggregate reports, allowing you to identify unauthorized sending sources and validate your 'p=reject' readiness.