Free Email Validation API Endpoint

Validate an address

The free email validation API endpoint takes the address in a data field and hands back six fields. There is no header to set beyond the content type.

curl -X POST https://aisenseapi.com/services/v1/email_validate \
  -H "Content-Type: application/json" \
  -d '{"data": "test@gmail.com"}'

{
  "email": "test@gmail.com",
  "valid_syntax": true,
  "domain": "gmail.com",
  "has_mx": true,
  "mx_hosts": ["gmail-smtp-in.l.google.com", "alt1.gmail-smtp-in.l.google.com", "alt2.gmail-smtp-in.l.google.com", "alt3.gmail-smtp-in.l.google.com", "alt4.gmail-smtp-in.l.google.com"],
  "has_address_record": true
}

Every value there is a fact about text and DNS. The address parsed, gmail.com publishes MX records, and five of them came back in preference order.

Input is trimmed but never rewritten. Posting " Test@GMAIL.COM " gives back "Test@GMAIL.COM" in email and "gmail.com" in domain, so the echo stays faithful to what you sent while the domain arrives lowercased and ready to compare.

What the free email validation API endpoint returns

Field	Type	Description
email	string	The address as received, trimmed.
valid_syntax	boolean	Whether the address parses as an email address.
domain	string or null	The domain part, lowercased. Null when syntax fails.
has_mx	boolean	Whether the domain publishes MX records.
mx_hosts	array	Up to five MX hosts, lowest preference first.
has_address_record	boolean	Whether the domain resolves to A or AAAA.

The shape never changes. A failed address returns the same six keys as a good one, so you can read the response without guarding for missing fields.

The mx_hosts cap of five matters for large providers. Gmail publishes exactly five, so the list above is complete, but a domain with more will hand you the five lowest preferences and stop there. The array is a diagnostic aid, not a routing table.

Syntax, a resolvable domain and a working MX are three different things

The three signals sit in a chain, and each one only makes sense once the one before it holds.

Syntax
The address is parsed as text. Nothing about the world is consulted yet. When parsing fails the chain stops there: domain comes back null and both DNS flags are false, because there was no domain to ask a question about.
A resolvable domain
has_address_record is true when the domain answers with an A or AAAA record. That is weaker than an MX record, but it is not nothing. RFC 5321 lets a sender fall back to the address record when no MX exists, so a missing MX alone does not prove an address dead.
An MX that can accept mail
has_mx true, with hosts listed in mx_hosts, means the domain has named the servers that take its mail. This is the strongest of the three signals, and it still describes the domain rather than any address inside it.

A domain that resolves nowhere shows the chain breaking after the first step.

curl -X POST https://aisenseapi.com/services/v1/email_validate \
  -H "Content-Type: application/json" \
  -d '{"data": "someone@this-domain-does-not-exist-zzz9.no"}'

{
  "email": "someone@this-domain-does-not-exist-zzz9.no",
  "valid_syntax": true,
  "domain": "this-domain-does-not-exist-zzz9.no",
  "has_mx": false,
  "mx_hosts": [],
  "has_address_record": false
}

Syntax passed, so domain is filled in. Everything after it is false, because the name does not resolve at all. Valid syntax with both DNS flags false is the clearest negative this endpoint gives you.

Why six true values still do not prove a mailbox

This is the honest limit of the free email validation API endpoint, and it is worth seeing rather than reading about.

curl -X POST https://aisenseapi.com/services/v1/email_validate \
  -H "Content-Type: application/json" \
  -d '{"data": "no-such-mailbox-zzq7431@gmail.com"}'

{
  "email": "no-such-mailbox-zzq7431@gmail.com",
  "valid_syntax": true,
  "domain": "gmail.com",
  "has_mx": true,
  "mx_hosts": ["gmail-smtp-in.l.google.com", "alt1.gmail-smtp-in.l.google.com", "alt2.gmail-smtp-in.l.google.com", "alt3.gmail-smtp-in.l.google.com", "alt4.gmail-smtp-in.l.google.com"],
  "has_address_record": true
}

That mailbox does not exist. The response is byte for byte the same as one for a real Gmail address apart from the local part, because DNS knows about gmail.com and knows nothing about who holds an account there.

Confirming a mailbox would need an SMTP conversation with the receiving server, and this endpoint never opens one. The omission is deliberate. A public, unauthenticated service that probes mailboxes is an address harvesting tool, and the answers would be poor anyway, since large providers routinely accept or defer every recipient at the door.

So treat the result as a filter rather than a verdict. It removes typos and dead domains for the price of one request. Only a message the recipient acts on proves the mailbox is real.

A bad address is a result, not an error

Rejection arrives with HTTP 200 and a normal body.

curl -X POST https://aisenseapi.com/services/v1/email_validate \
  -H "Content-Type: application/json" \
  -d '{"data": "not-an-email"}'

{
  "email": "not-an-email",
  "valid_syntax": false,
  "domain": null,
  "has_mx": false,
  "mx_hosts": [],
  "has_address_record": false
}

Only a request with no address at all is a 400:

{"error":"No email address provided."}

Branch on valid_syntax and the two DNS flags, and keep your error handling for the 400. A client that treats every unusable address as an exception will throw far more often than it needs to.

One case catches people out. Internationalized domains are not converted to punycode, so post@blåbær.no comes back with valid_syntax false. Convert such domains yourself before calling if your forms accept them.

Where an address check pays for itself

Signup forms

Catch a mistyped domain while the user is still on the page, when fixing it costs one keystroke instead of a support ticket.

Agent input checking

Verify an address a language model extracted from a document before anything downstream tries to use it.

List hygiene

Flag stored contacts whose domains have stopped publishing mail records, which is a common sign of a company that no longer exists.

Support tooling

Show an agent whether a customer-supplied address could receive mail at all, before anyone starts hunting for a missing message.

All four share a shape. They use the free email validation API endpoint to reject the clearly impossible, then let a real message settle the rest.

Privacy and limits

The address travels in the POST body, not the URL, so it never appears in request paths, logs or referrer headers. DNS questions about the domain go through this server's own resolver, as any lookup must, and no third party sees the address.

The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account behind it. Cache results per domain rather than per address: the DNS half of the answer is identical for every address at the same domain, which cuts the request count sharply on a large list.

Every endpoint on the service is listed in the free public REST APIs reference. When you have a domain but no address, the Domain IP Lookup API endpoint answers the resolution half on its own, and the Validation API endpoint covers the other input types a signup form has to check. The Health Check API endpoint is the one to poll before you build a batch job against any of them.