Email and email validation technologies continue to evolve and it is increasingly important that businesses keep up with these changes to ensure they are protected and getting the most out of their email lists. Whether the intention is to verify emails for a mailing campaign, verify users when they sign up on a webpage or ensure that your data is compliant with privacy laws like the General Data Protection Regulation (GDPR), our DOTS Email Validation 3 service helps ensure your email data is accurate, valid, and up-to-date.
In our Applications Engineer department, we are proud of our product expertise and happy to work with you and make integration recommendations that best meet your needs. We have found that each use case and integration scenario is different and may require using different parts of the email validation service to achieve best results. We always recommend starting with a free API key and checking out our comprehensive and up-to-date developer guide for a strong understanding of everything our service can do. With that said, below are some of the most common discussions we have with our clients when integrating our Email Validation service.
Setting up Email Validation’s web service call
Our recommended operation for the service is the ValidateEmailAddress operation. This method has four input fields; EmailAddress, AllowCorrections, Timeout and LicenseKey. The EmailAddress field should be the email address to be validated and the License key should be the trial or production key supplied by Service Objects (you can get yours here). The AllowCorrections and Timeout fields can be used to fine-tune the results from our email validation service.
The AllowCorrections field will essentially tell the service whether to attempt a correction on the email address if the original one is found to be invalid. This is helpful, especially for scenarios where the user mistypes their email address. This can also be set to “false” to weed out users that do not “strongly” type their email addresses.
The Timeout value uses a number in milliseconds. This value sets the maximum amount of time for our services to communicate with a mail server in a given request. One of the key features of our service is that it performs real-time SMTP communication with mail servers and part of this communication is waiting for the mail server to respond. So in short, the longer the timeout, the greater the validation accuracy will be. This will help turn the unknown email addresses (score 2; more on this below) into either good or bad emails. Most mail servers will respond very quickly to communication, but smaller or lesser known servers can take a bit of time to respond.
Email Validation scoring
There are a lot of different results returned in the Email Validation service and the best use case depends on your business logic and what you are hoping to achieve with the service. Arguably, the first return you will want to look at would be the score value that is returned, below are the scores and a brief description.
|Email is Good
|Email is Probably Good
|Email is Probably Bad
|Email is Bad
Generally, we recommend that our clients accept emails with a score of 0, 1 or 2 as “good” emails. If you want to be more conservative with email campaigns then only including emails with scores of 0 or 1 would be the way to go. This may not be the best option if you are validating users that fill in a form on your webpage, as many popular catch-all domains (e.g. yahoo, hotmail, etc.), will return an Unknown (2) score from the service. Conversely, considering good emails as scores from 0 to 3 would be an option if you want the highest volume of possible good emails.
The Email Validation service also returns Warning and Note codes for each email that is validated. Generally speaking, the Warning codes help define what is detrimental to the email score. Warning flags like Bot, Vulgar, Garbage and DisposableEmail are obvious indicators of a bad email address. But a warning flag like “KnownGreylister” indicates that the mail server is known to use greylisting techniques but this doesn’t necessarily mean the email address is bad. If you are sending an email campaign through MailChimp, Marketo or similar platforms, then you may experience temporary bounce backs on email addresses with the KnowGreylister flag, as those email domains will give a temporary reject message due to unfamiliar mail servers.
There are over 20 Warning codes that our Email Validation service can return, see the table below for the complete list and a brief description of each.
|Indicates if the top-level-domain is not recognized by ICANN.
|Indicates if the email is syntactically invalid.
|Indicates if email is syntactically invalid for the given domain.
|Indicates if the domain is unregistered or it does not have at least one MX or A record configured to relay email.
|Indicates that the registered DNS does not have an MX record.
|Indicates that the email address is known to be in bulk marketing lists.
|Indicates if the email address is believed to be an alias address.
|Indicates if the email address is believed to be a bogus email. For example, firstname.lastname@example.org.
|Indicates if the email address is believed to be a bogus SMS domain address.
|Indicates if the email address is believed to contain garbage-like keyboard strokes and/or garbage-like characters.
|Indicates if vulgar words or content are found in the email address.
|Indicates if the mailbox is currently full and unable to receive any new messages.
|Indicates if the mailbox is reported by the hosting mail server as being busy and unable to currently accept new messages.
|Indicates if the email address is believed to be disposable. Disposable email address are generally only valid for a short period of time before they are disposed and are then no longer valid.
|Indicates if the mailbox is believed to be a spam trap.
|Indicates if the email address is known to have participated in spam-like activities.
|Indicates if the domain was found to be in one or more blacklists.
|Indicates if the email address has been identified as a known complainer of receiving unsolicited mail.
|Indicates if the mail server is known to commonly use greylisting techniques. This means that if your mail server is communicating with this domain for the first time or if you are sending bulk messages or messages in high frequency then you may be greylisted by them and experience temporary bounce backs.
|Indicates if the mail server requires opting-in to send and receive messages.
|Indicates if the mail server only relays messages for users that are whitelisted.
|Indicates if the mail server refuses to accept an SMTP connection.
|Email is Bad - Subsequent checks halted.
|Indicates that the email address failed a critical check, such as SMTP verification.
|Indicates that the email address has been reported as being a known bot.
Notes from Email Validation typically provide additional information about an email domain and can be leveraged to intelligently target specific email addresses. For example, if you have an email sign up form and you want to limit the sign-ups to business emails, then you might want to want to look for email addresses with the BuisnessAddress note flag, which would indicate that the email is likely associated with a business. Or maybe you want to identify country based email addresses? Then it may be wise to filter out emails that receive the CCTLD note code as these will indicate emails that have a Top-Level Domain (i.e. .com of email@example.com) that is associated with a specific country. In addition, we recently rolled out a new feature that can detect the geographic location of the email’s mail server.
Other Note Codes you may want to pay attention to are those indicating the service had trouble connecting to the mail server. While these notes don’t indicate that an email is bad, they do reflect simulated interactions with mail servers and may indicate trouble contacting customers via email campaign or through typical email delivery. You can see the complete list of Note Codes and their descriptions below.
|Indicates if the top-level-domain (tld) represents a specific country. For example ".us" implies United States.
|Indicates if the domain of the email is a public-register domain, where users can sign up for email accounts for free.
|Indicates if the domain is a known Mail-to-SMS Gateway.
|Indicates if the email address appears to be a role that is designed to be anonymously managed by one or more persons.
|Indicates if the email address appears to be work related.
|Indicates if the mail server responded with a known greylist tactic.
|Indicates that the mail server may be temporarily unavailable or too busy to respond.
|Indicates that a connection to the recipient mail server could not be established.
|Indicates that the connection to the mail server timed out when trying to verify the email address.
|Indicates that the email address was temporarily rejected by the mail server. This is also known as a soft-bounce and the rejection is not permanent. There are many reasons for why a mail server may respond with a temporary reject. The mailbox or server may be busy, unavailable, or using a greylist. When a mail server does this it typically wants you to wait at least 15 minutes and then try again later.
|Indicates that the host mail server is known to communicate slowly and that real-time verification of an email address may not be possible unless adequate time is provided. In some cases a timeout time of 90 seconds or more may be necessary to verify email addresses with these mail servers.
|Varies (Example: JP)
|Countries: The ISO2 country code for the country where the mail server(s) is located. If mail servers are found in more than one country, then all country ISO2 codes will be represented in a pipe-delimited list. ***In BETA
|Varies (Example: OS|TY)
|Region: The region in the country where the mail server(s) is located. The region is commonly returned as a two-character abbreviation. If mail servers are found in more than one region then the value will be a pipe-delimited list of the regions. ***In BETA
|Varies (Example: Osaka|Tokyo)
|Localities: The name of the locality where the mail sever(s) is located in. If mail servers are found in more than one locality then the value will be a pipe-delimited list of all the localities. ***In BETA
|Varies (Example: 543-0062 | 102-0082)
|PostCodes: The post code of where the mail server(s) is located. If multiple post codes are found, then the value will be a pipe-delimited list. ***In BETA
Our Email Validation service is robust, multi-featured and constantly under refinement. Don’t hesitate to schedule an integration call with our Applications Engineering team with any integration or best practices questions, we are glad to help.