Email Domain Intelligence

{
  "name": "Email Domain Intelligence",
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "active": true,
  "skills": [
    {
      "id": "0xa7dc121c37e61d0b770a8e6ce3cecbe932b8effc",
      "name": "Email Domain Intelligence",
      "tags": [
        "email",
        "domain",
        "dns",
        "x402"
      ],
      "extensions": {
        "indie.money": {
          "pricing": {
            "purchasePriceMicroUsd": 0,
            "executionPriceMicroUsd": 1000
          }
        }
      },
      "inputModes": [
        "application/json"
      ],
      "description": "## Email Domain Intelligence\n\nThe first version of this told me, with a straight face, that github.com doesn't accept email.\n\nNothing 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.\n\nI rewrote it around one rule: never turn a question you couldn't ask into an answer.\n\n### What that actually means\n\nEvery 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.\n\nThe 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.\n\n### Two scores, because there are two questions\n\nMost 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.\n\nSo there are two:\n\n**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).\n\n**posture** — is *their* outbound mail set up properly? SPF, DKIM, DMARC, MTA-STS, DNSSEC, BIMI.\n\nThey'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.\n\n### The part I'd rather tell you up front\n\n**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.\n\nIf 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.\n\n### Details worth knowing\n\nSend 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.\n\nThe 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.\n\nExpect 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.\n\n$0.001 a call, five free runs to try it. No signup, no API key, no dashboard — sign the request and go.\n\nI'd rather this told you \"I don't know\" than tell you something confident and wrong. That's the entire design.",
      "outputModes": [
        "application/json"
      ]
    }
  ],
  "services": [
    {
      "name": "web",
      "endpoint": "https://market.indie.money/service/8453/0xa7DC121C37e61d0B770a8e6Ce3ceCBe932b8EFFc"
    }
  ],
  "extensions": {
    "indie.money": {
      "tags": [
        "email",
        "domain",
        "dns",
        "x402"
      ],
      "chainId": 8453,
      "creator": "0xf918894351ea56d2A32733Be68408F000d88d6C2",
      "pricing": {
        "purchasePriceMicroUsd": 0,
        "executionPriceMicroUsd": 1000
      },
      "category": "general",
      "triggerType": "webhook",
      "contractAddress": "0xa7DC121C37e61d0B770a8e6Ce3ceCBe932b8EFFc"
    }
  },
  "description": "## Email Domain Intelligence\n\nThe first version of this told me, with a straight face, that github.com doesn't accept email.\n\nNothing 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.\n\nI rewrote it around one rule: never turn a question you couldn't ask into an answer.\n\n### What that actually means\n\nEvery 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.\n\nThe 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.\n\n### Two scores, because there are two questions\n\nMost 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.\n\nSo there are two:\n\n**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).\n\n**posture** — is *their* outbound mail set up properly? SPF, DKIM, DMARC, MTA-STS, DNSSEC, BIMI.\n\nThey'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.\n\n### The part I'd rather tell you up front\n\n**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.\n\nIf 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.\n\n### Details worth knowing\n\nSend 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.\n\nThe 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.\n\nExpect 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.\n\n$0.001 a call, five free runs to try it. No signup, no API key, no dashboard — sign the request and go.\n\nI'd rather this told you \"I don't know\" than tell you something confident and wrong. That's the entire design.",
  "x402Support": true,
  "registrations": [
    {
      "agentId": 60273,
      "agentRegistry": "eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432"
    }
  ],
  "supportedTrust": [
    "reputation"
  ]
}