Frequently asked questions

Email verification finds the addresses that would bounce before you send to them. That matters because a high bounce rate damages your sender reputation and pushes the rest of your mail toward spam. Technically, it establishes whether an address can actually receive mail, without sending anything to it. A check inspects the syntax of the address, confirms the domain exists and publishes MX records, opens a conversation with the receiving mail server, and asks whether that server would accept a message for that mailbox. The result is a verdict, not a guarantee, because some receiving servers deliberately refuse to answer the question.

Inbox providers such as Gmail and Outlook watch how much of your mail bounces. Sending to addresses that do not exist tells them your list is old, bought or badly collected, which are the habits of spammers, so they start trusting your domain less. Lower trust means more of your mail is filtered into spam, including messages to real, engaged customers. The damage attaches to your sending domain and IP, not to the bad addresses, which is why a single careless send can affect everything you mail afterwards.

Usually three things, in roughly this order. Inbox providers start delaying your mail or filtering it into spam. Your email platform notices, because high bounce rates put its own shared reputation at risk, and may review, throttle or pause your account until the list is cleaned. Then recovery takes time: a damaged domain has to rebuild trust with clean, consistent sending over weeks, and some teams give up and move to a new domain instead. Verifying before you send is far cheaper than any of those steps.

In practice the two words are used for the same thing, and every vendor in this category uses them interchangeably. Where a distinction is drawn, validation means checking that an address is well formed and its domain is real, while verification adds the mailbox-level check against the receiving server. BounceIntel does both in a single call and tells you which stage produced the verdict.

No. The check stops short of delivery. It opens an SMTP conversation with the receiving server, asks whether a message for that address would be accepted, and closes the connection before any message body is transmitted. The mailbox owner sees nothing and receives nothing.

For ordinary mailboxes at the mainstream providers, a verification is reliable and the verdict can be trusted. Accuracy degrades in two specific, knowable situations: catch-all domains, which accept mail for every address and therefore cannot confirm a particular one, and servers that greylist or otherwise refuse to answer verification traffic. We report both as their own verdicts rather than folding them into a percentage. We do not publish a headline accuracy figure, because no vendor's figure in this category is independently verifiable and a number you cannot check is not a fact.

Contact data decays continuously, so the useful answer is a schedule rather than a one-off. Verify at the point of capture so nothing bad enters, then re-verify any segment before you mail it if it has been dormant for more than a few months. A list that has gone a year without verification should be treated as unknown until it has been checked.

No, and any vendor promising that is describing something that cannot be built. A mailbox can be closed between the moment you verify it and the moment you send. A full inbox can reject a message an hour after accepting a verification. Verification removes the addresses that were never going to work, which is the large majority of avoidable bounces, and it tells you which of the remainder are uncertain.

Deliverable means the mailbox exists and accepts mail, so send. Risky means the address is real but something about it warrants caution, a role account or a catch-all domain for example, so send with judgement. Undeliverable means the address will bounce, so do not send. Unknown means the receiving server would not give an answer, which is information about the server rather than about the address.

The verdict is the categorical answer and the score is the graded one. Two addresses can both be deliverable while one is a long-standing mailbox at a major provider and the other is a fresh account on an obscure domain. The score carries that difference so you can set your own threshold rather than accepting ours. A confidence level travels with it, saying how much evidence the score rests on.

A reason code names the specific finding that produced the verdict, and it is stable enough to branch on in code. That is the difference between a result you can act on and a number you have to trust. If an address is suppressed, the reason code says whether it was the syntax, the domain, the mailbox or the provider's reputation that decided it, which means a decision can be explained to a colleague, a client or an auditor months later.

Unknown means the receiving mail server declined to answer, not that the address is bad. Some servers greylist unfamiliar connections and defer everything on first contact. Some rate-limit or refuse verification traffic outright as a matter of policy. Some are simply unreachable at the moment of the check. Treating unknown as undeliverable throws away good addresses, which is why it is a separate verdict rather than being merged into one.

A catch-all domain is configured to accept mail addressed to anything at that domain, whether or not the mailbox exists, so the receiving server answers yes to every question you ask it. No verifier can prove a specific mailbox exists behind a catch-all, and one that claims otherwise is guessing. We return the address as risky with the catch-all reason attached, so you can decide per segment: often worth the risk for a warm list, usually not for cold outreach on a young sending domain.

A role address belongs to a function rather than a person: info, support, sales, admin, billing. It is usually deliverable, so it is not marked invalid, but it is often read by several people or by none, and it is more likely to generate a complaint on marketing mail. It is flagged rather than removed because the right answer depends on what you are sending. Keep them for transactional and support mail, and think twice before including them in a campaign.

A spam trap is an address that exists only to identify senders who do not maintain their lists. Pristine traps were never valid addresses; recycled traps are abandoned mailboxes reactivated by the provider. Nobody can identify a trap with certainty from the outside, and any vendor claiming a definitive spam-trap detector is overstating. What verification does is remove the conditions traps live in: long-dormant addresses, addresses that no longer resolve, and lists that have not been checked in years.

A hard bounce is permanent: the address does not exist, or the domain does not accept mail. It counts against your sender reputation and the address should be suppressed immediately. A soft bounce is temporary: a full inbox, a server that is down, a message that is too large. Verification is aimed at the hard bounces, because those are the ones that are both predictable in advance and damaging when they happen.

Four stages, in order, stopping as soon as an answer is certain. Syntax, which rejects malformed addresses without any network traffic. DNS and MX, which confirm the domain exists and publishes a mail server. The SMTP conversation with that mail server, which is where the mailbox itself is checked. And a set of classification signals: whether the domain is disposable, whether the address is role-based, whether the mailbox is disabled or full, and which provider is behind it.

Well under a second in the ordinary case, which is fast enough to sit inside a signup form handler. The variable is the receiving server: some answer immediately, some deliberately delay unfamiliar connections. Set a timeout that suits your form and decide the fallback in advance. Most teams accept the address and flag it rather than blocking a signup on a slow third-party lookup.

Yes. The response names the provider, Google Workspace or Microsoft 365 for example, along with how confident that identification is. It is useful beyond curiosity: provider is one of the inputs to the score, and it tells you which of your recipients sit behind the reputation systems that matter most for deliverability.

Yes, on every check, as a flag in the response rather than as a separate product. Maintaining your own list of disposable domains is a losing race because new ones appear faster than anybody can add them, which is exactly why this belongs in a lookup rather than in your codebase.

Upload a CSV in the dashboard, or submit the addresses to the bulk endpoint and poll for the result. Either way the job runs asynchronously, so nothing has to hold a connection open, and progress is readable while it runs. Results come back with the same per-address structure a single check returns, so anything you built against one works against the other.

Large enough that the practical limit is your credit balance rather than the job. Very large lists are best submitted as several jobs so you can start acting on the first results while the rest run, and so a single retry does not restart everything.

Results are available as JSON from the API and as a downloadable file from the dashboard. The file is a fixed set of result columns keyed on the address rather than your original rows, so it imports the same way every time; join it back to your own system on the address column. A summary report is also available for sharing with somebody who wants the shape of the list rather than the rows.

Not when you upload through the dashboard: repeated addresses are collapsed before the job starts, so each one is verified and charged once. A job submitted through the API is charged per address in the request, so deduplicate before you submit. Either way it is a good habit on lists assembled from several sources, where duplicates are common and inflate the apparent size of the list.

Yes, and it is the primary way to use the product. One REST endpoint verifies a single address, another submits and polls bulk jobs, and both authenticate with a bearer token. The documentation carries request and response examples for every endpoint plus a playground you can call live from the page.

The documentation shows cURL, TypeScript, Python and Go, all as plain HTTP calls with no SDK required. That is deliberate: the API is small enough that an SDK would add a dependency without removing any work, and a plain fetch call is something you can read and verify in any language.

Errors come back with a stable machine-readable code alongside the HTTP status, so retry logic can branch on the code rather than parsing a message. A rate limit and an exhausted credit balance both return 429 but with different codes, because one is worth retrying after a pause and the other is not. The documentation lists every code and the action it calls for.

Yes. The documentation includes a live playground that issues real requests against the real API, so you can see an actual response shape before writing any code.

You can hold several keys at once and revoke any of them independently, which is what you want for separating staging from production, or for giving a contractor a key you can withdraw without rotating everything else.

One credit verifies one address, whether it comes from the API, a bulk upload or the dashboard. Credits are bought in monthly plans or as pay-as-you-go packs, and the per-credit rate falls as volume rises. There is no separate charge for the API, no per-seat fee and no minimum contract.

A check that reaches the receiving server consumes a credit whatever the answer, including unknown, because the work was done and the result is genuine information about that server. A request that fails before any verification happens, a malformed request for example, does not.

The API returns 429 with a quota code that is distinct from the rate-limit code, so your integration can tell the difference between wait and top up. Nothing is deleted and no job is lost; add credits and the same job continues.

Pay-as-you-go credits stay on the account. Plan credits refresh on the plan's cycle. The pricing page states the terms for each plan explicitly rather than in a footnote, because expiring credits are the most common unpleasant surprise in this category.

Invoices are issued for every payment and are available in the billing area. For annual terms, larger volumes or procurement requirements, contact us and we will quote against your actual volume rather than pushing you to the nearest published tier.

New accounts start with a credit allowance so you can verify a real sample of your own data before deciding. No card is required to use it.

They are processed to produce the verdict you asked for, and for nothing else. Your addresses are not sold, not shared, not added to any list and not used to build a database that is resold to anyone. The privacy policy states this in full and the data processing agreement makes it contractual.

Verification results are kept for as long as you need them available in your account, and bulk job data can be deleted from the dashboard as soon as you have downloaded the results. Retention periods are set out in the privacy policy.

Yes. There is a GDPR page describing how the regulation applies to email verification specifically, a data processing agreement available to every customer, and a published list of the sub-processors involved in delivering the service. All three are linked from the footer of every page.

The verification platform and its database are hosted in the European Union. A few supporting services, payments and transactional email among them, operate partly outside it; the sub-processors page names every third party, says what each one does and where it is located, so you can complete a vendor assessment without having to ask.

API keys are shown once and stored hashed, so a key cannot be recovered from our side, only replaced. Keys are revocable individually. Access to production systems is limited to the people who need it, and the security controls we operate are described on the trust and legal pages rather than represented as badges.

Email support directly. There is no ticket queue to navigate and no tier that has to be bought before a human replies. Include the address or the job id you are asking about and the answer will be specific rather than generic.

Yes. Volume is pooled across the account, which is what makes this worth doing for an agency or a team handling several clients: one balance, one rate, separate keys.

Yes, from the account settings, and the deletion is confirmed rather than silent. It removes the account and the data associated with it, subject only to the records we are legally required to retain, which the privacy policy lists.

The site and the product interface are available in English, French, Spanish, Italian and German. Support is answered in English.