API Validation Tools
Syntax Check
When requesting the verification of an email address, the Mailboxlayer API will first and foremost perform a standard email syntax check, hence, verify its compliance with regular expression rules, such as:
The format of email addresses is local-part@domain where the local-part may be up to 64 characters long and the domain name may have a maximum of 253 characters. The formal definitions are in RFC 5322 and RFC 5321 – with a more readable form given in the informational RFC 3696.
Local part:
- Uppercase and lowercase Latin letters (A–Z, a–z) (ASCII: 65–90, 97–122)
- Digits 0 to 9 (ASCII: 48–57)
- These special characters: # - _ ~ ! $ & ' ( ) * + , ; = : and percentile encoding i.e. %20
- Character . (dot, period, full stop), ASCII 46, provided that it is not the first or last character, and provided also that it does not appear consecutively (e.g. [email protected] is not allowed).
Domain part:
The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, consisting of letters, digits, hyphens and dots. In addition, the domain part may be an IP address literal, surrounded by square braces, although this is rarely seen except in email spam.
Example:
The API responses format_valid JSON object will return true or false depending on whether the email's syntax is valid.
Read more about the Email Address Syntax »
Typo Check & Suggestions
Suppose a potential misspelling or typo in the domain part of the requested email address is detected. In that case, the Mailboxlayer API will include an alternative email suggestion in the did_you_mean object of the API result set.
Example:
Please Note: The email address contained in the
did_you_meanobject solely serves as a suggestion and does not have any impact on other API response objects.
Real-time Verification
The Mailboxlayer API verifies email addresses by looking up MX records and using SMTP, the Simple Mail Transfer Protocol, which is the protocol we all use to move emails across networks.
Our system initiates real-time email verification by checking whether the requested domain is configured to receive email. This is where the API's MX-Records check comes into play. If MX-Records for the given domain are found, the API's mx_found response object will let you know.
Example:
Next, the mail server assigned to the requested email address is contacted via SMTP. The resulting SMTP conversation is the key factor that ultimately tells us whether the email address provided actually exists.
Example:
The API responses smtp_check JSON object returns true or false depending on whether the SMTP check was successful.
Note about SMTP: Although the process of sending emails may seem simple to the end user —just pushing a button— there is a significant amount of data being moved back and forth in getting an email from one server to another. Email servers often tend to act in very unpredictable ways and create problems out of nowhere, this is one reason why more and more businesses have been choosing to use an email verification service like the Mailboxlayer API.
Catch-all Detection
The Mailboxlayer API's real-time verification process does not end with one SMTP check. Since many email servers out there are configured to catch (receive) all incoming mail traffic, regardless of the requested email address's local part, a catch-all detection functionality has been implemented.
Due to its significant impact on API response time, this functionality is inactive by default. However, you may turn on catch-all detection simply by appending the API's catch_all parameter to the request URL and setting it to 1.
Example:
Example:
The API responses catch_all JSON object returns true or false depending on whether the requested email address is part of a catch-all mailbox.
Please Note: If the API's
catch_allparameter is inactive, the respectivecatch_allJSON response object will returnnull.
Role Check
Another part of Mailboxlayer email verification is detecting whether the requested email address is a role email address. A role email is an address that typically points to a function (e.g., "support", "postmaster") rather than an individual or name.
This type of email address may, in some cases, be unwelcome when sending email campaigns, as open rates tend to be very low.
Example:
The API response's role JSON object will return true or false depending on whether or not the requested email is a role address.
Free Provider Check
The Mailboxlayer API is connected to a daily-updated database containing all available email providers, allowing it to identify free email services like Gmail and Yahoo!.
Depending on whether the requested email address is found to use a free service, the API response's free JSON object will return true or false.
Example:
Although it is most common to include free email addresses in your list of recipients, for certain types of email campaigns, it might make sense to sort them out and send only to email addresses with individual domains.
Disposable Provider Check
The API will also return a disposable JSON object containing true or false, depending on whether the requested email address is found to use a disposable email provider such as mailinator.com or trashmail.com.
Example:
Disposable Email Services
A disposable email service lets users create a temporary email address that expires after a set period and is often used only once for tasks like account activation or password retrieval. Many of these email providers do not require users to sign up, which makes the inboxes of these one-time email addresses publicly visible. We strongly advise against including these types of email addresses on your recipient list.
Quality Score
To round off the Mailboxlayer validation & verification process, the API will return a numeric Quality Score ranging from 0 (Bad) to 1 (Good), reflecting the quality and deliverability of the requested email address.
Example:
This Quality Score is calculated for each requested email address based on an algorithm that grows smarter with each email address validated and is focused on evaluating three main factors:
- Appearance: How close does the local or domain part of the email address get to the most valued and highest quality email addresses.
- Deliverability: The general email syntax valid. Does the SMTP check confirm that the requested email address actually exists?
- Background: Is the requested email address associated with a free or disposable email provider? Does it point to a role?
Since the validity of the numeric quality score strongly depends on which type of email approach you are making, it is not possible to define clear lines between "worth sending to" and "not worth sending to". However, here are some guidelines that make sense ot us:
For transactional email:
| Score | Quality |
|---|---|
| 1.00-0.65 | Good |
| 0.64-0.33 | Medium |
| 0.32-0.00 | Bad |
For marketing email:
| Score | Quality |
|---|---|
| 1.00-0.80 | Good |
| 0.79-0.49 | Medium |
| 0.48-0.00 | Bad |
Please Note: The Quality Score solely serves as an indicator and should not be the only decisive factor when determing whether ot not to send to an email address.