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 specific mailbox exists.** No SMTP probe, no catch-all detection. This looks at the domain's mail infrastructure, and that's it. Every response says so in a `basis` field so nothing downstream can mistake one for the other. If you need per-mailbox verification, buy that from someone who does SMTP. This is the layer underneath — and honestly, for fraud triage at signup, the domain layer is usually the part that matters. ### Details worth knowing Send one address, a bare domain, or up to 20 at once. Queries scale with distinct domains, not addresses — 20 addresses across 3 domains costs 3 lookups, so batches are cheap. The parsing is fussy on purpose. DMARC falls back to the organizational domain, so `x@email.uber.com` finds the policy at `uber.com` instead of shrugging. SPF policy comes from the *first* `all` because that's what receivers do. A DKIM record with an empty `p=` is a revoked key, not a working one. IDN domains work in the form people type them, not just punycode. Expect around 20 seconds a call. That's platform overhead, not the lookups — those take under half a second. It's built for enrichment and triage, not for blocking a live signup form. $0.001 a call, five free runs to try it. No signup, no API key, no dashboard — sign the request and go. I'd rather this told you "I don't know" than tell you something confident and wrong. That's the entire design.