Some of your contact email addresses may contain an IP address, for example, john.smith@[123.123.123.123] rather than a domain name, such as john.smith@example.com. Can you use these email addresses for mailing purposes?

The short answer is technically yes, but really no.

The Simple Mail Transfer Protocol (SMTP) does allow an IP address to be used instead of a domain name under special circumstances when encapsulated in brackets, such as our previous example of john.smith@[123.123.123.123], However, here are some common reasons why doing so may end up with the email message being bounced back and/or not making it to the intended recipient.

• By default, it is not uncommon for many mail servers to not accept email addresses without a ‘fully qualified domain name’ (FQDN).
• For a mail server that hosts more than one domain, the FQDN in the email address is necessary to identify which domain group the email user belongs to.
• Email addresses with IP addresses often get flagged as spam.

When is an IP address allowed?

Email messages are transmitted using the Simple Mail Transfer Protocol (SMTP), which is defined by the Request for Comments (RFC) 5321, 5322 and various extensions. In the email address specification section of RFC 4532, we see where the specification mentions the use of a domain-literal form, i.e. a domain’s literal IP address.

RFC 5322 – 3.4.1

The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a hostname or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain- literal form, the domain is interpreted as the literal Internet address of the particular host.

In other words, RFC 5322 says that either a domain name form or a domain literal form may be used to describe the domain portion of an email address. Where the domain name form is what we are typically used to seeing (ex: john.smith@example.com), and the domain literal form being an IP address (ex: john.smith@[123.123.123.132]). It goes on to say that, “In both cases, how addressing is used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321].” So, we must dig further to learn more about when an IP address may be acceptable to use.

In RFC 5321 we find the Host and Domain Names listed under sections 2.3.4 and 2.3.5 respectively. Here we see the RFC strongly recommending against the use of an address literal, also known as a domain literal or IP address.

RFC 5321 – 2.3.4

Hosts are known by names…they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.

And then we finally get a glimpse as to when an IP address would be allowed.

RFC 5321 – 2.3.5

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP…There are two exceptions to the

rule requiring FQDNs:

o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4. o The reserved mailbox name “postmaster” may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used.

Two situations where IP is allowed

We find that a domain name may be replaced with an IP address if the host has no name, as described below in sections 4.1.3, or if the email address is for the host postmaster (for example: postmaster@[123.123.123.123]). Now we’re finally getting somewhere. So according to the RCF below (emphasis mine), an IP address is allowed in email address when a domain name is not available in DNS, otherwise it must be an email addressed to the host postmaster.

RFC 5321 – 4.1.3

Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized “tag” that identifies the address syntax, a colon, and the address itself, in a format specified as part of the relevant standards (i.e., RFC 4291 [8] for IPv6).

IP addresses often associated with spammers

The RFC states that an address literal (IP address) is allowed as an alternative to a domain name when the recipient host is not known in DNS, but why wouldn’t a domain name be available? There are plenty of reasons for why a mail server might not be listed in DNS, but a mail administrator who is in charge of keeping out spam is not likely willing to take the risk. Many mail servers require reverse pointer (PTR) DNS records from the submitter. A PTR record allows the receiving mail server to perform a reverse lookup on the IP address that is sending the email message. The PTR record should resolve to a FQDN. If a PTR record does not exist or if the FQDN it resolves to does not match the one in the email address, then it is likely a spoofed email message and the recipient mail server will reject it. This is just one common method used by mail severs to try and fight spam.

A mail server without a FQDN will not have a PTR record, so if it were to try and send out mail then it is likely its messages would be rejected by most recipient mail severs. If chances are that your mail server will not accept email from a mail server without a FQDN then you likely wouldn’t want to send email to one, as you wouldn’t be able to get a reply. More likely, when a FQDN is not available it means there is no mail server that accepts email and that the IP address is just being used as a burner to blast out spam. This is why so many address literal form email addresses appear in various blacklists and why they are associated with spammers.

Address literal form disabled by default

It is common for many mail servers to disable the acceptance of address literal form by default or not support them at all. After all, even though the RFC does allow the use of IPs under special conditions, it does strongly recommend against using them. That coupled with the high abuse of address literal form by spammers and malicious users it makes sense for most mail servers to not allow them. If the mail server does not have the acceptance of address literals enabled, then it will likely reply with a permanent reject (aka a hard bounce). In other cases, the recipient mail server may reply with a temporary reject (aka a soft bounce) and instructions for the sender to use a FQDN instead and try again.

Domain groups

Mail servers are designed to host multiple domains. If one of these is reached by its IP address via address literal form, then it would be unable to route the email message to the end recipient because it needs to FQDN to know which domain group the message belongs to. For example, say you have three different email addresses.

sales@exampleone.com
sales@exampletwo.com
sales@examplethree.com

In our example, these email addresses are for three different businesses where ExampleOne is a large global leader in its marketspace, ExampleTwo is a longtime rival of ExampleOne and ExampleThree is fledgling competitor. ExampleOne and ExampleTwo are too big to adequately manage all their email traffic on their own, so they outsource to an Email Service Provider (ESP). ExampleThree is too small and lacks the resources to host their own mail, so they too outsource to an ESP. As it turns out, the ESP is so popular (cough, Gmail… cough, Office365) that all three businesses end up using the same ESP and the ESP is using the IP address 123.123.123.123.

Now, let’s say that we wanted to write the email addresses in domain literal form and use their IP address instead of the domain. If we were to do this then all three email addresses would end up looking the same.

sales@[123.123.123.123]

If we were to try and send a message to sales@[123.123.123.123] then the ESP’s mail server(s) wouldn’t know who it belongs to and it would be unable to deliver the message. Even in an example where a company hosts their own mail server and has only one domain, chances are that the mail server will still require the domain. Likely because it is configured that way, or it is simply a part of the way it works.

IPs are accepted but discouraged

In conclusion, while an IP address is technically allowed, it is not widely accepted and is in fact highly discouraged. However, because it is technically required to be accepted for mail server, we find that many servers may behave differently when they encounter them. The DOTS Email Validation service will attempt to verify these types of email addresses.

If the IP address is bogus and does not resolve, then the Email Validation service will fail the email address. If the IP does resolve and communication can be established with the recipient mail servers then it may respond with a temporary reject code (soft bounce), a permanent reject code (hard bounce) or it might accept the email. If the mail server does accept the email, there is a possibility that it will be delivered to a catchall mailbox. Overall, regardless of how an EV service responds to an email address with an IP instead of a domain, you should give some thought on whether you want to keep these addresses in your mailing lists or not.

If you would like to see how a validation service works, please sign up for a free Email Validation API trial key and test up to 500 email addresses.

 

We all know that paying attention to email security can protect sensitive information from prying eyes. But if you do email marketing, did you know that it can also improve your open and response rates as well?

Transport Layer Security, or TLS for short, is a relatively new security standard for email. It is the successor to the previous Secure Sockets Layer (SSL) standard familiar to many. In a previous blog article, we examined the security implications of TLS for email privacy. Here, we will take a deeper look at how it can affect your marketing as well.

TLS, email security and open rates

TLS is optional for people to use, and years ago, according to this article, at first people only used it when there were privacy concerns about the contents: for example, when the client wants to receive only encrypted emails. But it goes on to point out that today, there is an even bigger reason for marketers to use TLS encryption: open rates.

As an example, Google’s Gmail flags the security settings of your email for all to see. When you are the sender, choosing recipients who are not using TLS security will cause a red, unlocked “padlock” icon to be displayed in the upper right-hand corner of your compose screen. More importantly, when you aren’t using TLS, your email is shown with a similarly broken padlock, and your sender ID is displayed with a big, red question mark next to it.

 

So why does this matter – especially if you aren’t sending things like people’s account numbers or the top-secret plans for the next Space Shuttle? Appearances, pure and simple. Would you open an email from someone being flagged as “suspicious”? This source notes that even though TLS requires bandwidth and isn’t a perfect, foolproof solution for security, marketers are often concerned nowadays about how their emails appear to the recipient, and a broken red padlock isn’t exactly reassuring.

In a blog post announcing these changes, Google itself is far from comforting for recipients, noting that “Not all affected email will necessarily be dangerous. But we encourage you to be extra careful about replying to, or clicking on links in messages that you’re not sure about.” Ultimately, you want your outbound email marketing messages to pass Google’s security checks so that the percentage getting opened is as high as possible.

What you should do, and how we can help

As a marketer, this means that you should determine if the email address you are sending to supports TLS, and how you can use this additional security measure in marketing efforts to your advantage. Specifically, you want to make sure that you are sending TLS encrypted messages to recipients using TLS servers, so you get the security stamp of approval.  At the very least, you want to track and understand the impact on open rates for emails that are flagged as not secure.

So how do you determine whether an email address on your list uses TLS or not? Our DOTS Email Validation tool can come to your rescue here – it returns a Notes code letting you know whether the recipient’s email server supports TLS connections for encrypted email communication. Plus you get all the other benefits of email validation, including verifying and correcting addresses, as well as flagging spam traps, honeypots, known spammers and bogus addresses. Want to learn more? We’re always happy to help.

Wouldn’t it be great if there were a service where you could enter an email address, and it would be validated and automatically corrected when an error was found?

The good news is that this service already exists: we do have email correction embedded in our DOTS Email Validation service. However, it is turned off by default. Turning it on is as simple as setting the service’s ‘AllowCorrections’ input value to true. But there are good reasons you might not want to do this. This blog will examine when you should consider automatic email correction, and when you shouldn’t.

The pros and cons of email correction

Of course, the idea of email correction sounds and seems simple enough. In this day and age of auto-correct, why would you not want to correct? But like auto-correct on your phone, when it gets it wrong, the outcomes can range from hilarious to frustrating.  With email address correction, getting it wrong can have far more expensive outcomes, from inefficiencies to expensive penalties. To help avoid these outcomes, it is best to focus on how your email addresses are collected, how you plan to use them and ultimately if allowing email addresses to be corrected makes sense for your needs.

Correcting email addresses

First, it is important to understand that when we talk about email corrections, we are generally talking about the domain portion of the email address – the part after the @ symbol.  The alphanumeric characters before the @ symbol are usually left untouched.

With that understanding, what kind of corrections can be expected from our Email Validation service when the ‘AllowCorrections’ input field is set to true? This question gets to the heart of why we added this functionality in the first place.

Before we added the option to correct emails, our clients would ask us why we are not able to fix basic typos, like ‘@gmial.com’ corrected to ‘@gmail.com’.  On the surface that seems like a reasonable request, and depending on what your user base looks like, you may want these kinds of corrections.

On the other hand, you may also want “@ymial.com” email addresses corrected to “@gmail.com”. There is a problem here though: “ymail.com” is a legitimate domain and changing the domain to ‘@gmail.com’ would be taking a legitimate address and ‘correcting’ it to a bad or incorrect address.

Collecting email addresses

The two most common scenarios for collecting email addresses are; real-time collecting of email addresses through data entry forms, like a web registration form, versus importing or using existing email lists. In the latter case, these emails have already been previously collected or purchased and are stored in your CRM or marketing database. Using these two common scenarios, we can deduce how best to handle most situations where email validation and correction is deployed.

When to allow email address corrections

Setting ‘AllowCorrections’ to equal true is ideal to use as a suggestion for corrections on real-time forms.  Using the setting and the result, organizations may choose to alert the user to potential errors and the suggested correction, since the user is present at the time of validation, and can update or correct any data before it is submitted.  The key is to make sure your business rules do not interfere with your user’s intention.  You do not want to end up in a frustrating loop of suggesting a correction to someone who is happy with their input.

When validating an email list, checking and allowing for corrections is really about your intentions.  Are you trying to reach as many people as possible, regardless of accuracy?  Setting the ‘AllowCorrections’ value to true will give you the highest number of mailable email addresses, with the understanding that accuracy will likely suffer.

Using ‘AllowCorrections’

To accommodate those who want email corrections and those who do not, we added the AllowCorrections option to the input parameters of the Email Validation service. Using it is as simple as setting the input value for ‘AllowCorrections’ to true or false.

It bears repeating that since the variation of possible good emails (based on only the domain check) is nearly limitless, applying corrections can be dangerous: this is simply the nature of these corrections. There are, of course, uses cases where you may choose to do them, but we reiterate that using them is risky and requires really examining your use case for it.

If your organization is not sure what is the best option, you can always reach out to us and we can help you make the best decision.

Whether it is to comply with GDPR, cleanse emails for a mailing campaign, or ensure that new users provide you with a deliverable email address, DOTS Email Validation 3 (EV3) is a powerful tool that will ensure the accuracy of your email addresses. Our email validation service is extremely popular with customers and data validation experts alike for a good reason: it has extremely robust capabilities, performing over 50 tests to determine the validity of an email address.

Part of the power of Email Validation lies in its depth of features. It has the power to correct common typos in domain addresses or syntax, detect fraudulent addresses and flag known spammers, among many other tests. But for most users, the most important thing it does is take the results of its validation tests and give you a simple, quantitative score for how valid your email address is.

Score	Description
0	Email is Good
1	Email is Probably Good
2	Unknown
3	Email is Probably Bad
4	Email is Bad

But what do these scores mean? Read on, and we’ll break it down for you.

How to interpret your Email Validation scores

The Email Validation service returns a score that ranges from 0 to 4, representing how likely it is that an email address is valid. Lower numbers are better: a score of 0 indicates a good email address, and a score of 4 indicates a bad one. Simple enough, but what if the score we return is in between these two numbers? Since we run over 50 validation tests, there are a variety of reasons why a particular score is chosen, so let’s look at what these numbers really mean.

Score 0 – Email is good

We give a score of 0 to an email address that we have a lot of confidence in. This generally means that its SMTP server was good and that our service was successfully able to communicate with it. This score also means that we did not find the email address to contain any vulgar, garbage or bogus arrangement of characters.

In some cases where we return a zero score, we can even determine if the mailbox of an address is valid: for example, in the case of the address example@serviceobjects.com, this would mean that the “example” part of the email address was valid with the SMTP server. The validity of the mailbox can be viewed in the IsSMTPMailBoxGood response from the service as well.

Score 1 – Email is probably good

We give a score of 1 to email addresses that appear to be mostly good but may have some extenuating reasons for why we are hesitant to call it completely good. For example, email domains that are considered to implement greylisting techniques often receive a score of 1: this doesn’t necessarily call into the question the validity of the email address, but rather indicates that one may encounter greylisting behavior when trying to interact with this address.

(Greylisting, by the way, is when an email domain temporarily rejects incoming emails from unfamiliar senders. The logic of greylisting is that regular email servers will queue and reattempt delivery of your message, while bulk spammers won’t. However, delivery of your email may be delayed anywhere from minutes to days.)

Generally speaking, scores of 1 and 3 are relatively rare. Most emails will be able to be classified into a score of 0, 2 or 4.  Scores of 1 and 3 are reserved for cases where we are hesitant to call an email completely good or completely bad.

Score 2 – Unknown

A score of 2, in essence, indicates that the service was not able to make a definitive decision about whether or not an email address was valid. One of the most common reasons for this is when the mailbox for the email address is a “catch all domain” like yahoo.com, which will essentially receive any email that is sent to any mailbox at that domain. Even if the specific mailbox does not exist, the domain will still receive the email message. Another reason that may cause a score of 2 is greylisting by a mailbox domain.

Score 3 – Email is probably bad

These scores are for email addresses that are most likely bad but don’t fail enough of our validation tests to incur a completely bad score. Like emails with a score of 1, these are generally rarer than the other scores. Results that may move an email from a score of 2 to a score of 3 include getting a flag indicating that the email string contained bogus, vulgar or garbage characters. Email addresses with a score of 3 still may be deliverable, however.

Score 4 – Email is bad

If an email returns a score of 4, this means that it failed one of our more serious validation tests. For example, this email address may have had an invalid DNS, an invalid domain syntax, or the mail box simply does not exist.  If an email address fails one of these important tests our service will forgo all of the subsequent tests and return a score of 4.

How to use your scores

Generally, we recommend that clients consider emails with a score of 0 to 2 as “good” emails. However, you may want to use the additional results that Email Validation returns along with your own use case to determine the best emails to target. For example, if you want to be more conservative with your email campaigns then only sending emails to score 0 and 1 addresses may be the appropriate way to proceed. Conversely, if you would like to reach the broadest crowd possible, allowing emails with scores of 0 to 3 may be beneficial for your use case.

In a very real sense, DOTS Email Validation 3 serves as a consultant for your outbound email efforts: it provides you with data, but lets you make the final decision about who to send to. Understanding the scores we provide helps you use this data effectively – and in the process, get the most value out of your email contact assets.

I have a superpower that most people don’t have. In my position here at Service Objects, I have had the privilege of being a fly on the wall with many companies while helping them create clean and validated data. So I know, perhaps better than most people, what businesses go through as they wrestle with how to improve their data quality and ROI.

In this article, I would like to take you inside the mind of a typical business as they look at their data challenges, and what happens when they decide to work with us. You probably know what *we* think about our products, of course – but the only opinions that really matter are those of our customers. So let’s look at a hypothetical case study of a typical business, based on my many actual interactions with prospects and clients.

Discovering your data quality issues

I was a new hire at my company when it all started. We were a large manufacturing firm serving the business-to-business market, and things were ramping up. We had a website where people could make orders and sign up for a catalog, as well as opt-in for email alerts when special items would go on sale or we had an email campaign.

My job was ensuring that the data we were collecting was accurate and up-to-date. And I found that this data was a mess! For one thing, we had lots of inconsistencies in our contact data. Sometimes street suffixes and street prefixes were abbreviated, and sometimes they weren’t. Sometimes they were in all upper case, or all lower case, or sometimes mixed case. The same things were also true for the state field. One of the complaints from management was that the shipping labels on our catalogs looked very bad.

More importantly – particularly from a financial standpoint – the team was getting frustrated with the amount of “return to sender” items we were receiving. This gave us a few problems to solve. First, I knew that our data input forms would need to be updated, but I also quickly realized that somehow forcing our users to always provide good consistent data was a pipe dream. Standardizing the data alone wouldn’t fix the problem of returned catalogs, so I knew that this really came down to getting our existing data standardized and validated, as well as making sure new addresses coming into the system were also high quality and valid. Address validation was the key to solving this.

Finding an address validation solution

Now a decision needed to be made: do we get our software engineers involved and build it ourselves, or do we get something off the shelf? I had faced this dilemma before in previous positions. For small tasks, building solutions from scratch is OK and can save money in the long run. But I have found that when trying to implement solutions for larger projects, finding products off the shelf can have a much greater impact.

You see, the problem really wasn’t that we couldn’t update our forms to help standardize the inputs. It was a small job to switch data entry fields from open text fields to dropdown selectable options. The tough part was the address validation component. We were experts with our products, but it really didn’t make sense to try to be experts with address validation. Address validation is no simple task, and I knew the right solution would be finding a company that had a lot of experience with it.

Naturally, like everyone else, I did a Google search for “Address Validation”. I was looking for three main things for our solution. First, they had to be experts. Second, they had to have integration options, because I knew I wanted a solution that integrated with the forms we had on the website. I also didn’t want to have to build out a process to clean the existing addresses: I wanted to simply send the data over in a file have it cleansed and returned to me to repopulate our database. And third, I wanted service. I wanted a company that was available to talk when I needed to talk, and would respond quickly to my email questions.

It turned out that Service Objects had all of this and more. I had access to experts with solutions to my problems – not just people selling solutions, but also the people building and integrating these solutions. And it turned out that our team didn’t really need much help integrating the Service Objects’ Address Validation solution into our website. The documentation and sample code were clear, and with just a free trial key we were able to get up and running. Then all we needed to do was switch to a live production key, and we were done! I really like it when things are that easy.

When it came to validating the existing addresses, we wanted a solution where we could upload our data and get it cleansed and returned to us, as I mentioned earlier. After talking it through with a Service Objects representative I realized that we just didn’t have one data set to cleanse. In addition to our direct data set needing to be validated, we would also be importing address data from other divisions of the company on a periodic basis.

Here it would be nice to set up a process where we could regularly deliver a file and have it processed. After talking it over some more, Service Objects told us that they did do one-time processing, But also offered an automated batch service where we could upload a file that would get processed and returned to us automatically. This was exactly what we needed.

Moving on to email validation

So we integrated address validation into our system and got the automated batch process going, and everything was running like a well-oiled machine. Address data was coming into the system as clean as it could be, and the issue with returned catalogs disappeared. Next, I wanted to tackle the issue we were having with our email alerts that visitors could sign up for.

It was being reported that we were getting a lot of bounces on the email offers we were sending. When I examined the email data, some of the reasons were obvious. I was finding things like emails that appeared to have been entered by the user mashing a bunch of random keys on their keyboard. But the problem was larger than that – we were also getting bounces from emails that appeared legitimate.

I recalled from my conversations with Service Objects that they were experts in several types of data validation. Besides address validation, for which they had Canada and international products as well, they also had phone validation services, geocoding services, lead and ecommerce services, demographics services and more. But most importantly, for my purposes, Service Objects had a solution for real-time email validation.

The solution I was looking for would be one where we could validate an email at the point of entry into our system, and also one where we could send automated batches to get validated before we do an email campaign. The automated batches would also help us with the multiple email lists that we purchased or rented. The Service Objects’ Email Validation service was perfect for this and was just as easy to integrate as the address validation service was.

Lessons learned

This case study tried to identify a few phases companies go through when they try to validate their data. They involve identifying what the problems are, and sometimes these problems are not always obvious. Moreover, validating your data once does not mean that you are done. For starters, email addresses change and people move. Also, if your records are of people in the European Union then personal data needs to be as accurate and current as possible, particularly in light of their new GDPR regulations.

Stale or incorrect data is your enemy, and we have the services you need to keep it valid. After identifying the problem, most companies look next at how and who should solve the problem. As I mentioned in the case study, there are reasons to build out solutions in-house, but when you get into the realm of data validation it is really best left to the experts.

There are additional benefits to buying off the shelf with us besides our capabilities and expert support. You also benefit by always having the latest and greatest versions of our products. When we update our services, these updates are often injected into the operations you are already using and can provide for faster response times as well. Also, nearly every customer goes through a discovery phase where they are learning about a service and all the different data points that it can return. There are a lot of terms involved, and unless you are an expert some of them can be confusing. In cases like these, our assistance can make a big difference.

We’re here to help

Above all, we are there with our customers every step of the way. And there are often times when some expert advice can help you get more out of our services.
For example:

• For email validation, you may want to know what greylisting is or what catchall means, and how knowing these data points can help you.
• For address validation, it may be very helpful to know when an address is classified as residential, so you can better define shipping costs.
• You may not be aware of how some of our capabilities could directly profit your specific operations, such as demographic analysis or lead validation.

We are always here to help you understand our capabilities, as well as helping you through the integration process. Integration is usually the last main phase in the process. We do find that most organizations have few real issues when it comes to integration, but there are unique cases that we work through together. We have lots of documentation and sample code to help with integration, and you can count on us as a resource for help.

This hypothetical case study has a lot in common with our real-life experience with customers: they come to us with data quality issues that are costing them money, hurting their productivity or damaging their brand image. And then we collaboratively help them find solutions to these problems and make it look easy. We would love to help you too!

Contact us any time for a no-obligation discussion on what we can do for you.

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.

Score	Description
0	Email is Good
1	Email is Probably Good
2	Unknown
3	Email is Probably Bad
4	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.

Warning codes

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.

Code	Warning Name	Description
0	UnrecognizedTLD	Indicates if the top-level-domain is not recognized by ICANN.
1	InvalidSyntax	Indicates if the email is syntactically invalid.
2	InvalidDomainSpecificSyntax	Indicates if email is syntactically invalid for the given domain.
3	InvalidDNS	Indicates if the domain is unregistered or it does not have at least one MX or A record configured to relay email.
4	NoMXRecords	Indicates that the registered DNS does not have an MX record.
5	Established	Indicates that the email address is known to be in bulk marketing lists.
6	Alias	Indicates if the email address is believed to be an alias address.
7	Bogus	Indicates if the email address is believed to be a bogus email. For example, asdf@asdf.com.
8	BogusSMSAddress	Indicates if the email address is believed to be a bogus SMS domain address.
9	Garbage	Indicates if the email address is believed to contain garbage-like keyboard strokes and/or garbage-like characters.
10	Vulgar	Indicates if vulgar words or content are found in the email address.
11	MailBoxIsFull	Indicates if the mailbox is currently full and unable to receive any new messages.
12	MailboxIsBusy	Indicates if the mailbox is reported by the hosting mail server as being busy and unable to currently accept new messages.
13	DisposableEmail	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.
14	SpamTrap	Indicates if the mailbox is believed to be a spam trap.
15	KnownSpammer	Indicates if the email address is known to have participated in spam-like activities.
16	BlacklistedDomain	Indicates if the domain was found to be in one or more blacklists.
17	KnownComplainer	Indicates if the email address has been identified as a known complainer of receiving unsolicited mail.
18	KnownGreylister	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.
19	OptInRequired	Indicates if the mail server requires opting-in to send and receive messages.
20	IsWhiteListOnly	Indicates if the mail server only relays messages for users that are whitelisted.
21	ConnectionRefused	Indicates if the mail server refuses to accept an SMTP connection.
22	Email is Bad - Subsequent checks halted.	Indicates that the email address failed a critical check, such as SMTP verification.
23	Bot	Indicates that the email address has been reported as being a known bot.

Note codes

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 example@serviceobjects.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.

Code	Note	Description
0	CCTLD	Indicates if the top-level-domain (tld) represents a specific country. For example ".us" implies United States.
1	Free	Indicates if the domain of the email is a public-register domain, where users can sign up for email accounts for free.
2	SMSDomain	Indicates if the domain is a known Mail-to-SMS Gateway.
3	Role	Indicates if the email address appears to be a role that is designed to be anonymously managed by one or more persons.
4	BusinessAddress	Indicates if the email address appears to be work related.
5	GreyListed	Indicates if the mail server responded with a known greylist tactic.
6	MailServerTemporarilyUnavailable	Indicates that the mail server may be temporarily unavailable or too busy to respond.
7	ServerConnectTimeout	Indicates that a connection to the recipient mail server could not be established.
8	MailBoxTimeout	Indicates that the connection to the mail server timed out when trying to verify the email address.
9	TemporaryReject	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.
10	SlowMailServer	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.
11	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
12	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
13	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
14	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.