Email checker

Validation and fraud checking are different jobs

Most tools that look like this one are email validators, built for a different problem: keeping a mailing list clean so a send does not bounce. They answer one question well, which is whether mail to this address will arrive.

That question is nearly useless for fraud.

Validation asks whether the mailbox exists. Fraud checking asks whether the person exists, and whether you have already met them. Every field below is only worth reading in that light.

What each field is actually worth

Disposable domain. The one people look for, and genuinely useful. Covered properly on the disposable email checker. Worth knowing that a throwaway address is a signal about the account, not a verdict on the person.

MX records. Tells you the domain can receive mail. That is all. Every temp-mail service has valid MX, because an inbox that could not receive mail would be useless to them too.

SPF and DMARC. Sender-auth records the domain publishes. Relevant if you care whether someone can spoof mail from that domain. Close to irrelevant for whether the human filling in your signup form is real.

Domain age. Backfires more often than it helps. mailinator.com is over 23 years old and gmail.com dates to 1995, so an age rule vouches for the worst addresses on the internet and penalises the employee of a startup founded last year. The full argument is in how old is this email address.

Role accounts. info@, support@, admin@. Not a person, and cannot own a consumer account in any meaningful sense. For B2B it is completely normal. Whether this matters depends entirely on what you sell.

Gibberish. Machine-generated mailboxes, scored on the canonical form so an unusual real name is not punished for being unusual. Weak alone, useful stacked.

The field that actually matters

How many accounts share one inbox. Not whether the address is disposable. Not whether it delivers. Whether the canonical form of it has been seen before.

alex+1@gmail.com and a.l.e.x@gmail.comare the same mailbox. Both are real, both deliverable, neither disposable, and every validator on the market passes both without comment. Collapsing them to one identity key is what turns “two signups” into “one person, twice”.

That signal is unambiguous in a way most others are not. Two accounts sharing a device could be a household or an office. Two accounts sharing one real mailbox is one person receiving both sets of mail.

What this cannot tell you

Whether the mailbox exists. Nothing is sent to the address, and SMTP mailbox probing is unreliable and rude in equal measure: catch-all domains answer yes to everything, and many providers rate-limit or blacklist probers. Everything here comes from DNS, the address itself and reputation data.

Whether the person owns it. An address someone typed into your form is a claim, not a fact, until they click a link in it. Email verification and email checking are different steps and you want both.

Anything about intent. A clean report on a fresh address is the most common thing in the world, and it is also what the ninth account of a farm looks like. That is precisely why the inbox is one input to /v1/score rather than a verdict of its own.

Using it at signup

curl -X POST https://api.kaidn.io/v1/check/email \
  -H "x-api-key: $KAIDN_API_KEY" \
  -H "content-type: application/json" \
  -d '{"email":"a.l.e.x+7@gmail.com"}'

# {
#   "email": {
#     "fraud_score": 42,
#     "is_disposable": false,
#     "mx_valid": true,
#     "canonical": "alex@gmail.com",
#     "is_aliased": true,
#     "alias_tricks": ["plus_tag", "gmail_dots"]
#   },
#   "summary": "Deliverable and not disposable, but aliased:
#               canonical form is alex@gmail.com."
# }

Note what happened there. Not disposable, valid MX, ordinary domain, a validator would return a clean pass. The canonical field is the one carrying the information.

For a real decision, send it through POST /v1/score with the IP and the device so the inbox is weighed against everything else rather than judged alone.