dns-check

name	dns-check
description	Triage a Thundermail custom-domain email DNS ticket (DKIM/SPF/MX/DMARC) and draft the customer reply. Usage: /dns-check <domain> (e.g. /dns-check example.com)

Email DNS triage — $domain

Diagnose why mail from the custom domain $domain isn't signing or is landing in spam, then hand back a clear PASS/FAIL plus a paste-ready Zendesk reply.

Read docs/EMAIL-DNS-DEBUGGING.md for the full reasoning behind every step below — this skill is the fast path through it.

---

Step 1 — Run the automated audit

scripts/dns/tbpro-dns-check.sh $domain

This grades DKIM (tm1/tm2 CNAMEs), SPF, MX, and DMARC against the expected Thundermail values in one shot. If dig isn't available, fall back to the manual lookups in §1/§8 of the runbook.

Step 2 — If anything FAILed, identify which customer mistake it is

Check the four common causes (runbook §2), in order:

1. Domain appended twice — re-query with the domain doubled (dig +short tm1._domainkey.$domain.$domain CNAME @1.1.1.1). If that resolves, the customer pasted the full host into a panel that auto-appends the zone. Fix: enter only tm1._domainkey in the name field (and @ for apex).
2. Cloudflare orange-cloud — a proxied MX/CNAME/TXT. Fix: set those records to "DNS only" (grey cloud).
3. Duplicate / old SPF — there must be exactly one v=spf1 TXT. Merge them.
4. Not yet propagated — just-added records; compare @1.1.1.1 vs @8.8.8.8 and have them wait out the TTL.

Step 3 — If everything PASSed but mail is still unsigned → escalate, don't loop

All DNS correct + domain but no header on a test message is server-side bug, not the customer's DNS (runbook §6). Do send the customer back to their DNS. Escalate to the platform team with: the domain, raw headers of a test message, a note that DNS is verified clean, and a reference to / .