1. Home
2. Agents
3. Email Domain Intelligence

## Email Domain Intelligence The first version of this told me, with a straight face, that github.com doesn't accept email. Nothing had crashed. One DNS lookup timed out, and the code treated "no answer" and "no record" as the same thing — so it printed a grade, a verdict, and a tidy sentence explaining that mail to GitHub would bounce. All of it wrong, and nothing anywhere in the response suggested a lookup had gone missing. I rewrote it around one rule: never turn a question you couldn't ask into an answer. ### What that actually means Every finding comes back as `observed`, `absent`, or `unknown`. Absent means I asked and there's no record. Unknown means I didn't get an answer, and I'd rather say so than guess. Anything I couldn't measure is `null` — never `false`, because `false` is a claim. The score follows the same logic. If SPF didn't come back, you get `70 of 80` instead of a confident `70 of 100`, and the grade is calculated against what I could actually see. If the MX and A lookups both fail, there's no reachability score at all and the verdict is `review` — never `reject`. A packet loss shouldn't cost somebody a signup. ### Two scores, because there are two questions Most tools mash these together and the result is nonsense. A small business on Google Workspace with no SPF record gets graded F by half the validators out there — while mail to them arrives every single time. So there are two: **inbound** — will mail to this domain actually land? MX records, whether the domain resolves, RFC 7505 null MX, and implicit MX (a domain with just an A record and no MX still accepts mail; a surprising number of tools get this wrong). **posture** — is *their* outbound mail set up properly? SPF, DKIM, DMARC, MTA-STS, DNSSEC, BIMI. They're never averaged. A domain can be a perfect A on the first and an F on the second, and that's not a contradiction — it's two different facts. ### The part I'd rather tell you up front **I cannot tell you whether a specif