Parse and normalise
We reject hostile syntax before a credit is spent, then canonicalise the address the mail server will actually see.
Real-time email verification
Stop guessing which emails will bounce.
BounceIntel checks syntax, DNS, MX records and the mailbox itself, then explains the verdict with a score and reason codes you can act on.
Check any address. No account needed. Try it with .
POST /v1/check_emailExample
100/100
- Score
- 100 / 100
- Safe to send
- Yes
- Provider
- google workspace
- SyntaxValid
- MX recordsPresent
- SMTPConnected
- MailboxExists
- Catch-allNo
- DisposableNo
- deliverable
- provider reputation
- tenant history positive
Every verdict arrives with the evidence behind it.
Trusted by teams that live in the inbox
- Median verification latency
- < 500ms
- API uptime target
- 99.9%
- Email addresses validated, and counting
- 1B+
- Data processed and stored in the EU
- EU
01Method
A mailbox check, not a guess.
Every verification runs the same pipeline: syntax, DNS, MX, then an SMTP conversation with the receiving server. The verdict comes with the evidence.
Ask the mail server
MX lookup, SMTP handshake, recipient probe. Catch-all, full, disabled and role mailboxes are classified, not guessed.
Score and explain
A 0–100 score, a recommended action, and reason codes you can switch on in code. No black-box blob.
POST /v1/check_emaillive
02Use cases / by team / by moment
Find the moment a bad address costs you
Verification earns its keep in eight different places, from the signup form to a data platform running millions of checks a month. Pick the one that looks like your problem.
Product and growth engineers
Signup and checkout forms
A bad address entering your database at signup is a problem you will pay for many times over, not once.
Sales teams and outbound agenciesCold outreach and sales prospecting
Outbound is the one channel where a few percent of bad addresses can take the whole sending domain down with it.
Email and lifecycle marketersEmail marketing and list hygiene
A list decays whether or not you send to it, and the bill arrives all at once.
RevOps and data teamsCRM and database hygiene
Nobody notices a CRM going stale, because every individual record still looks fine.
Ecommerce and retail teamsEcommerce and transactional email
A mistyped address at checkout means the order confirmation and the shipping notice both go nowhere.
SaaS product teamsSaaS onboarding and trial abuse
Free trials and referral bonuses are farmed with disposable addresses, one throwaway inbox at a time.
Agencies and consultanciesAgencies and service providers
You inherit lists you did not build, and you are the one held responsible for what they do.
Data platforms and list vendorsData providers and platforms
If you sell contact data, verification accuracy is your product quality, not an operating cost.
03Signals
What actually goes into a verdict.
These are the checks behind every result on this site and in the API.
Syntax
RFC-shaped addresses only. Quoted locals and IP literals never reach SMTP.
MX records
Whether the domain accepts mail, and which hosts it names.
Mailbox probe
Does the recipient exist, is it full, disabled, or a catch-all.
Disposable & role
Throwaway inboxes and admin@ / info@ style addresses, flagged explicitly.
Provider rules
Gmail, Microsoft 365 and others apply extra local-part constraints we encode as reason codes.
Reason codes
Stable machine values so your integration can branch without parsing English copy.
04Developers / REST / no SDK required
One POST. Explainable JSON back.
Bearer auth, a single endpoint, and a response whose field names your integration can branch on. No client library to install, no wrapper to learn.
verify.sh
curl -X POST https://api.bounceintel.com/v1/check_email \
-H "Authorization: Bearer $BOUNCEINTEL_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]"}'response.json200
{
"input": "[email protected]",
"is_reachable": "safe",
"syntax": {
"domain": "stripe.com",
"username": "ada",
"is_valid_syntax": true
},
"mx": {
"accepts_mail": true,
"records": ["aspmx.l.google.com", "alt1.aspmx.l.google.com"]
},
"smtp": {
"can_connect_smtp": true,
"is_deliverable": true,
"is_catch_all": false,
"is_disabled": false,
"has_full_inbox": false
},
"misc": {
"is_disposable": false,
"is_role_account": false,
"is_b2c": false
},
"provider": "google_workspace",
"provider_rules_applied": true,
"score": {
"score": 100,
"category": "valid",
"sub_reason": "deliverable",
"safe_to_send": true,
"confidence": 0.97,
"confidence_level": "high",
"reason_codes": ["deliverable", "tenant_history_positive"]
},
"bounce_risk": {
"score": 3,
"category": "low",
"confidence": 0.94,
"action": "send",
"model_version": "br-2026.06",
"risk_factors": [
{
"signal": "smtp_is_deliverable",
"direction": "decreases_risk",
"contribution": -0.41,
"description": "Mailbox accepted the recipient at RCPT TO."
}
]
}
}05Product
One engine, three ways in.
The same verification pipeline powers the live checker, bulk jobs and the REST API.
06Audit trail
A score you can defend.
When a stakeholder asks why an address was rejected, you can point at the reason codes, not a vendor's gut feel.
VerdictRecommended action
The mailbox accepted the recipient, and nothing in the provider or history signals argued against it.
- deliverable
- provider_reputation
- tenant_history_positive
It resolves, but something about the address or its domain will cost you once you send at volume.
- catch_all
- role_account
- full_inbox
The address was refused outright, or there is nowhere for mail to be delivered.
- invalid_recipient
- no_mx
- disabled_mailbox
The provider would not give a straight answer. We say so, rather than dressing a guess up as a score.
- smtp_timeout
- smtp_policy_block
- transient_smtp
41 reason codes across 4 verdicts. Every check returns the ones that actually applied, so a rejection is always traceable to a rule rather than to a number.
Start with 100 credits. No card.
Create an account and run the same pipeline your production list will use.