# TamingDNS — Full LLM Context

> TamingDNS is a free suite of email deliverability and DNS diagnostic tools for IT administrators, MSPs, and developers. The platform is designed for immediate use with no account or login required. Built by OSH.co.za, a South African managed IT services provider specialising in email deliverability, Google Workspace, and Microsoft 365.

This file is the expanded counterpart to `/llms.txt`. It bundles short descriptions of every TamingDNS tool, the protocols each tool covers, and the SMTP codes catalogued in the Bounce Decoder library, so an LLM can answer most "what does TamingDNS do?" or "how do I check X?" questions without fetching the live pages.

- Site root: https://tamingdns.com/
- Sitemap: https://tamingdns.com/sitemap.xml
- Operator: OSH.co.za (https://osh.co.za)
- Pricing: free, no account required
- Privacy: https://tamingdns.com/privacy-policy

## About TamingDNS

TamingDNS focuses on the diagnostic side of email deliverability and DNS. It is positioned as a free, focused alternative to MXToolbox SuperTool, mail-tester.com, and dmarcian. Every tool is single-purpose, with FAQ sections explaining the underlying protocol in plain English. Domain lookups query authoritative DNS through multiple resolvers (Google, Cloudflare, Quad9). Tools that take user input (DMARC Report Viewer, CIDR Calculator) process it entirely in the browser and never upload it.

The site is organised into four groups:

1. Analysis tools read DNS for a domain and validate a specific protocol (SPF, DKIM, DMARC, BIMI, DNSSEC, MTA-STS, TLS-RPT, WHOIS, M365/Workspace audits, Email Headers, Bounce Decoder).
2. Diagnostic tools operate at the network layer (Blacklist, MX, Reverse DNS, IP/RDAP, Autodiscover, DNS Propagation, DNS Lookup, TXT Records, CNAME Records).
3. Builder tools generate or transform DNS records (DMARC Builder, SPF Builder, DKIM Generator, CIDR Calculator, Route 53 TXT Splitter).
4. The Bounce Decoder library catalogues SMTP/NDR error codes with provider-specific guidance for Gmail, Microsoft 365, Yahoo, Apple, Comcast, Proofpoint, and Mimecast.

## Analysis Tools

### Full Checker — https://tamingdns.com/

The homepage runs an end-to-end email deliverability scan against any domain: SPF, DKIM, DMARC, MX, blacklists, and an inbox-placement prediction. Results are graded with a compliance score, and each card links to the dedicated single-protocol tool.

### SPF Record Checker — https://tamingdns.com/spf

Fetches the SPF TXT record, expands the full include/redirect tree, counts DNS lookups (the spec hard-cap is 10; exceeding it causes PermError), and validates the all-qualifier (`-all`, `~all`, `?all`, `+all`). Flags duplicate records, deprecated `ptr` mechanisms, and unreachable includes.

**Agent-callable as `check_spf` — WebMCP on this page, and remotely via the `/mcp` server.** A single call returns the canonical result envelope: `grade` (A–F) with `grade_reasons`, `status`, structured `findings[]` with stable codes (`NEAR_LOOKUP_LIMIT`, `LOOKUP_LIMIT_EXCEEDED`, `PLUS_ALL_DANGEROUS`, `NO_ALL_MECHANISM`, `NEUTRAL_ALL_WEAK`, `PTR_MECHANISM_DEPRECATED`, `MULTIPLE_SPF_RECORDS`), the raw `records[]`, and an `analysis` object carrying the expanded include/redirect tree (RFC depth 5 — agents do not need to re-query each include target), the RFC 7208 §4.6.4 lookup count, void-lookup detail, and the terminal `all_qualifier` resolved through any `redirect=` chain. See § Agent Tools below for the full envelope.

Common questions answered on this page:

- What is an SPF record? A DNS TXT entry that lists which servers may send mail for a domain.
- `-all` vs `~all`? `-all` (Fail) tells receivers to reject; `~all` (Softfail) tells them to mark as suspicious. `~all` is more forgiving with forwarding.
- The 10-lookup limit. Each `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` consumes a lookup. Going over causes PermError.
- SPF flattening. Replacing `include:` with direct `ip4:`/`ip6:` drops the lookup count to zero, but is risky to do manually because provider IPs change.
- Parked domains. Use `v=spf1 -all` plus DMARC `p=reject` to prevent spoofing.

### DKIM Checker — https://tamingdns.com/dkim

Probes 500+ known DKIM selectors (Google `google`, M365 `selector1`/`selector2`, plus selectors for Mailchimp, Mailgun, SendGrid, HubSpot, Zoom, Salesforce, etc.), retrieves each public key, validates the RSA key length (1024 bit is weak, 2048 bit is recommended), and checks alignment with SPF and DMARC.

**Agent-callable as `check_dkim` — WebMCP on this page, and remotely via the `/mcp` server.** The WebMCP tool accepts `selectors: "common" | "all"` — common sweeps ~60 top-provider selectors at concurrency 32 (~200ms); all runs the full ~500 plus Mimecast's three-stage date scan (1–3s). Returns the canonical envelope: `grade`, `status`, findings (`NO_DKIM_KEY`, `KEY_TOO_SHORT`, `KEY_WEAK`, `KEY_REVOKED`, `SHA1_ONLY`, `DKIM_TEST_MODE`), and an `analysis` object with per-selector detail (`provider`, `keyType`, `keyLength`, `revoked`, `cname`), wildcard-revocation detection, and non-sending posture. The remote `/mcp` variant validates ONE key instead and requires `{ domain, selector }`. See § Agent Tools below.

### DMARC Record Analyser — https://tamingdns.com/dmarc

Parses every DMARC tag (`v`, `p`, `sp`, `rua`, `ruf`, `pct`, `adkim`, `aspf`, `fo`, `rf`, `ri`), explains policy strength, warns when `p=none` is left in place indefinitely, and verifies external RUA destinations have authorising `_report._dmarc` records.

**Agent-callable as `check_dmarc` — WebMCP on this page, and remotely via the `/mcp` server.** A single call returns the canonical envelope: `grade`, `status`, parsed tags (DMARCbis-aware: `t=`, `np=`, `psd=`), per-recipient external RUA/RUF authorisation status (checks `<checked-domain>._report._dmarc.<reporting-domain>` TXT for each external mailbox, RFC 9990), and dual policy discovery in `analysis.discovery` — the RFC 7489 org-domain ladder (grades anchor to it) and the RFC 9989 §4.10 DNS Tree Walk, with `DISCOVERY_DIVERGENCE` fired when they disagree. Finding codes: `NO_DMARC_RECORD`, `MULTIPLE_DMARC_RECORDS`, `INVALID_TAG`, `POLICY_NONE`, `POLICY_NONE_NO_RUA`, `PCT_BELOW_100`, `SP_NOT_ENFORCED`, `RUA_MISSING_UNDER_ENFORCEMENT`, `EXTERNAL_RUA_UNAUTHORIZED`, `TESTING_MODE`, `DEPRECATED_TAG`, `DISCOVERY_DIVERGENCE`. See § Agent Tools below.

### DMARC Aggregate Report Viewer — https://tamingdns.com/dmarc-report

Upload a DMARC RUA aggregate XML report (plain `.xml` or `.xml.gz`) and view a per-source-IP table showing disposition, SPF alignment, and DKIM alignment. Includes built-in example reports so users can preview output without their own data. Files are parsed in memory and never stored.

### Email Header Analyser — https://tamingdns.com/email-headers

Paste raw email headers to render a visual hop-by-hop trace: each `Received:` line, transit time per hop, and the SPF/DKIM/DMARC results from `Authentication-Results`. Useful for diagnosing why mail landed in spam or took an unusually long path.

### Bounce Decoder — https://tamingdns.com/bounce-decoder

Paste a Non-Delivery Report (NDR) or SMTP error string to get:

- a plain-English explanation of what the code means,
- root-cause categories (addressing, mailbox, system, policy, auth),
- a ranked list of likely causes,
- step-by-step remediation,
- provider-specific notes (Gmail, M365, Yahoo, Apple, Comcast, Proofpoint, Mimecast),
- links to RFCs and provider postmaster pages.

### BIMI Record Checker — https://tamingdns.com/bimi

Looks up `default._bimi.<domain>` TXT record, validates the SVG logo URL (must be SVG Tiny PS, served over HTTPS), and checks the Verified Mark Certificate (VMC) chain. BIMI display additionally requires DMARC enforcement at `quarantine` or `reject`.

**Agent-callable as `check_bimi` — WebMCP on this page, and remotely via the `/mcp` server.** Returns the canonical envelope: `grade`, `status`, findings (`BIMI_NOT_CONFIGURED`, `BIMI_LOGO_NOT_TINY_PS`, `BIMI_VMC_EXPIRED`, `BIMI_DMARC_POLICY_INSUFFICIENT`, …), and an `analysis` object with the parsed tags, logo validation, VMC chain detail, the DMARC prerequisite (DMARCbis `t=` aware), and a per-provider rendering matrix. The grade is computed server-side (X.509 + OCSP), so all surfaces proxy the same engine. See § Agent Tools below.

### DNSSEC Checker — https://tamingdns.com/dnssec

Walks the DNSSEC chain of trust from the root: DS records at the parent zone, DNSKEY at the child, and RRSIG signatures over each RRset. Flags broken delegations, expired signatures, and missing DS at the registrar.

### DANE / TLSA Validator — https://tamingdns.com/dane

Resolves a domain's MX hosts and validates the DANE TLSA records published at `_25._tcp.<mx-host>` (RFC 7672). Decodes each record's certificate usage (the page recommends 3 / DANE-EE for SMTP), selector, and matching type (SHA-256 over exact match), and confirms the TLSA answer was returned with the resolver's AD bit set. Sending MTAs ignore unsigned TLSA records because they can be forged, so an unsigned record is the most serious failure the checker reports. Completes the inbound transport-security set alongside MTA-STS and TLS-RPT.

### MTA-STS Checker — https://tamingdns.com/mta-sts

Verifies the `_mta-sts.<domain>` TXT record per the strict RFC 8461 §3.1 selection rules (case-sensitive leading `v=STSv1`, exactly one record, required 1–32 alphanumeric `id`), fetches the policy file at `https://mta-sts.<domain>/.well-known/mta-sts.txt` WITHOUT following redirects (§3.3), validates the §3.2 policy syntax (`version`/`mode`/`max_age` required, `mx:` required unless mode `none`, `max_age` ≤ 31557600), inspects the policy-host X.509 certificate (§3.3 — a failed cert means compliant senders fetch no policy at all), and validates live MX coverage against the `mx:` patterns (§4.1 — wildcards match exactly one leftmost label; coverage is `all`/`partial`/`none`).

**Agent-callable as `check_mta_sts` — WebMCP on this page, and remotely via the `/mcp` server.** A single call returns the canonical envelope: `grade` (A–F) with `grade_reasons`, `status`, a verdict (`enforced` / `testing` / `reporting_only` / `invalid` / `not_configured`), structured `findings[]` (`MTA_STS_NO_TXT_RECORD`, `MTA_STS_RECORD_INVALID`, `MULTIPLE_MTA_STS_RECORDS`, `MTA_STS_POLICY_UNREACHABLE`, `MTA_STS_POLICY_REDIRECT`, `MTA_STS_POLICY_INVALID`, `MTA_STS_CERT_INVALID`, `MTA_STS_MODE_NONE`, `MTA_STS_MODE_TESTING`, `MTA_STS_MX_MISMATCH`, `MTA_STS_MX_PARTIAL_COVERAGE`, `MTA_STS_MAX_AGE_TOO_LOW`), the raw `records[]`, and an `analysis` object (record / policy incl. `fetch_stage` / cert / MX coverage detail / TLS-RPT + DANE cross-signals). The certificate work is origin-only, so this tool computes once in `MtaStsChecker` and every surface (UI, WebMCP, `/mcp`) relays the same envelope. See § Agent Tools below.

### TLS-RPT Checker — https://tamingdns.com/tls-rpt

Validates the `_smtp._tls.<domain>` TXT record per RFC 8460 §3 — the record must begin with the case-sensitive `v=TLSRPTv1` tag, more than one such record means receivers treat TLS-RPT as not implemented, and `rua=` is required — parses the `rua=mailto:` or `rua=https://` reporting endpoints, probes the MTA-STS and DANE prerequisites over DNS, and explains how TLS-RPT pairs with MTA-STS to surface encryption failures.

**Agent-callable as `check_tls_rpt` — WebMCP on this page, and remotely via the `/mcp` server.** A single call returns the canonical envelope: `grade` (A–F) with `grade_reasons`, `status`, a verdict (`valid` / `partial` / `invalid` / `not_configured`), structured `findings[]` (`TLS_RPT_NO_RECORD`, `TLS_RPT_INVALID_VERSION`, `TLS_RPT_MULTIPLE_RECORDS`, `TLS_RPT_NO_RUA`, `TLS_RPT_RUA_INVALID_URI`, `TLS_RPT_NO_VALID_RUA`, `TLS_RPT_NO_ENFORCEMENT_POLICY`), the raw `records[]`, and an `analysis` object with parsed tags, per-URI rua validation detail, and `prerequisites{mta_sts, dane, dane_mx_host}` where `null` means the probe failed (outage never demotes the grade). See § Agent Tools below.

### MCP Signing Key Checker — https://tamingdns.com/mcp-keys

Renamed from `/mcp` on 2026-06-07. The `/mcp` path now hosts the live TamingDNS MCP server (Streamable HTTP, JSON-RPC 2.0 over POST); see [`/mcp`](https://tamingdns.com/mcp) for setup instructions and § Agent Tools below for the protocol detail.

Reads every apex TXT record on a domain and surfaces entries that match `v=MCPv1; k=<algorithm>; p=<base64-public-key>`, the signing-key convention published by the MCP (Model Context Protocol) Registry. Parses each record's tags, validates the algorithm (`ed25519` or `ecdsap384`), checks the base64-decoded public key against the required byte length (32 bytes for ed25519; 49 bytes for an ecdsap384 compressed point with leading `0x02`/`0x03`), and computes a SHA-256 fingerprint over the raw published bytes. Multiple records at the apex are supported (typical for key rotation or multiple MCP servers under one domain). The format is currently in preview per the MCP Registry docs, not an RFC.

### WHOIS / RDAP Lookup — https://tamingdns.com/whois

Modern RDAP-first WHOIS lookup. Returns registrar, registration/expiry/updated dates, nameservers, and EPP status codes (`clientTransferProhibited`, `serverHold`, etc.) with a plain-English explanation of each.

### Microsoft 365 DNS Audit — https://tamingdns.com/m365-check

One-click audit tailored to M365 / Exchange Online tenants. Checks the exact records Microsoft expects:

- SPF: `v=spf1 include:spf.protection.outlook.com -all`
- DKIM: `selector1` and `selector2` CNAMEs
- DMARC: presence + policy
- MX: `<tenant>-com.mail.protection.outlook.com`
- MTA-STS: optional but recommended
- Autodiscover: `autodiscover.<domain>` CNAME → `autodiscover.outlook.com`

### Google Workspace DNS Audit — https://tamingdns.com/google-workspace-check

One-click audit tailored to Google Workspace / Gmail-hosted domains. Checks:

- SPF: `v=spf1 include:_spf.google.com ~all`
- DKIM: `google._domainkey` selector (default Workspace selector)
- DMARC: presence + policy
- MX: the five `*.googlemail.com` (or `aspmx.l.google.com`) hosts
- MTA-STS: optional but recommended

## Diagnostic Tools

### Blacklist / RBL Checker — https://tamingdns.com/blacklist

Queries an IP or domain against 12+ major real-time blacklists and reputation lists (Spamhaus ZEN, Barracuda BRBL, SORBS, SpamCop, etc.). Listings include direct delisting links to each provider's request form.

### MX Record Inspector — https://tamingdns.com/mx

Resolves all MX hosts in priority order, fetches A/AAAA for each, validates PTR for each address, and verifies Forward-Confirmed reverse DNS (FCrDNS). Detects the email provider from MX hostnames (M365, Workspace, Zoho, Fastmail, Proofpoint, Mimecast, Bitdefender, etc.). Flags IP-literal (RFC 5321 §5) and CNAME (RFC 2181 §10.3) MX targets, the null MX (RFC 7505) and a null MX wrongly mixed with real records, the implicit MX via the apex A/AAAA, and the MTA-STS / TLS-RPT / DANE transport-security posture. Grades A-F. Agent-callable as `check_mx` (WebMCP + remote MCP) — same `mx-core.js` engine as the UI.

### Reverse DNS / PTR / FCrDNS Checker — https://tamingdns.com/reverse-dns

Looks up the PTR for any IPv4 or IPv6 address, then re-resolves that hostname forward to confirm it points back to the same IP. FCrDNS is the lightweight authentication check most mail servers run before accepting connections; failing it commonly produces SMTP `550 5.7.25`.

### IP / ASN / GeoIP Lookup — https://tamingdns.com/ip-info

RDAP-based IP information: network range, ASN, organisation, country, abuse contact, and PTR. Replaces legacy WHOIS for IP queries.

### What's My IP — Public IP Diagnostic — https://tamingdns.com/whats-my-ip

Zero-input deliverability triage page. Auto-detects the visitor's public IPv4 or IPv6 address from the connection, then runs a battery of checks in parallel and renders them progressively:

- RDAP card: ASN, AS name, ISP/network, CIDR, country, abuse contact, PTR.
- Reverse DNS / FCrDNS verdict (pass, forward mismatch, or no PTR).
- DNSBL scan against 15+ major blocklists (Spamhaus, Barracuda, SpamCop, etc.).
- IPv6 connectivity test via dedicated single-family subdomains (`v4.tamingdns.com` A-only, `v6.tamingdns.com` AAAA-only), so the result distinguishes dual-stack, IPv4-only, IPv6-only, and broken-IPv6 setups independent of which family the page loaded over.
- Contextual one-click CTAs: a DNSBL hit links to `/blacklist` with the IP prefilled; a passing PTR offers prefilled SPF, DMARC, and MX lookups for the registrable domain; an FCrDNS mismatch links to `/reverse-dns`; a hosting/cloud ASN gets a note about reputation considerations; mail-server-style PTRs (`mail.*`, `mx.*`, `smtp.*`) surface mail-specific guidance.

Different from `/ip-info` in that `/ip-info` requires manual entry of an IP and is focused on the RDAP deep-dive, while `/whats-my-ip` auto-detects the visitor's own IP and combines RDAP with FCrDNS, IPv6 connectivity, and DNSBL on a single page with contextual next-step links. Use `/whats-my-ip` when an admin asks "is my IP OK?" without a specific question; use `/ip-info` when they already know the IP they want to investigate.

Deliberately does not show city-level GeoIP (RDAP country only) and does not store the visitor's IP.

### Website Checker — https://tamingdns.com/website

Single-hostname web-layer triage. Pulls together the diagnostics an IT admin or web developer would otherwise gather from SSL Labs, Mozilla Observatory, `curl -v`, and `openssl s_client`. Probes run server-side from a single vantage point with a browser-side DoH consensus overlay for the DNS portion (degrades browser → Cloudflare Worker → PHP origin if the visitor's network blocks DoH).

Cards rendered, in canonical order:

- Resolver-disagreement banner (only if the two browser-side DoH resolvers see different A-record sets — common on GeoDNS-fronted sites).
- Verdict strip (`ok` / `warn` / `fail`) and a "Why this verdict?" reasons box.
- Spec compliance chip row: one chip per signal (TLS reachable, WebPKI valid, hostname matches cert, cert not expired, HTTPS reachable, HTTP/2, HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy, CAA published). No overall letter grade — every signal stands on its own.
- DNS resolution table: A + AAAA + reverse DNS + ASN/org/country per IP (Team Cymru WHOIS-over-DNS, no API key).
- CAA records on the apex.
- HTTPS redirect chain: every hop's URL, status code, HTTP version, and TTFB. Cross-domain redirects (`example.co.za` → `www.examplebank.co.za`) are captured.
- TLS certificate: subject CN, issuer DN, full SAN list, validity window, days remaining, SAN-vs-hostname check, WebPKI chain verdict, self-signed flag, negotiated TLS version, cipher, signature algorithm, chain depth. Two-pass cert capture (`verify_peer` on, then off for display when verification fails) means expired and self-signed certs still surface their metadata instead of being hidden behind a generic error.
- HTTP security headers: HSTS (`max-age`, `includeSubDomains`, `preload`), CSP (presence + `unsafe-inline` sentinel check), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Each gets its own pass/warn/fail pill.
- Cookies: per `Set-Cookie`, the `Secure` / `HttpOnly` / `SameSite` flags.
- Transport timings: DNS, TCP connect, TLS handshake, TTFB, total wall-clock for the final hop.
- Related-tools row deep-linked to `/dns-lookup`, `/dns-propagation`, `/cname`, `/dnssec`, `/mx`, `/mta-sts`, `/blacklist`, plus per-IP links to `/ip-info` and `/reverse-dns`.

Deliberately not done: full CSP grading (a shallow CSP scorecard is worse than no scorecard — we check presence and flag `unsafe-inline`, nothing deeper), QUIC handshake (HTTP/3 is detected from `Alt-Svc: h3=` advertisement only), multi-vantage probing. The intro and FAQ say so plainly.

### Autodiscover / Autoconfig Checker — https://tamingdns.com/autodiscover

Probes the four endpoints mail clients use to auto-configure themselves:

- Outlook Autodiscover: `autodiscover.<domain>` CNAME, A record, SRV `_autodiscover._tcp`, and the HTTPS endpoint at `/autodiscover/autodiscover.xml`.
- Thunderbird Autoconfig: `autoconfig.<domain>` CNAME, `config-v1.1.xml`, and the ISP `.well-known/autoconfig/mail/config-v1.1.xml`.

### DNS Propagation Checker — https://tamingdns.com/dns-propagation

Queries A, MX, TXT, and NS records simultaneously across global resolvers in South Africa (often missing from competitor tools), Europe, the Americas, and Asia-Pacific, so users can see how a recently-changed record has propagated.

### DNS Lookup Tool — https://tamingdns.com/dns-lookup

Generic record query for A, AAAA, MX, TXT, CNAME, NS, SOA, SRV, CAA, and PTR via Google (8.8.8.8 / 8.8.4.4), Cloudflare (1.1.1.1 / 1.0.0.1), or Quad9 (9.9.9.9). Useful for comparing answers across resolvers.

### TXT Record Checker — https://tamingdns.com/txt

Reads every TXT record at the domain apex in a single query and classifies each (SPF, plus verification tokens for Google, Microsoft 365, Atlassian, Adobe, Stripe and dozens more), then probes well-known prefixed locations: `_dmarc` (DMARC), `_mta-sts` (MTA-STS), `_smtp._tls` (TLS-RPT), `default._bimi` (BIMI), `_adsp._domainkey`, `_acme-challenge`, `_amazonses` and other ownership tokens. DKIM selectors are not enumerated here; the page links to the dedicated DKIM checker for that.

### CNAME Record Checker — https://tamingdns.com/cname

Probes ~70 common sub-hosts (www, autodiscover, enterpriseregistration, lyncdiscover, cdn, status, help, shop, mail, and more), follows each CNAME alias to its target, and detects the vendor behind the target (Microsoft 365, Google, Cloudflare, Shopify, Zendesk, SendGrid, etc.). Flags dangling CNAMEs whose target does not resolve (broken links / subdomain-takeover risk). DKIM CNAME delegations are left to the dedicated DKIM checker. Includes a custom hostname lookup.

## Builder Tools

### DMARC Record Builder — https://tamingdns.com/dmarc-builder

Guided form for assembling a DMARC TXT record. Walks through the standard staged rollout (`p=none` for monitoring → `p=quarantine` with `pct=` ramp → `p=reject`), separate `sp=` for subdomains, alignment modes (`adkim=s/r`, `aspf=s/r`), reporting addresses (`rua=`, `ruf=`), and failure reporting options (`fo=0/1/d/s`).

### SPF Record Builder — https://tamingdns.com/spf-builder

Generates a validated SPF TXT record by selecting from 15+ providers (Google Workspace, Microsoft 365, Mailchimp, Mailgun, SendGrid, Amazon SES, HubSpot, Zoho, etc.) or by adding custom `include:`, `a:`, `mx:`, `ip4:`, `ip6:` entries. Live-counts DNS lookups so users stay below the 10-lookup limit.

### DKIM Key Generator & Record Builder — https://tamingdns.com/dkim-generator

Generates a DKIM key pair entirely in the browser via the Web Crypto API. The private key is never transmitted to or stored on the server. Supports RSA 2048 (recommended), RSA 1024 (legacy compatibility), and Ed25519 (RFC 8463). Outputs the PKCS#8 private-key PEM for the signing platform plus the public-key DNS record: name `<selector>._domainkey.<domain>` and value `v=DKIM1; k=rsa; p=<base64-SPKI>` (or `k=ed25519`), with an optional 255-character split for AWS Route 53 and BIND-style zones. Pairs with the DKIM checker for verification after publishing.

### Subnet / CIDR Calculator — https://tamingdns.com/cidr

Pure-JavaScript IPv4 and IPv6 subnet calculator: network address, broadcast (IPv4), first/last host, total addresses, subnet mask, wildcard mask, and prefix length. Handy when populating SPF `ip4:` / `ip6:` mechanisms. All maths is done in the browser; nothing is sent to a server.

### Route 53 TXT Splitter — https://tamingdns.com/route53-splitter

AWS Route 53 enforces a 255-character limit per TXT string and requires multiple strings to be quoted and concatenated. This tool auto-splits long DKIM, SPF, DMARC, BIMI, or arbitrary TXT records into Route 53-formatted, quoted 255-character chunks ready to paste into the console or Terraform.

## Reference Pages

Four standalone reference hubs covering the building blocks of email DNS. Each hub page links to per-mechanism, per-tag, per-RBL, or per-record-type detail pages with syntax, examples, and common pitfalls. The detail pages are linked from the relevant analysis tool so users land on the right concept when a check fails.

### SPF Syntax Guide — https://tamingdns.com/spf-syntax

Reference for every mechanism, modifier, and qualifier defined in RFC 7208. Each detail page covers syntax, lookup cost (toward the 10-lookup limit), and common misuse.

- Mechanisms: https://tamingdns.com/spf-syntax/include, /a, /mx, /ip4, /ip6, /ptr, /exists, /all
- Modifiers: https://tamingdns.com/spf-syntax/redirect, /exp
- Qualifiers: https://tamingdns.com/spf-syntax/qualifier-pass, /qualifier-fail, /qualifier-softfail, /qualifier-neutral

### DMARC Tags Reference — https://tamingdns.com/dmarc-tags

Reference for every DMARC record tag as defined in RFC 9989 (DMARCbis) and its predecessor RFC 7489. Each detail page explains valid values, default behaviour when the tag is omitted, and how the tag interacts with alignment and reporting.

- Core policy: https://tamingdns.com/dmarc-tags/v, /p, /sp, /pct, /t, /np, /psd
- Reporting: https://tamingdns.com/dmarc-tags/rua, /ruf, /rf, /ri, /fo
- Alignment: https://tamingdns.com/dmarc-tags/adkim, /aspf

### DMARCbis (DMARC 2.0) — https://tamingdns.com/dmarcbis

Conceptual overview of the May 2026 revision that replaced RFC 7489 (Informational, 2015) with RFC 9989 (core), 9990 (aggregate reporting), and 9991 (failure reporting) as IETF Proposed Standards. Existing DMARC records continue to work unchanged; the changes are mostly receiver-side or additive.

Key changes documented on the page:
- DNS Tree Walk replaces the Public Suffix List for organizational-domain detection. Receivers walk up to five labels of `_dmarc.<name>` from the From header's domain toward the root.
- Three new tags: `np=` (policy for non-existent subdomains), `t=` (testing mode, replaces `pct=` for staged rollout), `psd=` (public-suffix flag for registries, promoted from the experimental RFC 9091 into core).
- Three tags removed from core: `pct=` (removed entirely; use `t=y`), `rf=` (removed; only AFRF was ever used), `ri=` (relocated to RFC 9990).
- SPF alignment now checks MAIL FROM only; the HELO fallback in RFC 7489 is dropped.
- Status change: RFC 7489 was Informational, RFC 9989/9990/9991 are Proposed Standards.

Use this page when an admin asks "what is DMARC 2.0?" or "do I need to update my DMARC record?". Use `/dmarc-tags` and the per-tag detail pages (`/dmarc-tags/np`, `/dmarc-tags/t`, `/dmarc-tags/pct`, etc.) for the syntax-level reference.

### RBL / Blacklist Directory — https://tamingdns.com/rbl

Directory of every real-time blacklist queried by the Blacklist Checker. Each detail page covers what the list flags, how a listing is triggered, and the delisting workflow.

- IP-based RBLs: https://tamingdns.com/rbl/spamhaus-zen, /spamhaus-pbl, /barracuda, /spamcop, /psbl, /uceprotect-l1, /uceprotect-l2, /wpbl, /cbl-abuseat, /gbudb, /s5h, /spfbl
- Domain-based DBLs: https://tamingdns.com/rbl/spamhaus-dbl, /surbl, /uribl-black, /abuseat-dbl, /nordspam-dbl

### DNS Record Types — https://tamingdns.com/dns-record-types

Reference for the DNS record types that matter for email deliverability. Each detail page shows the wire format, typical TTLs, and how the record fits into authentication or routing.

- Address: https://tamingdns.com/dns-record-types/a, /aaaa, /cname
- Routing: https://tamingdns.com/dns-record-types/mx, /ns, /soa, /ptr
- Email TXT: https://tamingdns.com/dns-record-types/txt, /txt-spf, /txt-dkim, /txt-dmarc, /txt-bimi, /txt-mta-sts
- Security: https://tamingdns.com/dns-record-types/tlsa, /caa

## Articles

Long-form working notes on email deliverability, DNS standards, and the corners of the spec that decide whether mail lands. Single-author (Paul Ogier), written for IT administrators and email-ops engineers. Index at https://tamingdns.com/articles with tag filtering; full-content RSS 2.0 at https://tamingdns.com/articles/feed.xml.

<!-- BEGIN:articles -->
- BIMI: how to set it up, and why you probably shouldn't bother yet — https://tamingdns.com/articles/bimi-vanity-or-worth-it
  What it takes to get a BIMI logo into the inbox: enforced DMARC, an SVG Tiny PS logo, and an optional paid VMC certificate. Argues that BIMI is mostly vanity right now because it does nothing for deliverability (the logo rides on DMARC enforcement, which is where the actual protection comes from), client support is patchy, and the VMC costs around a thousand dollars a year. Worth it mainly for high-volume consumer brands with a registered trademark.
- DMARC from p=none to p=reject, without breaking real mail — https://tamingdns.com/articles/dmarc-none-to-reject
  The safe, staged path to DMARC enforcement. p=none only sends reports; it protects nothing. Read the aggregate reports to inventory every sender, set up aligned DKIM (or SPF) for each legitimate one, then ratchet none → quarantine → reject over a few weeks rather than jumping straight to reject and bouncing your own mail. Covers the pct tag's removal in DMARCbis (RFC 9989), the sp subdomain-inheritance gotcha, and why you keep the rua address after reaching reject.
- Everything "passes" and the mail still lands in spam. Why? — https://tamingdns.com/articles/spam-despite-passing
  A clean SPF, DKIM and DMARC pass proves identity to the receiving server, not that the mail reaches the inbox. Inbox placement is a separate decision driven by signals no DNS checker measures: domain and IP reputation, recipient engagement (opens, replies, marking as not-spam vs deletes and complaints), content and list hygiene, and complaint rate against Gmail's 0.3% bulk-sender threshold. Explains why Google Postmaster Tools can show 0% spam while mail sits in Junk (it reports complaint rate, not folder placement, and Junked mail draws no complaints), and how to diagnose the real cause by reading the receiver's verdict in raw headers (Authentication-Results, spam-score headers), reading DMARC aggregate reports for unauthorised or unaligned senders, and checking domain and IP against Spamhaus. Ends with a warm-up section for cold domains and VPS IPs and an ordered remediation checklist.
- From no MTA-STS to enforce, without blackholing your own mail — https://tamingdns.com/articles/mta-sts-tls-rpt-to-enforce
  A staged rollout for SMTP TLS policy: publish TLS-RPT first (zero risk), then MTA-STS in testing mode, read the failure reports, and only then switch to enforce. Covers the pitfalls that blackhole mail: the policy file 404ing, an invalid certificate on the mta-sts host, forgetting to bump the policy id, and MX-list drift. Includes M365 single-tenant and mixed-MX scenarios.
- Rotating Microsoft 365 DKIM to 2048-bit in PowerShell, and the gotcha that leaves half the job undone — https://tamingdns.com/articles/m365-dkim-2048-powershell
  M365 rotates DKIM with genuine zero downtime via two selectors (selector1/selector2) as CNAMEs to Microsoft-hosted keys. The trap: Rotate-DkimSigningConfig -KeySize 2048 only upgrades the selector that isn't currently active, so you must run it a second time for the other selector, and not back to back because rotation takes up to 96 hours before the new key signs. If both selectors already read 2048 there is nothing to upgrade, but a plain Rotate-DkimSigningConfig is still worth running for six-monthly freshness (M3AAWG). Contrast piece to the Google Workspace article.
- Upgrading Google Workspace DKIM to 2048-bit, without believing the zero-downtime myth — https://tamingdns.com/articles/google-workspace-dkim-2048
  Google Workspace allows only one DKIM key per domain at a time, so the M365-style two-selector zero-downtime swap is impossible there; generating a new key drops authentication until you publish the new TXT and click Start authentication. The fix is to make the unavoidable gap harmless: lower the google._domainkey TXT TTL to 300s the day before, confirm SPF is valid and aligned as the DMARC fallback during the gap, and do the swap out of hours. Why bother: 1024-bit is below the M3AAWG 2048 standard, and M3AAWG recommends rotating keys at least every six months regardless of size.
- What on earth is DNSSEC, and should your business care? — https://tamingdns.com/articles/what-is-dnssec
  A plain-English explainer: DNSSEC signs DNS answers so resolvers can prove they are genuine, defeating cache poisoning. It authenticates, it does not encrypt. Covers the DS/DNSKEY/RRSIG chain of trust, the real benefits (hijack resistance, the foundation under DANE, compliance), and the honest costs (key management, the registrar DS step, and a total-failure mode if a key rollover is fumbled).
- Why Microsoft 365 and Outlook are blocking your mail in 2026 — https://tamingdns.com/articles/microsoft-365-blocking-mail
  There are two Microsoft worlds and they block for different reasons: consumer Outlook.com/Hotmail enforces a May 2025 rule requiring aligned SPF/DKIM/DMARC above 5,000 messages a day (550 5.7.515), while Microsoft 365 tenants gatekeep on sending-IP reputation at the SMTP edge (Exchange Online Protection) regardless of passing authentication (550 5.4.1). Covers telling the two apart from the NDR's recipient domain and reporting host, the RESOLVER/STOREDRV/QUEUE component prefixes Microsoft uses in bounce diagnostics, the 5.7.23/5.7.26/5.7.25 SPF/alignment/PTR codes, reading Authentication-Results and the X-Forefront-Antispam-Report SCL header, and an ordered remediation checklist by code.
<!-- END:articles -->

## Bounce Decoder Provider Hubs

Each provider hub explains the rejection patterns specific to that gateway, with links to the underlying SMTP code pages.

- Gmail / Google Workspace (https://tamingdns.com/bounce-decoder/gmail): DMARC failures (`5.7.26`), bulk-sender complaint blocks (`4.7.28`), new-sender holds (`4.7.29`), and the post-Feb-2024 bulk sender requirements (one-click unsubscribe, complaint rate <0.3%, DMARC enforcement).
- Microsoft 365 / Outlook (https://tamingdns.com/bounce-decoder/microsoft): `RESOLVER` and `STOREDRV` NDR codes from Exchange Online, `5.7.13` (account disabled), `5.7.14` (Modern Auth required), `5.4.1` (sender reputation block).
- Yahoo / AOL (https://tamingdns.com/bounce-decoder/yahoo): `[TSS]` (Temporary Spam Suspect) and `[TS]` deferral codes, the Yahoo Sender Hub, and bulk-sender requirements that mirror Gmail's.
- Apple iCloud Mail (https://tamingdns.com/bounce-decoder/apple): iCloud rejection patterns, Hide My Email relay errors, and the contact path for Apple delisting.
- Comcast / Xfinity (https://tamingdns.com/bounce-decoder/comcast): Sender Score / IP reputation blocks, rate limits, SPF failures, and the Comcast Postmaster delisting workflow.
- Proofpoint (https://tamingdns.com/bounce-decoder/proofpoint): `pphosted.com` rejection patterns, spam policy blocks, reputation filters, and the Proofpoint Sender Review form.
- Mimecast (https://tamingdns.com/bounce-decoder/mimecast): `mimecast.com` rejection patterns, anti-spam blocks, greylisting, and the Mimecast sender portal.

## SMTP Bounce Code Library

The Bounce Decoder library at https://tamingdns.com/bounce-codes catalogues both bare SMTP codes (e.g. 421, 500, 550, 554) and enhanced status codes (RFC 3463 `class.subject.detail`). Each entry has a permanent SEO page at `/bounce-decoder/<slug>` with a plain-English explanation, causes, remediation steps, provider-specific notes, example NDRs, and related codes.

### Permanent (5.x.x) — Addressing

- 550 5.1.1 — Mailbox Does Not Exist — https://tamingdns.com/bounce-decoder/550-5-1-1-mailbox-does-not-exist
- 550 5.1.0 — Other Address Status — https://tamingdns.com/bounce-decoder/550-5-1-0-other-address-status
- 550 5.1.2 — Bad Destination Domain — https://tamingdns.com/bounce-decoder/550-5-1-2-bad-destination-domain
- 501 5.1.3 — Invalid Address Syntax — https://tamingdns.com/bounce-decoder/501-5-1-3-invalid-address-syntax
- 551 5.1.6 — Mailbox Has Moved — https://tamingdns.com/bounce-decoder/551-5-1-6-mailbox-has-moved
- 501 5.1.8 — Bad Sender Address — https://tamingdns.com/bounce-decoder/501-5-1-8-bad-sender-address

### Permanent (5.x.x) — Mailbox

- 550 5.2.0 — Other Mailbox Status — https://tamingdns.com/bounce-decoder/550-5-2-0-other-mailbox-status
- 550 5.2.1 — Mailbox Disabled — https://tamingdns.com/bounce-decoder/550-5-2-1-mailbox-disabled
- 552 5.2.2 — Mailbox Over Quota — https://tamingdns.com/bounce-decoder/552-5-2-2-mailbox-over-quota
- 552 5.2.3 — Message Too Large for Mailbox — https://tamingdns.com/bounce-decoder/552-5-2-3-message-too-large
- 550 5.2.4 — Mailing List Expansion Problem — https://tamingdns.com/bounce-decoder/550-5-2-4-mailing-list-expansion-problem

### Permanent (5.x.x) — Mail System

- 550 5.3.0 — Other Mail System Status — https://tamingdns.com/bounce-decoder/550-5-3-0-other-mail-system-status
- 421 5.3.2 — System Not Accepting Messages — https://tamingdns.com/bounce-decoder/421-5-3-2-system-not-accepting-messages
- 552 5.3.4 — Message Too Big for System — https://tamingdns.com/bounce-decoder/552-5-3-4-message-too-big-for-system

### Permanent (5.x.x) — Network / Routing

- 550 5.4.1 — Recipient Address Rejected — https://tamingdns.com/bounce-decoder/550-5-4-1-recipient-address-rejected
- 550 5.4.4 — No Route to Destination — https://tamingdns.com/bounce-decoder/550-5-4-4-no-route-to-destination
- 554 5.4.6 — Routing Loop Detected — https://tamingdns.com/bounce-decoder/554-5-4-6-routing-loop-detected
- 550 5.4.7 — Delivery Time Expired — https://tamingdns.com/bounce-decoder/550-5-4-7-delivery-time-expired

### Permanent (5.x.x) — Security / Policy / Auth

- 550 5.7.0 — Message Rejected (Policy) — https://tamingdns.com/bounce-decoder/550-5-7-0-message-rejected-policy
- 550 5.7.1 — Message Rejected by Policy — https://tamingdns.com/bounce-decoder/550-5-7-1-message-rejected-not-authorized
- 550 5.7.2 — Mailing List Expansion Prohibited — https://tamingdns.com/bounce-decoder/550-5-7-2-mailing-list-expansion-prohibited
- 535 5.7.8 — Authentication Credentials Invalid — https://tamingdns.com/bounce-decoder/535-5-7-8-authentication-credentials-invalid
- 534 5.7.9 — Authentication Mechanism Too Weak — https://tamingdns.com/bounce-decoder/534-5-7-9-authentication-mechanism-too-weak
- 550 5.7.13 — User Account Disabled — https://tamingdns.com/bounce-decoder/550-5-7-13-user-account-disabled
- 550 5.7.14 — Trust Relationship Required — https://tamingdns.com/bounce-decoder/550-5-7-14-trust-relationship-required
- 550 5.7.23 — SPF Validation Failed — https://tamingdns.com/bounce-decoder/550-5-7-23-spf-validation-failed
- 550 5.7.24 — SPF Validation Error (PermError) — https://tamingdns.com/bounce-decoder/550-5-7-24-spf-validation-error-permerror
- 550 5.7.25 — Reverse DNS (PTR) Validation Failed — https://tamingdns.com/bounce-decoder/550-5-7-25-reverse-dns-validation-failed
- 550 5.7.26 — DMARC Policy Violation — https://tamingdns.com/bounce-decoder/550-5-7-26-dmarc-policy-violation

### Temporary (4.x.x)

- 450 4.2.1 — Rate Limit: Try Again Later — https://tamingdns.com/bounce-decoder/450-4-2-1-rate-limit-try-again-later
- 452 4.2.2 — Mailbox Full (Temporary) — https://tamingdns.com/bounce-decoder/452-4-2-2-mailbox-full-temporary
- 421 4.3.2 — System Not Accepting Mail — https://tamingdns.com/bounce-decoder/421-4-3-2-system-not-accepting-mail
- 421 4.4.1 — No Answer from Host — https://tamingdns.com/bounce-decoder/421-4-4-1-no-answer-from-host
- 421 4.4.2 — Bad Connection — https://tamingdns.com/bounce-decoder/421-4-4-2-bad-connection
- 421 4.4.7 — Message Expired in Queue — https://tamingdns.com/bounce-decoder/421-4-4-7-message-expired-in-queue
- 421 4.7.0 — Temporary Policy Rejection — https://tamingdns.com/bounce-decoder/421-4-7-0-temporary-policy-rejection
- 451 4.7.1 — Temporary Auth / Policy Hold — https://tamingdns.com/bounce-decoder/451-4-7-1-temporary-auth-policy-hold
- 421 4.7.28 — Blocked: High Complaint Rate — https://tamingdns.com/bounce-decoder/421-4-7-28-blocked-high-complaint-rate
- 421 4.7.29 — Blocked: Local Policy (New Sender) — https://tamingdns.com/bounce-decoder/421-4-7-29-blocked-local-policy-new-sender

### Bare SMTP Codes

- 421 — Service Temporarily Unavailable — https://tamingdns.com/bounce-decoder/421-service-temporarily-unavailable
- 450 — Requested Action Not Taken (Temporary) — https://tamingdns.com/bounce-decoder/450-requested-action-not-taken-temporary
- 451 — Local Processing Error (Temporary) — https://tamingdns.com/bounce-decoder/451-local-processing-error-temporary
- 452 — Insufficient Storage (Temporary) — https://tamingdns.com/bounce-decoder/452-insufficient-storage-temporary
- 500 — SMTP Syntax Error — https://tamingdns.com/bounce-decoder/500-smtp-syntax-error
- 501 — Bad Parameter or Argument — https://tamingdns.com/bounce-decoder/501-bad-parameter-or-argument
- 550 — Generic Delivery Failure — https://tamingdns.com/bounce-decoder/550-generic-delivery-failure
- 554 — Transaction Failed — https://tamingdns.com/bounce-decoder/554-transaction-failed

## Standards and Background Reading

The tools follow these IETF standards:

- SPF — RFC 7208
- DKIM — RFC 6376
- DMARC — RFC 9989 (DMARCbis), RFC 9990 (Aggregate Reporting), RFC 9991 (Failure Reporting); supersedes RFC 7489
- ARC — RFC 8617
- BIMI — Internet-Draft (draft-brand-indicators-for-message-identification)
- MTA-STS — RFC 8461
- TLS-RPT — RFC 8460
- DNSSEC — RFC 4033 / 4034 / 4035
- RDAP — RFC 7480
- Enhanced SMTP status codes — RFC 3463 / 5248

## Agent Tools (MCP server — remote)

TamingDNS runs a remote MCP server at `https://tamingdns.com/mcp`. Streamable HTTP, JSON-RPC 2.0 over POST, stateless, no auth. Targets MCP spec `2025-11-25` and the 2026-07-28 RC.

Endpoints:
- `POST https://tamingdns.com/mcp` — JSON-RPC dispatcher (`initialize`, `tools/list`, `tools/call`, `prompts/list`, `prompts/get`, `resources/list`, `resources/read`)
- `GET  https://tamingdns.com/mcp` — human setup page (connect snippets for Claude Code, Claude Desktop, Cursor, Raycast, curl)
- `GET  https://tamingdns.com/.well-known/mcp/server-card.json` — SEP-2127 server card
- `GET  https://tamingdns.com/mcp/resources/finding-codes` — browser-friendly view of the finding-code registry (the MCP-spec path is via `resources/read`)

Tools (Phase 2 cutover — Jun 2026):
- `check_spf` (annotations: readOnlyHint, destructiveHint=false, idempotentHint, openWorldHint). Input `{ domain }`. Output: canonical envelope (`docs/result-schema.md`).
- `check_dkim`. Input `{ domain, selector }`. Output: canonical envelope.
- `check_dmarc`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons.
- `check_tls_rpt`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons.
- `check_mta_sts`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons.
- `check_bimi`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons.
- `check_mx`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons and an `analysis` block (per-host A/AAAA/PTR/FCrDNS/DANE/provider + MTA-STS/TLS-RPT prerequisites). Edge-native — the Worker runs the shared `mx-core.js` over edge DoH.
- `check_dnssec`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons and an `analysis` block (zone-by-zone chain walk, the 4-resolver AD-bit matrix, NSEC3/CDS state). Origin-proxy — the chain walk lives in `app/lib/DnssecChecker.php`.
- `check_dane`. Input `{ domain }`. Output: canonical envelope with grade A-F + reasons and an `analysis` block (per-host TLSA records + DNSSEC status). Origin-proxy — `app/lib/DaneChecker.php` reads the binary-DoH AD bit.
- `analyze_email_headers`. Input `{ headers }` (a raw header block, not a domain). Output: canonical envelope with a phishing verdict; the echoed input is a digest only, so raw headers are never returned. Hybrid — parsed/enriched at the PHP origin, canonical envelope built at the edge.

Tool results conform to `docs/result-schema.md` and are returned as both `structuredContent` (machine-readable JSON, schema-validated) AND a `text` content block (RFC-recommended dual-emit for backwards-compatibility with older MCP clients). The output schema is JSON Schema draft 2020-12.

Prompts:
- `audit_email_auth` — single-domain audit that orchestrates SPF + DMARC + DKIM (selectors google, selector1, selector2, default) + BIMI into a consolidated remediation plan.

Resources:
- `mcp://tamingdns/resources/finding-codes` — the canonical finding-code registry, served from `docs/finding-codes.md`.

Rate limits: per IP, a few dozen calls a minute — enough for interactive use and scheduled checks, not bulk scanning. Results are cached 60 s per input, so a retry inside that window is free.

## Agent Tools (WebMCP)

TamingDNS exposes a small set of tools via the WebMCP API (`document.modelContext.registerTool`) so AI agents can invoke them directly instead of scraping the page DOM. Tools are registered on first load of the relevant tool page. Every tool returns structured JSON matching the documented schema. All tools are read-only, run client-side via DNS-over-HTTPS (Google, Cloudflare, Quad9, plus a fallback Worker), and are rate-limited per origin.

WebMCP is currently experimental: Chrome 149+ with `chrome://flags/#enable-webmcp-testing` enabled, or under the origin trial.

Every WebMCP tool returns the same canonical result envelope as the remote `/mcp` server (`docs/result-schema.md`) — one isomorphic engine per tool, so the web UI, WebMCP, and the MCP server grade identically. There is no schema drift between surfaces by construction:

```
{
  "tool":           "check_dmarc",
  "tool_version":   "2.3.0",
  "schema_version": 1,
  "input":          { "domain": "example.com" },
  "status":         "warn",                      // pass | warn | fail | info
  "verdict":        "monitoring",                // tool-specific string
  "grade":          "C",                         // A | B | C | D | F
  "grade_reasons":  ["p=none — monitoring only; spoofed mail is not blocked."],
  "findings": [
    { "code": "POLICY_NONE", "severity": "warn",
      "title": "Policy is p=none",
      "explanation": "Receivers authenticate but take no action on failures.",
      "remediation": "Move to p=quarantine once reports look clean." }
  ],
  "records": [
    { "name": "_dmarc.example.com.", "type": "TXT", "ttl": 300,
      "data": "v=DMARC1; p=none; rua=mailto:dmarc@example.com" }
  ],
  "analysis":   { /* tool-specific structured detail — see each tool below */ },
  "timestamp":  "2026-06-10T07:00:00Z",
  "provenance": { "operated_by": "OSH.co.za" },
  "error":      null                             // or { code, message, retriable }
}
```

`findings[].code` values are a stable public API. The full registry lives at https://tamingdns.com/mcp/resources/finding-codes and is also served via MCP `resources/read` (`mcp://tamingdns/resources/finding-codes`).

### `check_spf` — https://tamingdns.com/spf

Input: `{ "domain": "example.com" }`.

The `analysis` object carries the SPF-specific detail: the expanded include/redirect `tree` (nested `{ domain, record, mechanisms[] }`, RFC depth 5 — agents do not need to re-query each include target), `lookup_count` (true DNS-resolving terms across the whole tree, RFC 7208 §4.6.4 cap 10), `void_lookups{count, items[]}`, `mechanisms_by_type` (include / ip4 / ip6 / a / mx / ptr / exists / redirect / all / other), flattened `ip4[]` / `ip6[]` ranges from the whole tree, `redirect_chain[]` and `effective_domain` (RFC 7208 §6.1 — the domain whose record determined the verdict), `all_qualifier` (terminal qualifier after following `redirect=`, e.g. `meta.com → _spf.fb.com → -all`), and `multiple_records`.

Finding codes: `NO_SPF_RECORD` (info), `NEAR_LOOKUP_LIMIT` (warn, 9+ of 10 lookups), `LOOKUP_LIMIT_EXCEEDED` (error, PermError), `VOID_LOOKUP_LIMIT_EXCEEDED` (error, PermError), `PLUS_ALL_DANGEROUS` (error), `NEUTRAL_ALL_WEAK` (warn), `NO_ALL_MECHANISM` (warn), `REDIRECT_AND_ALL_CONFLICT` (warn), `PTR_MECHANISM_DEPRECATED` (warn, RFC 7208 §5.5), `MULTIPLE_SPF_RECORDS` (error), `SPF_RECORD_TOO_LONG` (warn).

### `check_dmarc` — https://tamingdns.com/dmarc

Input: `{ "domain": "example.com" }`.

Runs DUAL policy discovery: the RFC 7489 §6.6.3 organisational-domain ladder (what major receivers enforce today — `grade` and `verdict` anchor to this view) AND the RFC 9989 §4.10 DNS Tree Walk (8-query cap, `psd=` stop rules, fewest-labels org selection). Both views land in `analysis.discovery { legacy, tree_walk, diverges }`; when the two methods select different policy records or org domains, the `DISCOVERY_DIVERGENCE` finding (warn) fires with a one-notch grade downgrade — during the bis transition the two receiver populations enforce different things.

DMARCbis-aware tag handling: `t=`, `np=`, and `psd=` are parsed into `analysis.tags`; tags removed by RFC 9989 (`pct`, `rf`, `ri`) emit `DEPRECATED_TAG` (info); `t=y` emits `TESTING_MODE` (warn — bis receivers apply the policy one level below the published one).

`analysis` also carries `org_domain`, `source` (`self` / `org`), the lookup `ladder`, `rua_unauthorised`, and per-recipient external RUA/RUF authorisation detail — every external `rua=` / `ruf=` mailbox triggers a check at `<queried-domain>._report._dmarc.<reporting-domain>` (RFC 7489 §7.1 / RFC 9990).

Finding codes: `NO_DMARC_RECORD` (error), `MULTIPLE_DMARC_RECORDS` (error), `INVALID_TAG` (error — receivers ignore the whole record), `POLICY_NONE` (warn), `POLICY_NONE_NO_RUA` (error — published but does nothing), `PCT_BELOW_100` (warn), `SP_NOT_ENFORCED` (warn), `RUA_MISSING_UNDER_ENFORCEMENT` (warn), `EXTERNAL_RUA_UNAUTHORIZED` (warn), `DMARC_INHERITED_FROM_ORG` (info), `TESTING_MODE` (warn), `DEPRECATED_TAG` (info), `DISCOVERY_DIVERGENCE` (warn).

### `check_dkim` — https://tamingdns.com/dkim

Input: `{ "domain": "example.com", "selectors": "common" | "all" }` (default `"common"`).

`common` scope probes ~60 selectors covering the major providers (Google Workspace, Microsoft 365, SendGrid, Mailchimp/Mandrill, Mailgun, AmazonSES, HubSpot, Salesforce, Klaviyo, Constant Contact, Brevo, Mailjet, Postmark, Slack, Fastmail, Campaign Monitor, Mailerlite, Litmus, Zendesk, Zoho, GitHub, Atlassian) at concurrency 32, with sub-second median latency. `all` scope expands to the full ~500-selector database plus a three-stage Mimecast date scan when MX records hint at Mimecast (year selectors → common rotation dates → all dates). Agents finding nothing under `common` should retry with `"all"`.

Selector discovery runs client-side; each match is then validated server-side by the same `DkimChecker` the MCP server uses, so findings (`NO_DKIM_KEY`, `KEY_TOO_SHORT`, `KEY_WEAK`, `KEY_REVOKED`, `SHA1_ONLY`, `DKIM_TEST_MODE`) and `records` are engine-identical across surfaces. The multi-selector discovery context rides under `analysis`: `scope`, `scanned`, `matchedCount`, `wildcardRevocation`, per-selector entries (`selector`, `fqdn`, `provider`, `isGeneric`, `keyType`, `keyLength`, `revoked`, `cname`), and provider grouping.

NOTE: the remote MCP server's `check_dkim` is different — it validates ONE key and requires `{ "domain": ..., "selector": ... }`. The sweep exists only on this WebMCP surface, where the browser does the fan-out.

**Non-sending domains.** A correctly hardened non-sending domain publishes `*._domainkey TXT "v=DKIM1; p="` (wildcard DKIM revocation) plus `MX 0 .` (RFC 7505 null MX) and `v=spf1 -all`. When the tool detects the wildcard revoke it probes MX and A/AAAA in parallel and returns `analysis.nonSending`:

```
"nonSending": {
  "wildcardDkim": true,
  "nullMx":       true,
  "noMx":         false,
  "hasWebsite":   true,
  "mailHardened": true,
  "posture":      "non-sending (with website)"
}
```

Agents should report this as a *positive* configuration, not a problem — the wildcard revoke is the M3AAWG-recommended posture for parked and non-sending domains. If the revoke is in place but MX still resolves to a real mail host, `posture` is `dkim-revoked-but-mx-configured` (unusual; worth a human look). `tamingdns.com` and `example.com` are canonical live examples of the `non-sending (with website)` posture (example.com verified 2026-06-09).

### `check_tls_rpt` — https://tamingdns.com/tls-rpt

Input: `{ "domain": "example.com" }`.

Strict RFC 8460 §3 record classification: the TXT at `_smtp._tls.<domain>` must BEGIN with the case-sensitive `v=TLSRPTv1` tag (RFC 7405 `%s`); records failing that test are discarded by receivers, and when more than one record passes the filter, senders MUST treat the domain as not implementing TLS-RPT at all. `rua=` is required by the ABNF. Every destination is validated syntactically — `mailto:` against an address shape, `https://` against a URL shape; reachability is never probed (it would be origin-only, so it can never be grade-bearing in the isomorphic engine).

`analysis` carries `tags` (parsed `v`, split `rua[]`, and `extensions{}` — unknown fields receivers ignore per §3), per-URI `rua[]` rows (`{uri, type, valid, reason}`), `prerequisites{mta_sts, dane, dane_mx_host}` (probed over DNS — `_mta-sts` TXT and TLSA at `_25._tcp` of the lowest-preference MX; `true`/`false` are KNOWN states, `null` means the probe itself failed and never demotes the grade), `discarded_records[]`, and `other_txt_count`.

Finding codes: `TLS_RPT_NO_RECORD` (info — absence of an optional standard, verdict `not_configured`, status `info`), `TLS_RPT_INVALID_VERSION` (error), `TLS_RPT_MULTIPLE_RECORDS` (error), `TLS_RPT_NO_RUA` (error), `TLS_RPT_RUA_INVALID_URI` (warn, per bad URI), `TLS_RPT_NO_VALID_RUA` (error), `TLS_RPT_NO_ENFORCEMENT_POLICY` (warn — neither MTA-STS nor DANE deployed, so there is nothing to report on).

### `check_mta_sts` — https://tamingdns.com/mta-sts

Input: `{ "domain": "example.com" }`.

Origin-proxy tool: RFC 8461 §3.3 makes the policy-host X.509 certificate grade-bearing (an invalid cert means compliant senders fetch no policy), and only the origin can inspect a chain — so the whole analysis computes once in `MtaStsChecker` (PHP) and the UI, this WebMCP surface and the `/mcp` server all relay the same envelope. No partial edge engine, deliberately.

Strict RFC 8461 record selection (§3.1): the TXT at `_mta-sts.<domain>` must BEGIN with the case-sensitive `v=STSv1` tag; after discarding non-matching records, a count other than exactly one means senders assume no policy; the `id` field is required (1–32 alphanumerics). The policy fetch never follows redirects (§3.3 — a 3xx answer is `MTA_STS_POLICY_REDIRECT`, not a fetch). Policy syntax is validated against the §3.2 ABNF (required keys, case-sensitive mode values, `max_age` ≤ 31557600, duplicate non-`mx` keys first-wins). MX coverage follows §4.1/§5.1: wildcards match exactly one leftmost label, and coverage is three-valued — `all`, `partial` (warn: strict senders skip uncovered hosts, silently reducing MX redundancy), `none` (error: in enforce mode compliant senders cannot deliver at all).

`analysis` carries `record` (raw / id / syntax_valid / valid_count / sts_like_count / other_txt_count), `policy` (fetched, `fetch_stage` ∈ transport|http|redirect, mode, max_age, mx[], syntax_valid, quality notes), `cert` (ok / webpki_ok / san_covers / days_left — `null` when inspection was unavailable but the verified HTTPS fetch already succeeded), `mx` (actual hosts, per-host match detail, coverage), and `cross` (`tls_rpt` / `dane` — `null` means the probe failed; unknown is never reported as absent). A DoH outage on the TXT or MX lookup returns a retriable `DOH_TIMEOUT` error envelope, never a grade.

Finding codes: `MTA_STS_NO_TXT_RECORD` (info — absence of an optional standard, verdict `not_configured`; unrelated TXT parked at the name counts as absence), `MTA_STS_RECORD_INVALID` (error), `MULTIPLE_MTA_STS_RECORDS` (error), `MTA_STS_POLICY_UNREACHABLE` (error), `MTA_STS_POLICY_REDIRECT` (error), `MTA_STS_POLICY_INVALID` (error), `MTA_STS_CERT_INVALID` (error), `MTA_STS_MODE_NONE` (warn — verdict `reporting_only`, the §8.3 removal flow), `MTA_STS_MODE_TESTING` (warn), `MTA_STS_MX_MISMATCH` (error), `MTA_STS_MX_PARTIAL_COVERAGE` (warn), `MTA_STS_MAX_AGE_TOO_LOW` (warn — advisory; google.com publishes `max_age: 86400`, verified 2026-06-10, so healthy domains do trip it).

### `check_bimi` — https://tamingdns.com/bimi

Input: `{ "domain": "example.com" }`.

The `analysis` object carries the full BIMI diagnostics the UI renders: the matched `selector`, parsed tags (`v` / `l` logo URL / `a` VMC URL), SVG Tiny-PS logo validation, VMC chain detail (expiry, EKU, SCT, issuer-accepted, SAN match, logotype hash), the DMARC prerequisite check (enforcement at `pct=100` — the RFC 7489 reading Gmail and Apple Mail evaluate today, including the DMARCbis `t=` flag), and a per-provider rendering matrix (Gmail / Yahoo / Apple Mail).

The grade is computed server-side: BIMI's verdict depends on X.509 chain verification against the pinned BIMI root store and OCSP revocation checks, which cannot run in a browser or edge Worker. This WebMCP surface therefore proxies the same `BimiChecker` engine the UI and the `/mcp` server use — deliberately, so all three surfaces return identical grades.

DMARCbis-aware: `t=y` on the prerequisite DMARC record emits `TESTING_MODE` (warn under `p=quarantine` — bis receivers read it as `none`, below the BIMI floor; info under `p=reject`); a present `pct=` emits `DEPRECATED_TAG` (RFC 9989 Appendix A.6, advisory only).

Finding codes include: `BIMI_NOT_CONFIGURED` (info), `BIMI_NO_LOGO_URL`, `BIMI_LOGO_NOT_HTTPS`, `BIMI_LOGO_NOT_SVG`, `BIMI_LOGO_NOT_TINY_PS`, `BIMI_LOGO_UNSAFE_SVG` (all error), `BIMI_LOGO_OVERSIZED`, `BIMI_LOGO_NOT_SQUARE` (warn), `BIMI_VMC_EXPIRED`, `BIMI_VMC_REVOKED`, `BIMI_VMC_SAN_MISMATCH`, `BIMI_VMC_LOGO_MISMATCH`, `BIMI_VMC_MISSING_EKU` (error), `BIMI_VMC_EXPIRING_SOON`, `BIMI_VMC_ISSUER_NOT_ACCEPTED`, `BIMI_VMC_NO_EMBEDDED_SCT` (warn), `BIMI_DMARC_POLICY_INSUFFICIENT`, `BIMI_DMARC_PCT_BELOW_100` (error), `TESTING_MODE`, `DEPRECATED_TAG`.

## Key Facts

Short, dated statements that can be quoted directly. Each one is the kind of fact a TamingDNS FAQ or tool result would cite.

- DMARCbis was published as IETF Proposed Standard in May 2026 across RFC 9989 (DMARC), RFC 9990 (DMARC aggregate reporting), and RFC 9991 (DMARC failure reporting), superseding the older RFC 7489 informational document.
- Google and Yahoo's bulk-sender requirements took effect on 1 February 2024: senders over 5,000 messages per day to Gmail or Yahoo Mail must publish SPF, DKIM, and a DMARC record of at least `p=none`, with one-click unsubscribe and a spam-complaint rate below 0.3%.
- Microsoft began enforcing the same authentication requirement for Outlook.com, Hotmail, and Live on 5 May 2025; failed mail returns the SMTP code 550 5.7.515.
- SPF (RFC 7208 §4.6.4) caps a single evaluation at 10 DNS-resolving terms. Exceeding the cap returns `PermError`, which Google reports as 550 5.7.24.
- SPF's void-lookup cap (NXDOMAIN or empty answers) is 2 per evaluation under RFC 7208 §4.6.4.
- DKIM signing keys must be at least 2048 bits under RFC 8301 (January 2018), which superseded the original RFC 6376 recommendation of 1024 bits.
- Ed25519 DKIM signatures are defined in RFC 8463 (September 2018) and remain optional; RSA-2048 is still the interoperable default.
- ARC (Authenticated Received Chain, RFC 8617) lets forwarders preserve original SPF, DKIM, and DMARC results across hops; it is the standard mitigation for mailing-list and forwarder-induced DMARC failures.
- MTA-STS is defined in RFC 8461 (September 2018) and is paired with TLS-RPT (RFC 8460) for reporting; the policy file is served from `https://mta-sts.<domain>/.well-known/mta-sts.txt`.
- DANE for SMTP is defined in RFC 7672. TLSA records sit at `_25._tcp.<mx-host>` and require DNSSEC; without the AD bit, receivers ignore the pin.
- BIMI requires a DMARC policy of `p=quarantine` or `p=reject` at the organisational domain. Gmail and Apple Mail additionally require a Verified Mark Certificate (VMC) before displaying the logo; Yahoo and Fastmail accept SVG only.
- Apple Mail also accepts a Common Mark Certificate (CMC) for marks in continuous public use for five years, removing the registered-trademark prerequisite.
- A null MX record (`MX 0 .`) signals a non-sending domain under RFC 7505. The M3AAWG-recommended hardened posture for parked domains adds `v=spf1 -all`, a wildcard DKIM revoke (`*._domainkey TXT "v=DKIM1; p="`), and `v=DMARC1; p=reject;`.
- Google Workspace currently rotates through dated DKIM selectors (for example `20251104`); Microsoft 365 uses `selector1` and `selector2`; Mailchimp uses `k1`.

## References

The authoritative sources cited across TamingDNS tools and FAQs.

- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures: https://www.rfc-editor.org/rfc/rfc6376
- RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email: https://www.rfc-editor.org/rfc/rfc7208
- RFC 7489 — DMARC (informational, superseded by RFC 9089): https://www.rfc-editor.org/rfc/rfc7489
- RFC 7505 — A "Null MX" No Service Resource Record for Domains That Accept No Mail: https://www.rfc-editor.org/rfc/rfc7505
- RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS): https://www.rfc-editor.org/rfc/rfc7672
- RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM (raises minimum to 2048-bit RSA): https://www.rfc-editor.org/rfc/rfc8301
- RFC 8460 — SMTP TLS Reporting (TLS-RPT): https://www.rfc-editor.org/rfc/rfc8460
- RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS): https://www.rfc-editor.org/rfc/rfc8461
- RFC 8463 — A New Cryptographic Signature Method for DKIM (Ed25519-SHA256): https://www.rfc-editor.org/rfc/rfc8463
- RFC 8617 — The Authenticated Received Chain (ARC) Protocol: https://www.rfc-editor.org/rfc/rfc8617
- RFC 9989 / 9990 / 9991 — DMARCbis (May 2026): https://www.rfc-editor.org/rfc/rfc9989
- Google bulk-sender guidelines: https://support.google.com/mail/answer/81126
- Yahoo bulk-sender guidelines: https://senders.yahooinc.com/best-practices/
- Microsoft Outlook.com bulk-sender announcement (May 2025): https://techcommunity.microsoft.com/blog/exchange/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
- M3AAWG Sender Best Common Practices: https://www.m3aawg.org/sites/default/files/M3AAWG_Senders_BCP_Ver3-2015-02.pdf
- BIMI Group authority list and SVG profile: https://bimigroup.org/

## Contact

- General support: support@osh.co.za
- Operator: OSH.co.za — https://osh.co.za