Security and privacy
Built to verify email data without compromising it.
Most security pages blur two very different things together. One is what a system does because of the way it is built. The other is what somebody has to sign their name to. The first kind is all here. The second stays visibly marked until it has been approved.
Properties of the design
True because of how it is built.
None of these is a policy somebody could quietly switch off with a config flag. They follow from the shape of the system.
Nothing reaches the address
The prober connects, greets, names the sender and the recipient, then resets and disconnects. There is no DATA stage in it at all — not a skipped one, not one behind a flag. No code path in there can put a message in a mailbox you verify.
Server reply text never leaves us
You get stable reason codes instead. Raw reply text gives away details of the destination’s infrastructure, it can carry control characters or personal data nobody asked for, and it changes the day a provider rewords a message. A fixed vocabulary is safer for you and steadier to build on.
Unmeasured evidence can’t reject anybody
Probe evidence is only allowed to produce a rejection where we have measured how accurate it is for that provider. Everywhere else the default is fail-safe: no rejection. Rejecting on unmeasured evidence is how a provider’s blanket policy turns into a real person who can’t register.
Access is always authenticated
Anonymous API access isn’t an option you can switch on. Credentials are issued per integration, so one can be rotated or revoked without disturbing the rest, and request volume is bounded per caller and per source network.
Data lifecycle
What happens to an address you send us.
- 01
It arrives
Over an encrypted transport, from your server or from this website.
- 02
We gather evidence
DNS lookups, routing checks, and an SMTP probe where one is worth doing.
- 03
We reach a conclusion
A status, a recommendation and reason codes. DNS and SMTP evidence get their own timestamps.
- 04
We keep it
So that checking the same address again does not send us back to someone else’s mail server.
- 05
We delete it
On schedule, and on request.
The retention window [PERIOD] and the deletion process [PROCESS] both come from Legal. Keeping the conclusion is what makes a repeat verification cheap and consistent: the same address gets the same answer under the same identifier, rather than a second probe against somebody else’s mail server.
This website
What the free checker stores.
Compliance
These need a signature, not a design decision.
A “compliant” badge earned by following good practice is not a certification. Nothing appears here until it is actually held and can be evidenced.
GDPR posture
[STATEMENT] — lawful basis, data-subject requests, and the role the service plays as processor.
Certifications
[LIST OR NONE] — only what is actually held, with the scope of the audit.
Processing regions
[REGIONS] — where verification runs and where results are stored.
Data processing agreement
[AVAILABILITY] — see the DPA page.
Sub-processors
[REGISTER] — who else touches the data, and for what.
Encryption
[IN TRANSIT / AT REST] — stated precisely rather than as a reassuring adjective.
Every marked item has a named owner in Legal and a due date before launch.
Availability
How the system behaves when something is wrong.
Failures are not verdicts
An infrastructure failure never renders as a verification result. A timeout is unknown; a 5xx is a service error. Neither is undeliverable.
Bounded waiting
Slower evidence is queued and polled on an explicit interval. Nothing sits holding a socket open and hoping.
Circuit breaking
When a provider stops behaving, we stop probing it and the result says so. The alternative is a stream of confident, wrong rejections.