Does SMTP verification send a message to the address?

SMTP verification opens a session with the receiving server, announces the sender and the recipient, then stops before writing the message. No mail arrives in the mailbox being analysed, and the person whose address is verified receives nothing.

What happens when the SMTP probe cannot conclude?

The API returns the unknown status with the reason that prevented a conclusion, and no credit is charged. The three usual reasons are a catch-all domain, a greylisting delay, and a server that blocks the probe or stays unreachable.

Can I use the API without ever being charged?

Yes. Omit the smtp parameter and the 18 other checks still run, with no quota and no credit consumed. Only SMTP verification of the mailbox is charged, and only when it reaches a final verdict.

Email verification API

A single REST call submits one address and returns the detail of 19 checks, a status, a reason and a risk score. SMTP verification of the mailbox is optional, requested by one parameter, and it is the only part of the response that consumes a credit. Everything else is free.

Create an account Read the API getting started guide

Cette page existe aussi en français : voir la page de l'API en français .

One call, one verdict

A validation is one POST request carrying an address and, optionally, a request for SMTP verification. The response carries the status, the reason, the risk score and the detail of every check that ran, each one under the field name that the reference documentation uses.

Request

curl -X POST https://api.yeswecheck.fr/v2/email/validate \
  -H "Authorization: Bearer $YESWECHECK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","smtp":true}'

Authentication goes through the Authorization header, with the Bearer scheme, for an API key as well as for a session token. The X-API-Key header is never read.

Response, excerpt

{
  "result": "valid",
  "score": 100,
  "businessEmail": true,
  "freeProvider": false,
  "disposable": false,
  "alias": false,
  "features": {
    "syntax": {
      "result": "valid",
      "score": 100,
      "message": "Adresse conforme."
    },
    "dns": {
      "result": "valid",
      "score": 100,
      "message": "Le domaine annonce un serveur de messagerie.",
      "details": {
        "primaryMx": "mx.exemple.fr",
        "hasARecord": true
      }
    },
    "smtp": {
      "result": "valid",
      "score": 100,
      "message": "Le serveur destinataire confirme la boîte.",
      "details": {
        "exists": true,
        "canReceiveMail": true,
        "isCatchAll": false,
        "smtpCode": 250
      }
    },
    "disposable": {
      "result": "valid",
      "score": 100,
      "message": "Domaine absent de la base de domaines jetables."
    }
  },
  "metadata": {
    "apiVersion": "v2",
    "credits": {
      "used": 1
    }
  }
}

The real response carries more fields than this excerpt. The full reference lives in the documentation: read the address validation guide.

Parameters

Five parameters are accepted, one of them required. Only one of the five can lead to a credit being charged, and it has to be asked for explicitly: an integration that never sets it never spends anything, whatever volume it sends through the API.

Parameters accepted by the validation endpoint.
Name	Type	What it does
email	string, required	Address to analyse.
smtp	boolean, optional	Requests SMTP verification of the mailbox. This is the only parameter that can lead to a credit being charged.
enrichment	boolean, optional	Requests identity enrichment: first name, last name, gender and presumed age inferred from the local part.
smtpTimeout	integer, optional	Maximum time granted to the SMTP session, in milliseconds. The server refuses a value outside the accepted bounds.
country	string, optional	Reference country for the age estimate attached to a first name, as an ISO 3166-1 code. Without this parameter, the country is inferred from the domain.

The SMTP timeout is a configuration bound, not a measured response time: the server refuses any value below 1,000 or above 30,000 milliseconds. Without SMTP verification, the response is immediate. With SMTP verification, response time depends on the receiving server and can range from a few hundred milliseconds to several seconds.

Endpoints

Five endpoints cover the three ways to integrate: one address at a time, a whole file, and the embeddable form widget. This list gives the entry point of each mode rather than the full reference, which belongs to the documentation and is kept in one place only.

Published endpoints and what each one does.
Method	Path	What it does
POST	/v2/email/validate	Validate one address and receive the detail of every check.
POST	/v2/batch/upload	Upload a file of addresses and create a batch job.
GET	/v2/batch/:jobId/status	Follow the progress of a batch job.
GET	/v2/widget/config	Public configuration of a widget, read by the embedded script.
POST	/v2/widget/validate	Validation called by the widget from a customer site.

Statuses and scoring

The API returns one status among four, always with a reason, and a risk score on a scale ending at 100. The status is what an integration branches on; the reason is what makes a support conversation possible when a customer disagrees with the verdict.

The four statuses, what each one means, and whether it is charged.
Status	What it means	What to do	Charged
valid	The address exists and the receiving server agrees to accept it. When SMTP verification is requested, this status is only returned if the server confirmed the mailbox.	Accept the address.	1 credit
invalid	The address cannot receive mail: malformed syntax, a domain with no MX record, a mailbox refused by the server, or an address present in the block list of the organisation.	Reject the address, it will produce a hard bounce.	1 credit
risky	The address is technically acceptable but carries a risk signal: disposable domain, malicious domain, typosquatted domain, or an overall score below the degradation threshold.	Accept under conditions, or discard according to the configured business policy.	1 credit
unknown	The receiving server did not allow a conclusion: catch-all domain, greylisting delay, blocked probe, unreachable server or network error.	Do not decide on this result alone. No credit is charged.	No credit

When the SMTP probe actually talked to the server, its result prevails. The other checks can degrade a result to risky, they can never turn a refusal by the server into an acceptance.

Catch-all domains and disposable addresses each have their own page: how catch-all domains are detected and how disposable addresses are detected .

What a call costs

Billing is governed by one rule, quoted here in full rather than summarised, because summarising it is exactly how a customer ends up surprised by an invoice. It has one consequence that surprises most integrators, and that consequence is written out below rather than buried.

A credit is charged if and only if SMTP verification was requested and the final status is not "unknown".

This rule has a consequence worth stating plainly. Once SMTP verification is requested, an address is charged as soon as a final verdict is reached, including when that verdict comes from syntax or from DNS and the probe never ran. Only the allow list and the block list of the organisation bypass the probe.

La grille tarifaire complète et le simulateur sont publiés en français : consulter la grille tarifaire et les règles de crédits .

Response codes to handle

Five response codes are worth handling explicitly in an integration. The one that matters most is the code returned when the credit balance is empty: the other checks stay available, so a client that falls back gracefully keeps validating rather than stopping altogether.

Response codes returned by the validation endpoint.
Code	Label	What it means
200	Success	Validation completed, the body carries the full result.
401	Not authenticated	The Authorization header is missing, malformed, or the key has been revoked.
402	Out of credits	SMTP verification was requested while the balance is empty. The other checks stay available by dropping the smtp parameter.
422	Invalid request	A parameter does not respect its type or its bounds. The body lists the offending fields.
429	Cap reached	The cap of the API key has been reached. The body states which window is concerned.

Read the error reference and read the rate limit reference.

Keys, hosting, and what is not claimed

Keys are sent in the Authorization header with the Bearer scheme, and the header named after the product is never read. YesWeCheck hosts its validation infrastructure with OVHcloud, in France and in Germany. That statement covers where the platform runs and where validation data is stored, and it is not stretched any further.

Live keys and test keys are distinguished by their prefix, ywc_live_ and ywc_test_, so that a key pasted into the wrong environment is visible at a glance. Read the API keys guide.

No formal security certification is held, and none is claimed anywhere on this site.
No response time figure is published on this site. The measurement available today is taken server side and covers too few calls for a percentile to mean anything.

Frequently asked questions

How do I authenticate a call?: Authentication goes through the Authorization header, with the Bearer scheme, for an API key as well as for a session token. The X-API-Key header is never read.
Does SMTP verification send a message to the address?: SMTP verification opens a session with the receiving server, announces the sender and the recipient, then stops before writing the message. No mail arrives in the mailbox being analysed, and the person whose address is verified receives nothing.
What happens when the SMTP probe cannot conclude?: The API returns the unknown status with the reason that prevented a conclusion, and no credit is charged. The three usual reasons are a catch-all domain, a greylisting delay, and a server that blocks the probe or stays unreachable.
Can I use the API without ever being charged?: Yes. Omit the smtp parameter and the 18 other checks still run, with no quota and no credit consumed. Only SMTP verification of the mailbox is charged, and only when it reaches a final verdict.