valid
Accept the address.
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.
Charged when SMTP was requested
European email verification
Email verification API, hosted in Europe
19 checks on every address. Only one can consume a credit.
YesWeCheck checks whether an email address is correctly formed, whether its domain can receive mail, and, on request, whether the mailbox itself exists. It returns a status, a reason and a risk score. Nineteen checks run on every address, eighteen of them without consuming a credit or hitting a quota.
- No signup required
- No message sent
- Hosted in France and Germany
YesWeCheck is a French email address validation platform. It provides a documented REST API for real time verification and batch processing, combining syntax, DNS and MX checks, disposable address detection, role accounts, domain typo detection and SMTP verification, and returns a status, a reason and a risk score. The infrastructure is hosted with OVHcloud, in France and in Germany.
Cette page existe aussi en français : voir la page d'accueil en français.
Live demo
Check an address now
The public demo uses the production validation API and displays each returned check.
The demo submits one address to the public API and displays the complete response, check by check, without signup or a payment card. No message is sent to the address. The raw JSON response remains available, so the visible result can be compared with the API payload.
valid
Overall score 100 / 100
- Syntax Syntax is valid valid
- Domain MX records found valid
- SMTP mailbox Mailbox accepted valid
- Disposable domain Not listed as disposable valid
credits.used = 1: only SMTP verification is charged.The engine
What runs on every address
The free checks run together; SMTP verification follows only when requested.
Every address submitted goes through 19 checks, listed below with the field that carries each result in the API response. 18 of them consume no credit and are subject to no quota. One single check is charged, the SMTP verification of the mailbox, and only when it reaches a final verdict.
The list is exhaustive and it is read from the engine, not from a brochure. The figures and capabilities described on this site are read from the code of the service, not from a brochure. A check that does not exist in the engine is not announced, and a capability that is removed disappears from the site the day it disappears from the product.
-
Input No credit
one submitted address
-
18 checks, in parallel No credit
- syntaxe
- mx
- a aaaa
- catch all
- jetable
- malveillant
- typosquat
- typo domaine
- compte role
- aleatoire
- vulgarite
- alias
- pro particulier
- spf
- dmarc
- bimi
- age titulaire
- listes
-
SMTP verification, on its own 1 credit
Dialogue with the receiving server, without sending a message -
Verdict
- valid
- invalid
- risky
- unknown
See all 19 checks
| Check | API field | Cost |
|---|---|---|
| 1. RFC 5322 syntax and normalisation | features.syntax | Free |
| 2. MX records of the domain | features.dns.details.mxRecords | Free |
| 3. Fallback A and AAAA records | features.dns.details.hasARecord | Free |
| 4. SMTP verification of the mailbox | features.smtp | 1 credit |
| 5. Catch-all and accept-all detection | features.smtp.details.isCatchAll | Included in SMTP verification |
| 6. Disposable domains | features.disposable | Free |
| 7. Malicious domains | features.maliciousDomains | Free |
| 8. Domain typosquatting | features.typosquat | Free |
| 9. Domain typo, with a suggested correction | features.typoDomain | Free |
| 10. Role accounts | features.roleAccount | Free |
| 11. Random local part, entropy measurement | features.randomDetection | Free |
| 12. Profanity in the local part | features.profanity | Free |
| 13. Sub-addressing and aliases | features.aliasing | Free |
| 14. Business or consumer address | businessEmail, freeProvider | Free |
| 15. SPF record of the domain | features.domainHealth.checks.spf | Free |
| 16. DMARC policy of the domain | features.domainHealth.checks.dmarc | Free |
| 17. BIMI record of the domain | features.domainHealth.checks.bimi | Free |
| 18. Domain age and registrant, through RDAP | features.domainHealth.checks.age, .registrant | Free |
| 19. Allow list and block list of the organisation | features.listCheck | Free |
Decision
The four statuses, and what to do with them
A named verdict, its reason and a risk score remain available together.
The API returns one status among four, a reason, and a risk score between 0 and 100. A technically valid address whose score falls below 70 is degraded to risky rather than returned as valid. Only one of the four statuses escapes billing, the one that concludes nothing.
invalid
Reject the address, it will produce a hard bounce.
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.
Charged when SMTP was requested
risky
Accept under conditions, or discard according to the configured business policy.
The address is technically acceptable but carries a risk signal: disposable domain, malicious domain, typosquatted domain, or an overall score below the degradation threshold.
Charged when SMTP was requested
unknown
Do not decide on this result alone. No credit is charged.
The receiving server did not allow a conclusion: catch-all domain, greylisting delay, blocked probe, unreachable server or network error.
No credit charged
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.
Compare the four statuses in one table
| 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 |
Cost control
When a credit is charged
One billing rule covers real time and batch verification.
One rule governs billing, and it is short enough to be quoted in full rather than summarised. A credit is charged if and only if SMTP verification was requested and the final status is not unknown. Everything else on this page runs without consuming anything.
A credit is charged if and only if SMTP verification was requested and the final status is not "unknown".
Every address18 checksNo credit
On requestSMTP verificationOne credit when it concludes
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, les paliers de crédits et le simulateur sont publiés en français : consulter la grille tarifaire et les règles de crédits.
Three uses
Calling the API
Real time, files and forms use the same validation engine.
The service is a documented REST API. One address at a time for a signup form, a whole file for a batch clean up, and an embeddable widget for a form that should reject a bad address before it is submitted. The same engine answers in all three cases.
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.
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.
Product
Real time
One call, one address, one verdict. Suited to a signup form or to a check made at the moment the address is entered.
Marketing and CRM
Batch processing
A file is uploaded, processed, and returned enriched with a status and a reason on every line.
Acquisition
Form widget
A single script tag on the page, carrying no API key. The key is resolved server side and never travels in the public page.
Hosting
Where the service runs
The hosting statement and the boundary of that statement stay together.
YesWeCheck hosts its validation infrastructure with OVHcloud, in France and in Germany. That covers where the platform runs and where the validation data is stored. It says nothing about every outbound request the engine makes, and this site is careful never to turn one statement into the other.
An SMTP check is a dialogue with the receiving server of the domain being verified, wherever that server happens to be. That is inherent to the protocol rather than a hosting choice, and no email validation service can avoid it. A page describing the outbound flows one by one is being prepared in French and is not published yet.
Infrastructure in Europe
YesWeCheck hosts its validation infrastructure with OVHcloud, in France and in Germany.
No message sent
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.
Boundaries
What this site does not claim
Product facts remain separate from claims that have not been demonstrated.
Three things are worth saying because they are commonly expected of a service of this kind, and because saying them is what makes the rest usable. No formal certification is held. No response time figure is published. No availability rate is published either, for a reason written out in full.
- 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.
- No availability rate is published either. A rate is only worth something if the measurement that produces it is reliable over the whole period, which is not yet the case here.
Frequently asked questions
Frequently asked questions
The decisive answers remain in the initial HTML and do not depend on an interaction.
- What is YesWeCheck?
- YesWeCheck is a French email address validation platform. It provides a documented REST API for real time verification and batch processing, combining syntax, DNS and MX checks, disposable address detection, role accounts, domain typo detection and SMTP verification, and returns a status, a reason and a risk score. The infrastructure is hosted with OVHcloud, in France and in Germany.
- How many checks run on one address?
- Every address goes through 19 checks. 18 of them run without consuming a credit and without a quota: syntax, DNS and MX, disposable domains, malicious domains, typosquatting, role accounts, domain health. Only SMTP verification of the mailbox is charged, and only when it reaches a final verdict.
- When is a credit charged?
- A credit is charged if and only if SMTP verification was requested and the final status is not "unknown".
- Does the SMTP check send an email 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.
- Where is the service hosted?
- 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. It is not a claim that every outbound request stays inside the European Union, and this site does not make that claim anywhere.
Get started
Run your first check
Use the live demo, then create an account when you are ready to integrate the API.