Security and data handling
Email verification security and data handling
Emvero receives the email address you submit and stores its verification record. A full check may disclose that address to the receiving mail server without sending an email. This page explains the data flow, access controls, retention and processing commitments you can review before using the service.
Verification and access
What a check sends and returns
No verification message is sent
During a mailbox check, Emvero connects to the receiving server using the SMTP mail protocol. The server sees the sender and recipient named in the session. The connection is reset and closed before DATA, the stage that would send message content. No subject or body is submitted, and no email is delivered.
Structured evidence and reason codes
The API returns individual check results and stable reason codes. It excludes raw mail-server reply text, which can contain infrastructure details, control characters or personal data. The wording of a server reply can also change without the underlying evidence changing.
How SMTP replies affect the result
An SMTP refusal may reflect server policy or conceal mailbox information. Under the current policy, probe evidence does not trigger rejection; the result may be unknown with a recommendation to confirm the address. Invalid syntax or a nonexistent domain can justify rejection.
Keep API credentials on your server
The verification API requires a credential kept on your server. Use a separate key for each integration so you can revoke it independently. Requests are limited per caller and source network. Public website lookups have separate access rules; they do not grant access to the authenticated API.
Full verification may contact the receiving mail server. A domain check stops at address format, domain and mail-routing evidence. Both return structured results for your application to interpret.
Submitted addresses
What happens to the address you submit
- 01
Submit an address
Use the website checker or send an authenticated API request from your backend over HTTPS.
- 02
Collect evidence
Emvero checks the address format, domain and mail routing. A full check may also probe the mailbox; a domain check opens no SMTP session.
- 03
Return the result
A completed check returns a status, recommended action and reason codes. DNS and SMTP observations have separate timestamps.
- 04
Retain the record
Emvero stores the submitted address with its result. A new request may reuse a sufficiently fresh cached result; later checks may need updated evidence.
- 05
Delete expired records
A scheduled cleanup deletes verification records after they expire. You can also request deletion.
Verification records are retained for 30 days. Deletion requests are completed within 72 hours. Retention does not make evidence current: a record can remain stored after its findings need updating.
Website controls
Website limits and analytics choices
Data-processing commitments
Information for a security review
These are Emvero’s stated processing and security commitments. The data processing agreement (DPA) covers processor terms. Contact sales for documents or written answers your security review needs.
Processing roles
Our role depends on the data: Processor for the addresses you send, controller for your account.
Certifications
None held today.
Storage and probe locations
Accounts and results are stored in Germany. SMTP probes run on a separate fleet within the European Economic Area.
Data processing agreement
Signed on request, and part of every enterprise agreement. The DPA page sets out the terms for processing submitted addresses on your behalf.
Sub-processors
Hetzner Online GmbH for hosting and storage; FastVPS OÜ for the probe fleet, inside the European Economic Area, with a planned move to OVHcloud; Google for website analytics. Analytics cookies and product events require consent.
Encryption commitments
TLS 1.3 in transit, AES-256 at rest, keys rotated yearly. Ask sales for a written description of the scope if your security review needs it.
Using the API
Handle pending work and unavailable evidence
Distinguish an error from a result
An HTTP 5xx response indicates a service error. A completed check can return unknown when it lacks enough evidence, including when a mailbox check timed out or could not run. Neither establishes that the address is undeliverable.
Follow the returned retry interval
If a request returns pending, work is still in progress. Wait for the returned retry interval before retrieving the result again. Pending is a transport state, not a final verdict about the address.
When an SMTP probe is delayed or skipped
Provider pacing and service protections can delay or skip an SMTP probe. The response records the reason and retains the available evidence. A skipped probe does not establish that the mailbox is absent.