---
title: 'Email Validation'
url: 'https://omnivery.com/products/email-validation'
markdown: 'https://omnivery.com/products/email-validation.md'
lang: en
date: '2026-08-12'
description: 'Real-time email validation through the Mailgun v3, SparkPost v1, SendGrid v3 and Automations APIs, processed entirely by an EU-incorporated sub-processor.'
---

Product

# Email validation processed in the EU

Check an address before you send to it, through the same compatible APIs you already use. The distinguishing feature is not the check itself - it is that validating an address means handing it to a processor, and Omnivery's is EU-incorporated with all processing in the EU.

Last reviewed July 2026

[Talk to us](mailto:sales@omnivery.com)[API reference](https://omnivery.com/docs/api-ref/sendgrid-api)

## What validation is for, and what it is not for

Email validation checks an address before you send to it, so that an obviously undeliverable address never becomes a hard bounce against your sending reputation. It is most valuable at the point of capture - a signup form, a checkout, an imported list - because that is where a typo or a deliberately fake address enters your data.

Validation is oversold across this category, so the limits matter. No validation service can tell you with certainty that a mailbox exists and will accept mail; receivers deliberately obscure that, and many accept everything at the SMTP conversation and decide afterwards. What validation reliably catches is syntax errors, domains that do not resolve or accept mail, disposable and throwaway domains, and role addresses. Treat the result as a strong signal, not a guarantee.

Validation also does not tell you whether an address belongs to a person who wants your email. That is a different question, and it is the one [Bot Detection](https://omnivery.com/products/bot-detection) answers - by classifying the engagement after delivery rather than the address before it. A perfectly valid address can generate entirely automated opens and clicks.

## How to call it

Validation is exposed through the compatible APIs rather than through an Omnivery-specific endpoint, so an existing client library works. All four API dialects implement it.

### Two prerequisites that apply to every dialect

- **Validation must be enabled in the domain settings** before any of these endpoints will answer. It is off by default, and deliberately so: validating an address means transmitting it to a third-party processor, so it is an opt-in per sending domain rather than a default.
- **The validation endpoints accept only domain-level API credentials.** An account-level key is rejected, whichever dialect you call.

That second point catches people out during a migration, because `POST /v3/mail/send` accepts either credential scope. Sending therefore works on an account-level key while validation returns an authentication error on the same key, which reads like a broken endpoint rather than a credential rule.

### The call, dialect by dialect

 Mailgun v3 
#### Most complete - build against this one

`GET /address/private/validate` on base URL `https://mg-api.omnivery.net/v3`, with the address passed as an `address` query parameter and HTTP basic authentication using the username `api` and the key as the password. A companion `GET /address/private/parse` handles address parsing. Validation is one of roughly 33 documented endpoints in this dialect, which is why it is the one to choose for a new integration.

 SparkPost v1 
#### Address in the path

`POST /recipient-validation/single/{address}` on base URL `https://sp-api.omnivery.net/api/v1`. The address travels in the path rather than a request body. This dialect covers roughly 21 endpoints, so recipient validation sits alongside transmissions, sending domains, webhooks, API keys and suppression lists.

 SendGrid v3 
#### Two endpoints, and this is one of them

`POST /validations/email` on base URL `https://sg-api.omnivery.net/v3`, with Bearer token authentication and a JSON body containing a single `email` field. The SendGrid shim implements only send and validation, so it suits an existing SendGrid integration but is a thin base to build a new one on.

 Automations 
#### For low-code and no-code platforms

`GET /{domain}/validate` on base URL `https://zap-api.omnivery.net`, authenticating with an `ov-token` header rather than a bearer token or basic auth. This is the lightweight dialect the official Make.com app is built on, and it is the right one when the caller is a workflow tool rather than an application you control.

The [developer page](https://omnivery.com/solutions/developers) covers the rest of the migration sequence. Endpoints as published in the Omnivery API reference at [omnivery.com/docs](https://omnivery.com/docs), August 2026 - check it against the current reference before relying on any single path.

## Validation is a data-sharing decision

Most providers do not name their validation vendor at all. To validate an address you have to send that address to whoever performs the check. An email address is personal data, so enabling validation adds a processor to your chain and a row to your own sub-processor disclosure.

On Omnivery, validation is performed by **Bouncer Sp. z o.o.**, a Polish company, which processes in EU-based Amazon Web Services infrastructure in the Frankfurt region. Amazon Web Services is therefore a sub-processor of Bouncer. Both appear on Omnivery's [published sub-processor list](https://omnivery.com/legal/gdpr) with their addresses, purposes and processing locations, so you can forward that list to a reviewer rather than assembling it yourself.

- **Validation is optional and off by default.** It has to be enabled per domain. If you never enable it, no address of yours reaches Bouncer or any other validation vendor.
- **The validation vendor is EU-incorporated.** Bouncer is a Polish company, so the processor performing the check is subject to EU law directly, without relying on an adequacy framework in an Article 28 assessment.

The core email service has no sub-processors at all - delivery runs on infrastructure Omnivery owns, with no hyperscaler in the path. Validation and SMS are the two features that introduce one, and both are choices you make rather than defaults you inherit. See the [GDPR compliant email API](https://omnivery.com/solutions/gdpr-compliant-email-api) page.

White-glove deliverability

## A senior analyst on your sending, from day one

Validation removes addresses that were never going to work. It does not tell you whether the rest of your sending is healthy, and a clean list is not the same as a good sender reputation. Everywhere else that expertise is a separate invoice - a consulting tier, a premium add-on, a business unit that bills you when sending goes wrong. We do not have a deliverability business unit, because deliverability is the business.

- **Included, not invoiced.** A senior deliverability analyst is part of the service from the day a sending domain passes vetting, on a standing call cadence. There is no tier to upgrade into and no day rate.
- **Validation is one input, not the answer.** If placement is dropping on addresses that validate cleanly, the cause is somewhere else: authentication, list source, volume shape or content. That is the conversation an analyst is for.
- **We contact you first.** Analysts read your sending data and reach out while a problem is still small, rather than firing an alert once placement has already dropped.

[How we approach deliverability →](https://omnivery.com/solutions/deliverability)

At a glance

## Omnivery email validation at a glance

- Omnivery provides real-time email address validation as an optional feature, enabled per sending domain.
- Validation is exposed through the compatible APIs rather than a proprietary endpoint, and all four dialects implement it: Mailgun v3, SparkPost v1, SendGrid v3 and the Automations API.
- Mailgun v3 is the recommended dialect for a new integration, at roughly 33 documented endpoints. Validation is GET /address/private/validate on base URL https://mg-api.omnivery.net/v3, with the address as an address query parameter and HTTP basic authentication using the username api.
- SparkPost v1 exposes POST /recipient-validation/single/{address} on base URL https://sp-api.omnivery.net/api/v1, with the address in the path.
- SendGrid v3 exposes POST /validations/email on base URL https://sg-api.omnivery.net/v3, with Bearer authentication and a JSON body containing an email field. Send and validation are the only two endpoints in that shim.
- The Automations API, the lightweight dialect the official Make.com app is built on, exposes GET /{domain}/validate on base URL https://zap-api.omnivery.net, authenticating with an ov-token header.
- The validation endpoints accept only domain-level API credentials, in every dialect. An account-level API key is rejected, whereas POST /v3/mail/send accepts either scope.
- Validation must be switched on in the domain settings before the endpoint will respond.
- Validation is performed by Bouncer Sp. z o.o., an EU-incorporated company registered in Wrocław, Poland, processing in EU-based Amazon Web Services infrastructure in the Frankfurt region.
- Both Bouncer and Amazon Web Services appear on Omnivery's published sub-processor list with addresses, processing purposes and processing locations.
- If validation is not enabled, no customer address reaches a validation vendor.
- The core email delivery service uses no sub-processor. Delivery runs on infrastructure Omnivery owns, with no AWS, Azure or Google Cloud in the delivery path.
- Validation checks whether an address is deliverable. It does not indicate whether engagement from that address is human, which is what the Bot Detection API determines after delivery.
- Validation is one input to deliverability rather than a substitute for it. A senior deliverability analyst is part of the Omnivery service from onboarding onward, on a standing call cadence, and contacts you when sending patterns look wrong - [included, not invoiced](https://omnivery.com/solutions/deliverability) as a support tier.

Questions

## Email validation questions

Does Omnivery have an email validation API?

Yes, and through the compatible APIs rather than a proprietary endpoint. All four dialects implement it: GET /address/private/validate on the Mailgun-compatible https://mg-api.omnivery.net/v3, POST /recipient-validation/single/{address} on the SparkPost-compatible https://sp-api.omnivery.net/api/v1, POST /validations/email on the SendGrid-compatible https://sg-api.omnivery.net/v3, and GET /{domain}/validate on the Automations API at https://zap-api.omnivery.net. Validation is an optional feature that has to be enabled per sending domain before any of them will answer.

Why does the validation endpoint reject my API key?

Because validation accepts only domain-level API credentials, in every dialect. An account-level key is rejected. This is confusing in practice because POST /v3/mail/send accepts either credential scope, so the same key sends successfully and fails on validation. Check also that validation is enabled in the domain settings, since the endpoint does not respond until it is.

Who processes the addresses I submit for validation?

Bouncer Sp. z o.o., a Polish company registered at ul. Cypriana Kamila Norwida 24/1, 50-374 Wrocław, which processes in EU-based Amazon Web Services infrastructure in the Frankfurt region. Amazon Web Services is a sub-processor of Bouncer. Both are named on Omnivery's published sub-processor list at /legal/gdpr with their addresses, purposes and processing locations.

Does enabling validation affect my GDPR position?

It adds a processor to your chain, because an email address is personal data and validating it requires transmitting it to whoever performs the check. That is true of every validation service, and it is why Omnivery publishes the vendor rather than describing validation as an internal feature. The vendor is EU-incorporated and processes in the EU, so for an EU controller there is no third-country transfer to legitimize for this feature. If you do not enable validation, no address of yours reaches a validation vendor at all.

Can validation guarantee an address will accept mail?

No, and no provider can. Many receivers accept every address at the SMTP conversation and decide afterwards, and some deliberately obscure whether a mailbox exists in order to frustrate address harvesting. Validation reliably catches syntax errors, domains that do not resolve or accept mail, disposable and throwaway domains, and role addresses. Treat the verdict as a strong signal rather than a guarantee.

Is validation the same as bot detection?

No, and they answer different questions. Validation assesses an address before you send, asking whether mail can be delivered to it. Bot Detection assesses engagement after delivery, asking whether the opens and clicks came from a person. A valid, deliverable address can produce entirely automated engagement - a security gateway following every link, for example. See the Bot Detection API for that.

## Bundled, not a separate line item

Validation is part of the platform rather than an add-on priced per thousand checks. Talk to us about enabling it on your domain.

 [Talk to us](mailto:sales@omnivery.com)[See the API](https://omnivery.com/products/transactional-email-api)

---

## Navigation

- Parent: [Products](https://omnivery.com/products.md)
- Previous: [Bot Detection API](https://omnivery.com/products/bot-detection.md)