In a previous blog, we discussed the benefits of using DOTS Address Detective – International to detect a contact’s country. This blog will discuss some of the challenges surrounding country detection in more detail, as well as provide an overview on how we determine the best country from your data.

Contact Components

When trying to append a country to a contact, we have four main components to examine.

1. Address
2. Phone
3. IP Address
4. Email

Each component must be carefully evaluated on its own merit before it can be used to help identify a country for the contact.

Address Component

The Address component may represent a contact’s physical location or mailable address. It is the most diverse and complex of all the components. International addresses do not follow a singular format, language or standard. Each country has its own set of rules and standards, which can also make the storage of international addresses problematic for US-centric CRMs.

This also means that is common for a contact’s address to be incorrect and/or incomplete. Additionally, some businesses are not always interested in capturing a mailable address and only wish to store a contact’s region. Depending on who is entering the contact address and how it is being stored, it would not be unreasonable to expect this data to be flawed in more ways than one.

Knowing the country is critical to processing most addresses. It determines the address format, which is needed to identify individual address elements, which in turn are needed to identify a locality, postal code or region. With that said, our sophisticated data-driven algorithms are not dependent on completeness and allow for a wide variety of formats and languages.

If you think you can identify a country’s address, take our fun, short Country Quiz.

Similar to the DOTS Address Validation International service, the address component consists of Address Lines 1-8, Locality, Admin Area and Postal Code. The address can be entered entirely in lines 1-8 or in combination with the Locality, Admin Area and Postal Code fields. Address line order does not matter, and common mistakes like putting an address value into the wrong address field are detected and handled.

Not all countries follow the US city-state pairing format or the equivalent locality admin area pairing. Many international addresses do not include an admin area, which can make country detection difficult since many localities from around the world can often share names. Take Venice, for example, which can be found in separate locations of three different countries.

Locality	Admin Area	Country
Venice	Venice	Italy
Venice	Alberta	Canada
Venice	California	USA
Venice	Florida	USA

If no other address information besides the name Venice was made available, one would be left having to choose between these three countries. However, by making use of other contact data such as a phone number, IP address and/or email, the service can cross reference various datasets to better determine which country is the best match. Then again, if the locality was entered as Venezia, the Italian endonym for Venice, there would be less ambiguity and the country Italy would be the clear choice.

Phone Component

The phone component consists of a contact’s phone number(s). The format of a phone number is dictated by its country’s numbering plan. Some countries have their own numbering plan, while others share one. The USA and Canada, for example, share the North American Numbering Plan (NANP), whereas the UK and its crown dependencies share the UK National Telephone Numbering Plan. Most countries conform to the E.164 International Telecommunication Numbering Plan, which is published by the International Telecommunication Union (ITU).

The E.164 Numbering Plan
The E.164 currently provides five number structures (numbering plans) for international phone numbers:

1. International ITU-T E.164-number for geographic areas.
2. International ITU-T E.164-number for global services.
3. International ITU-T E.164-number for Networks.
4. International ITU-T E.164-number for groups of countries.
5. International ITU-T E.164-number for trials.

Each structure has its own set of rules and requirements, but telephone numbers that conform to E.164, in general, will adhere to the following:

• The recommended maximum length for a telephone number is 15 digits.
• Telephone numbers will begin with a Country Code (CC).
• Telephone numbers will not include Prefixes and Suffixes

Country Codes
Country calling codes are published by the Telecommunication Standardization Bureau (TSB). Depending on which E.164 structure is being used the country code (CC) may vary between 1 to 3 digits or may be fixed to 3 digits. Country codes are followed by the destination number in accordance with the E.164 numbering plan. When storing a country code or an international (E.164) number, the number is commonly prefixed with a plus symbol (+) to indicate that when dialing the number, one must first dial the appropriate international call prefix to complete the call.

Prefixes
International call prefixes (also known as call out codes, dial out codes, exit codes or international access codes) are used to make a call from one country to another. The Prefix is dialed before the country code (CC) and the destination telephone number. Prefixes are not a part of the E.164 numbering plan and it is recommended to not include them as they can interfere with country code identification.

Making the Call
Suppose you have a contact in the UK with the following number saved in your CRM, ‘+44 123 456 7890 Ext. 123’, and you wanted to call this person from within the USA. To call them, you would dial 011441234567890, and then after you have been successfully connected you would next dial your contact’s extension of 123.

The table below shows how the prefix and suffix are not a part of an international number.

Prefix	International Number		Suffix
	Country Code	Destination Number
011	44	1234567890	Ext. 123

Now suppose that you wanted to call this contact again, but this time you are in Sweden and not in the USA. Instead of dialing the 011 prefix, which is shared by all countries in the North American Numbering Plan (NANP), you would dial 00 which is the prefix used by many countries in Europe.

At Service Objects, we understand that not all phone numbers will conform to an E.164 numbering plan and that many numbers will have missing country codes, which why our services make use of a wide variety of datasets and are flexible enough to intelligently identify a country.

IP Address Component

Not all companies capture a contact’s IP address, but when they do they are most likely capturing it via the web form the contact used to submit their information. The captured IP address and the location for that IP is often for the registered owner of the IP, so if the contact filled out a web form from their home computer then it is likely that the IP is for their Internet Service Provider (ISP). If they filled it out from their office computer, then the IP address may belong to the business or to the business’s ISP. IP based geolocation systems will commonly return a general location for the owner of the IP, which in most cases is the end user’s ISP.

There is often a misconception that IP based geolocation services will always return an end user’s exact location. For example, that the IP address assigned to a mobile smartphone can alone be used to pinpoint and track the phone’s exact location. This is simply not true. In most cases, IP based geolocation services will return the city and/or the metropolitan area for where the IP address is commonly served. Subscribers will generally be located within the serviceable area of their ISP, and so the IP based location can be used in confidence to identify the region of the end user.

Identifying Anonymous Users
If a contact used a Virtual Private Network (VPN) or Proxy connection, such as a Tor network, when filling out a form then that means that the end user’s true IP address was masked and it was not captured. Some users will make use of methods such as these to try and remain anonymous and prevent others from capturing their true IP address. These methods are not only used to mask a user’s true location, but they can also be used to make a user appear to be from somewhere they are not. This is commonly done to circumvent region locked sites and services, however not all VPN and proxy connections are used for this purpose. Many businesses make use of VPN and proxy connections to connect their employees, sites and services from various regions, including remote employees.

A service like DOTS IP Address Validation is capable of identifying proxy related IP addresses as well as IP addresses associated with malicious activity. By leveraging this data, the country detection algorithm can determine if the IP is trustworthy and if the IP based location is genuine.

Email Component

The email address component uses the contact email address to identify where in the world the mail servers are located. The location of the mail server should not be confused with the location of the mail sender; after all, one of the benefits of email is that you can send and receive it from just about anywhere an internet connection is available. This means that a contact may not necessarily be anywhere near where the mail server is located and could potentially reside in an entirely different country. It’s also worth noting that the domain name, including the Top Level Domain (TLD), can be misleading.

For example, let’s suppose we have an email with a domain that consists of Spanish words and the TLD country code for Spain (ES), like: ejemplo@una_palabra_espanola.es

While the above example email address may appear to be for a contact for Spain, the company could instead be hosted or even located in another country, such as the USA. Another possibility is that the company is located in one country and has their email handled by a provider in another. It is quite common for businesses to outsource email duties to specialized email providers.

Some domains have mail servers located in multiple countries and regions and are not tied to a single location. So, email addresses alone cannot be used to accurately and confidently identify a contact’s country, as doing so would be too far-reaching. However, the country or countries for the email component can be used in some cases to help identify a single country when used in combination with other contact data.

Which Country is Best

As you can see, each contact component is carefully analyzed to the point where a country may be singled out for each one, but the next step is to now determine which country best represents the overall contact. By taking the countries that are related for each component and carefully weighing their relevance as well as cross-examining them we can in many cases successfully identify the single best country that best exemplifies the contact.

As previously mentioned, contact components like the Address and Email can result in more than one country. The country detection algorithm takes all possible countries into account, so even though a single component may not have a clear country winner, a best match can be found between all the components. Some components have a stronger influence than others. For example, the IP address and email address components do not have as much influence as the address and phone components since they are not always directly related to where a contact resides.

In general, the more complete the contact information is, the more the country detection algorithm will have to work with, choosing a best overall country. However, even when a few contact components are available, the service will still be able to make do with the information it receives.

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, like 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 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.

“Nobody is perfect. And my company wasn’t even talking about things like data quality ten years ago. So, what is the big deal if there are a few problems with my contact data? That’s life, isn’t it?”

Actually, it is a big deal. First, it affects your costs and competitiveness. Second, it affects your reputation in the marketplace. And finally, because bad data can be so easily fixed with the latest automated tools.

With new regulations on the horizon and an increasingly competitive marketplace, companies need data they can rely on. If you’re still on the fence, below are some of the main reasons your business needs confirmed data.

Saving Time and Money

Bad data always costs your business time, money, or both. It affects areas such as sales leads, delivery accuracy, your reputation when sending email marketing, and much more. It is estimated15-25% of contact data is inaccurate, incomplete, fraudulent, or out-of-date, and a great deal of resources are wasted due to inaccurate or straight-up bad data.

Getting sales leads is costly for most organizations, especially when leads are bad or inaccurate. The earlier you can validate incoming data, the better you will be able to utilize your resources.  Our Email and Address Validation services can help make sure your incoming contact data is coming in clean and valid, and our Lead Validation service helps prioritize your resources toward better targeted leads.

Improving Your Marketing Efficiency

Think of all the wasted resources involved when materials are sent to the wrong address, or salespeople chase after bad or mislocated prospects. Even a small percentage of errors can result in a great deal of frustration for everyone involved, and fixing these problems is low-hanging fruit you can easily automate.

Beyond our Address Validation services, our Address Geocode product can translate addresses to exact latitude-longitude coordinates in real time. For incomplete addresses, our Address Detective product can prevent you from purging good leads. It fixes fatal addressing errors by filling in the gaps of missing address data in your contact records, using a fuzzy-matching API that returns a confidence score for each updated address.

Protecting Your Email Reputation

Suppose you bought an email list and you are ready to send the perfect email, after weeks of refining. Nothing can give you a bad reputation quicker than sending email to a bunch of addresses that bounce, not to mention getting mediocre results from your campaign.

Use our Email Validation service to keep your reputation in good standing. Using a real-time API can reduce bounce rates up to 90%. Our service can process rented lists as well as your own house lists, giving you valuable insight into your contact data assets to make sure you get the most out of your investment.

Cleaning Up Your Existing Contact Data

We often hear people say, “What if I just realized we were doing things wrong and I want to get our data on the right track?” Once your database gets corrupted with uncertain data, typically two things must happen to reverse course. First, you need to draw a line in the sand and commit to making sure to validate any new information going into your system. The next step involves validating all your current database information in a separate process.

We can help automate much of the extra work of cleaning up existing data. We have lots of sample code and support many platforms to make it easy to integrate with us, not to mention the top-notch technical service team we have standing by to help you implement a robust solution.

Lather, Rinse, Repeat

Finally, we wanted to mention the importance of keeping your data current. Even after validating data coming into your system using our API or cleansing your system afterward with our batch process, data will still get old and invalid over time. People move, new homes are built, old buildings are repurposed, emails change, phone numbers are disconnected, and so on.  Like showering, regular data hygiene will help keep your data in the best condition possible, and we make this easy for you.

There are many benefits to keeping your data as up-to-date and accurate as possible, and we are here to help you every step of the way. Contact us to see what we can do for you and your data!

 

With 2.1 billion active users, Facebook presents an exceptional opportunity for targeted marketing and businesses interested in harnessing the power of consumer data. In fact, there are now entire industries devoted to collecting and selling personally identifiable information. Unfortunately, the swift expansion of social media, with its tantalizing trove of consumer information, has left lawmakers playing catch up. However, that’s about to change, thanks, in part, to the scandal surrounding Facebook and Cambridge Analytica and its intersection with the General Data Protection Regulation (GDPR), an EU law governing data protection and privacy for all individuals within the European Union.

The GDPR Effect 

Though the GDPR will not take effect until May 25, 2018, if the breach of 50 million user account had happened while the law was in place, it would have resulted in a costly error for Facebook. As Austrian privacy campaigner and Facebook critic Max Schrems was quick to point out, had the unauthorized the sharing of profile data to Cambridge Analytica occurred while the GDPR was in effect, it “would have cost Facebook 4 percent of their global revenue”, somewhere in the ballpark of $1.6bn (€1.3bn).

But even before the Cambridge-Analytica story grabbed headlines, GDPR implementation was set to trigger significant changes to Facebook’s business operations. According to Reuters, Facebook faces a double-edged challenge: comply with the new GDPR rules and allow European users to opt out of targeted advertising, or violate the GDPR and face fines of up to 4% of the company’s annual revenue.  Considering 24% of Facebook’s ad revenue comes from EU users, either course of action represents a significant hit to profits for the company. And with global adoption of GDPR-type privacy protocols beginning to take hole around the world, Facebook and its social media cohorts will need to adapt to the changing consumer data landscape. 

A Global Movement

Though the EU primarily applies directly to data from EU citizens, it also controls the flow of personal data from within the EU to countries outside its borders. With US and UK legislation probable, this new era of data security means enormous changes in the way companies do business. As a result, international adoption of the GDPR’s privacy protocols is already taking hold around the world as counties begin to change their own data privacy rules. 

How Businesses Can Prepare

So how can business owners make sure they do not follow in Facebook’s footsteps? Companies entrusted with customer data must first acknowledge their responsibility in keeping that information secure. It is not enough to create a security protocol; organizations must also enforce and audit those policies. Robust and comprehensive quality analysis is also crucial, especially in light of the GDPR Article 5 mandate requiring the personal information of individuals within the European Union (EU) be current and accurate. Finally, the use of contact data, especially when it comes to combining information from different sources, should also be monitored. It is not enough to know your information is accurate; you must also make sure you are using it in the manner it was intended to be used, both legally and ethically.

The Benefits of Data Quality Best Practices

Though many businesses are still unprepared for the GDPR’s May 2018 deadline, it seems clear this latest scandal involving Facebook and Cambridge Analytica will spur many businesses into action.

The good news is implementing data quality best practices to comply with Article 5 makes good business sense. It will save organizations considerable money in the form of streamlined marketing and sales campaigns, improve overall customer service and reduce the waste associated with bad contact data.

Service Objects can help you get a better understanding of the role your customer data plays in becoming GDPR compliant. Send us up to 500 records (it is a 100% secure process) and we will provide you with an overall score of the quality of each record based on fields such as name, phone, address, email, IP, and country. Get started today.

Welcome to our third installment in our Salesforce Data Quality Tools Integration Series. In the first two parts, we covered creating a plug-in that could be dropped on a flow and a trigger. Today, we are going to jump into creating a VisualForce app that you’ll be able to extend for your purposes. At the end, you will have all the code you’ll need to get started, so don’t worry about implementing this step by step as I have it laid out in this blog.

The goal of this app is to display to a table of contacts that can be selected to have their emails validated. We will add a filter to the table to better target certain emails for validation. We will also display a few charts that will provide a good overview of the state of the emails in their system. These charts will refresh according to the filter selected for the table of contacts.

As always, we are going to start with some basic setup, then switching to look at what the final VisualForce page is going to look like, after that we’ll run through the code. During this walk-through, it should be clear where there are opportunities for customizing this solution.

The very first thing you need to start with is setting up the Service Objects endpoint. I am not going to go over it this time because I go over it in the first and second parts of this series. So, if you need help setting up your endpoint or a description of what this is, please check out the previous blogs. If you have been following along from the first two blogs, then you have already completed this part. Once you have set up your endpoint, you will need to add the following custom fields to the Contact object. If you are customizing this for your own purposes, you will want to add these fields to the object you are working with. If you want to map more of the fields that our service returns, you’ll have to create the appropriate fields on the object, if there isn’t an existing field already at your disposal.

• Field name
  • Internal Salesforce name
  • Type
  • Service Objects field name

• Email Catch All
  • EmailCatchAll__c
  • Text(20)
  • IsCatchAllDomain

• Email Score
  • Email_Score__c
  • Number(2,0)
  • Score

• Email Score Name
  • EmailScoreName__c
  • Text(20)
  • DPVNotesDesc

• Email Top Level Domain
  • EmailTopLevelDomain__c
  • Text(50)
  • TopLevelDomainDescription

Here is a view of the table with the filter and the Validate button.

Next is a screen shot of a couple of the charts.

As you can see, it is a pretty simple example that can be tailored to whatever custom solution you are looking for.

For this walk-through, we will be creating three files: one for the markup, one for the controller and one for the web service call.

MARKUP

Starting with the markup page, the actual VisualForce page, we will create a file called EmailValidation.vfp. For the first element, the Apex:page element, we define which controller we want to have associated to the page. We will make a custom controller for this app, “ContactEmailValidationController”, which is the name of the class that we will build later in the controller section. After we establish the controller that we are going to use, we override some styles so that we get the headers in the charts to stand out properly.

Next, we create the page block that will house the components to the page inside a form. The four main components are the filter, the table of contacts, the validate button(s) and the charts. You will more than likely want to implement a paging system for the table, so you can page through your contact records but I do not go into that here.

The filter section is basic:

Throughout the code you will see instances of values that come in the form of {! [Some variable name]}. That is simply a reference to a value in our custom controller. In the case of the filter, we have two of those instances, one for the filterId and one for Items. In this case, the filterId is telling the select dropdown list which item is selected. When the page first loads, nothing is selected, so the filterId is empty or null, which will render the default table view. You can certainly set this to have some other default value. The Items variable simply holds all the possible select options for the dropdown list. Items is populated in the controller, which we will take a look at later. Since we want the charts and the table to refresh when the filter is changed, we set the reRender attribute on the actionSupport element to target contacts_list. This is the id of the overarching page block section. Any markup outside of the contacts_list page block section will not be refreshed. The underlying code does an ajax call to refresh just a part of the page, which can be handy when you don’t want the whole page to reload.

In the next section of the markup, we setup the table of contacts and the columns that we will display back to the user. I have collapsed much of the code here so we can first focus on the apex:pageBlockTable element.

There are two things to notice in the page block table element. First, the contacts variable holds all the contacts coming back from the controller. Later, you will see a method on the controller that is called getContacts which is specifically named that way to sync up with this contacts variable. For example, if the variable was called people then the controller would need a method to retrieve those records called getPeople. The second thing to notice is the value cont for var. This value will be the container for each of the contacts in the contacts variable. The format and setup of the page block table element can be described such that it acts like your traditional for each loop. On a side note, there are many ways we could have created this table. For instance, we could have used a repeater or a couple of other elements to display the contacts to the user.

Next, we are going to look at the way we setup the columns and we’ll start with the checkbox column, since it is unique to the rest of them.

This column consists of an apex:facet and a checkbox input. The facet will implement its own checkbox input as well. We use the facet to customize the header of the column with a checkbox. Salesforce defines the facet as this “A placeholder for content that’s rendered in a specific part of the parent component, such as the header or footer of an <apex:dataTable>”. The checkbox in the header will act as the select all/select none functionality of the column. The checkboxes in the rows will be populated with a contact id so we can track which contacts were selected. The onclick functions in both input elements reference JavaScript functions that we will discuss in more detail shortly. Simply put, those functions will manage the storage of selected rows.

The columns I have highlighted with the red boxes are going to be your standard output columns and those outside of the red boxes will need the header label, for the respective columns, updated to be more readable.

Earlier we created the custom fields to house some of the values that will be coming back from the call to the email validation service. Creating custom fields can, at times, lead to having to create a more “technical” label for the field instead of “displayable”. One obvious reason is so new custom fields do not conflict with existing fields or any future fields. Keeping that in mind, we do not want to use the labels of a couple of our custom fields in the header, so we will update them using the facet like we did earlier for the checkbox header but this time without a checkbox.

In this simple example, we are updating the header text, but the values in the column will still be pulled from the cont.EmailTopLevelDomain__c variable. And that is really it for the columns, pretty straightforward. And easy to extend, with little effort you can alter this example to display any of the columns you want in the table, as long as you have access to them from the controller.

In the next section, we will focus on the pie charts. The sample code will have a chart for Email Scores, Catch All Domains and Top Level Domains. The code becomes redundant, so I will only demonstrate one of them here. With that said, you can add any chart you want that focuses on the particular situation you are solving for. The overarching chart container is a page block element that I titled “Email Details”. This will house the three charts.

Each pie chart is wrapped in a page block section with it’s own unique title. For the apex:chart element, we see the variable EmailScorePieData. That links up to the getEmailScorePieData method on the controller which pulls in a list of wedgeName and count combinations which we can see referenced in the apex:pieSeries element.

Next, we’ll jump into the JavaScript portion of the client code. The JavaScript code on the markup page was designed to handle the checkboxes and compiling a list of ids based on checked/unchecked boxes. I used the code from this source on the internet. My only contribution to the code was to update some of the variable names to match more of what was going on in it. As you can see there is a function for selecting/deselecting one or all checkboxes at a time.

I am not going to take a deep dive into this code, since reading through it should illustrate what is going on there. At this point, all you need to know is that it compiles a list of Contact ids into the ContactIdBuilder variable based on which boxes have been checked as I mentioned earlier.

I did skip over the last part of the markup because it would be easier to make the connection between the ContactIdBuilder variable and the following markup code.

This part of the code, when the Validate button is clicked, it takes the id list stored in ContactIdBuilder and assigns it to the returnString hidden input element. After the value is assigned, the ValidateCheckedEmails method on the controller is called. The returnString value associates to the returnString variable in the controller that we will see shortly. And that is it. That’s all for the user facing part of the code.

CONTROLLER

The controller code consists of two main parts. First, getting data from Salesforce and displaying it to the screen. And the second part is validating the selected rows from the user interface.

Based on the filter selected from the user interface, the getContacts method will return a list of contacts. The main thing that you need to do here is make sure you are pulling back all the fields that the user interface needs to work with, taking into account both the visible and hidden fields. For example, the contact id which is in the background on the checkbox columns.

The method, getItems, retrieves all the filter options for the dropdown list in the user interface. In this method, we put together a list of hardcoded options and then some dynamic options that will allow us to filter on each company in the list.

The three methods that get the data for the charts return a list of EmailData records which are simply key/value pairs. Key being the name of the pie wedge and value being the count or size of the wedge. You can use the pie methods here to copy or modify to suit your own purposes. The more stats you want to present to the user, the more fields you’ll need to retain from the call to our email validation web service. Some of the other fields you may be interested in adding here are, the warning notes, the notes descriptions and/or the SMTP flags (server and mailbox level). There are many other fields that our email validation service returns and you can look at them in more depth here.

The last part of the controller to go over is the call to the method that does the email validate request. The method ValidateCheckedEmails pulls all the contact ids from the returnString variable and sets them up for processing in the CallEV3ByIdList method of the EmailValidationUtil class.

WEB SERVICE CALL

The EmailValidationUtil.apxc is the last file left to discuss. This file does the actual request to the email validation web service. This is the part of the code that you can customize the most; from what you decide to process to what is returned by the service. It is also a good place for any additional logic you may want to implement.

This code should seem very familiar to you if you had read the previous parts of this blog series. It is setup in a very similar way. Just as with the other examples in this blog series, we demonstrate the best practices when it comes to implementing failover. The inputs to the service are the EmailAddress, AllowCorrections, Timeout and Licensekey.

In our example, the email address comes from the contact records selected in the user interface and the rest of the inputs are hardcoded (but they don’t have to be). AllowCorrections accepts true or false. The service will attempt to correct an email address if set to true. Otherwise, the email address will be left unaltered if set to false. Here, I hardcoded it to true but you may want it to be false or use some other business logic to make that determination. The Timeout value specifies how long the service is allowed to wait for all real-time network level checks to finish. Real-time checks consist primarily of DNS and SMTP level verification. Timeout time is in milliseconds. A minimum value of 200ms is required. I have hardcoded it to 2000ms. For the LicenseKey, you will want to either hardcode this into the call (depending on the access that people have to the code) or create a custom object and/or a custom field with the license key that you can lock down with user permission only available to the administrator.

Before I wrap this up I wanted to make mention of writing tests to cover the code. This example is complete but expects you to customize parts of it, so I have not provided any test code. You will want to do that. It will ensure that even as Salesforce updates their system or you make changes to your organization, everything will continue to work as expected.

In conclusion, VisualForce pages are mostly used with the old Salesforce UI the Classic UI, but it can be created in a way so that it will continue to work with the new Lightning experience. In a future blog, I will show a demonstration of how to create a Lightning App while incorporating our validation services. Service Objects has validation services for all kinds of solutions, making Salesforce a perfect platform to demonstrate our services on.

We love data here at Service Objects. We are constantly working to expand and improve on our datasets to further innovate our product lineup. A big part of what makes our Email Validation (EV) service so good is the data that helps drive it. When communicating with a mail server in real-time to verify an email address it helps to know what kind of mail server it is dealing with and if it is trustworthy. Just because an email address is deliverable does not always mean that it is good.  For example, an email may be disposable, vulgar or worse yet, a spamtrap.

Our Email Validation service already keeps track of mail server behavior patterns for millions of domains, which allows us to identify and flag mail servers with malicious activity or servers that have a high association with malicious activity.  In addition to monitoring behavior patterns, we are now focusing on determining the geographic location of the email servers.

What benefits does identifying mail server location offer?

Email addresses can be sent and received from anywhere in the world. They are not anchored to one physical location, and at a glance, one cannot easily discern its geographic origin. Even email addresses with a country code for a Top Level Domain (TLD) can have a global presence and may have servers located in multiple countries.  Fortunately, mail server location data can be derived and aggregated from some of our other datasets. This allows our Email Validation service to better identify potentially malicious mail servers and flag servers from known geographic hot spots.

In addition to helping identify problematic email servers, mail server location data can provide additional insights and benefits. From a marketing and administration perspective, the mail server location data can be used to help identify and organize email addresses for a particular region. The location information can also be used to gain business insights about a company and its location(s). At Service Objects, we are using the additional information to further enhance some of our other services, such as Lead Validation.

Challenges to identifying mail server location information

There are a number of challenges to accurately identifying mail server location information. First, we are identifying the mail server locations of a domain, not attempting to identify where an email message was sent from. This would require more than just a simple email address. However, the location data can be used to help cross-check and verify the legitimacy of an email message. For example, an email message is received, and the headers say that the message was sent from Gmail.com. However, the server IP address in the header does not match any of the known Gmail mail server locations, so chances are the message was spoofed and that it is spam or part of a phishing scam.

Second, trying to identify all of the mail servers for a particular domain is not something that can be done quickly enough for a real-time service where end-users expect sub-second response times. Real-time communication with a mail server can often take several seconds, but trying to identify all the mail servers for a domain from around the world can sometimes take several minutes. For this reason, our DOTS Email Validation service does not include mail server location identification in its suite of real-time checks. Instead, the service relies on background systems that have already collected and identified mail server locations from around the world. This ensures that the service is not bogged down by slow processes and continues to respond normally. While mail server location identification may be too slow for a real-time check, it is a daily process that we perform to ensure our list of locations is up to date. The process is also quick enough that our background processes can routinely check for any new domains that we have not come across before and process them hourly.

Third, if a business has multiple locations, then a typical DNS lookup for a domain will just tell you which mail server(s) to connect to that are closest to your area, and not necessarily tell you about their other mail servers. DNS does this to help ensure that communication is quick and efficient, that way an end-user isn’t trying to communicate with a server on the other side of the country or potentially in a different nation entirely if it doesn’t have to. Part of what makes the location identification process “slow” is that we are looking for mail servers in every major region of the world, and not just in our own local areas.

What’s going on behind the scenes

While our email validation service will currently only display the location(s) of the mail server(s) in the notes of the output when it has been identified, it is doing a lot more with that data behind the scenes. Knowing the IP Addresses and locations of the mail servers means that we can perform cross-checks against more data points in other areas. Service Objects is extremely interested in fraud prevention, so we use this data to check for associations with known proxies, VPNs, bot services and other data points that have ties to malicious activity. The data allows us to check various data driven blacklists and white hat resources against more than a simple email address and domain.  Instead, we can pull back the curtain, so to speak, and dig deeper into the mail server(s) that run behind the scenes. All, while continuing and expanding our server behavior monitorization.

With the addition of this new data, we have added additional NoteCodes to the output from our DOTS Email Validation 3 service. Below is a list of the new notes codes and that have been added:

Code	Description	Example
11	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.	JP
12	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.	OS|TY
13	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.	Osaka|Tokyo
14	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.	543-0062|102-0082

 

For more information about terms for international addresses and locations please check out this previous blog post.

Unlike other NotesCodes where the corresponding NotesDescriptions value will be a human readable flag to describe the note code, the value will instead contain the list of locations found.

Get started testing DOTS Email Validation by downloading a real-time API trial key or sending is a sample list to run for you.

Do you have any friends named “info” or “customerservice”?

If you do, our sympathies, because their parents were probably way over-invested in their careers. But in all likelihood, you probably don’t. Which leads to a very important principle about your email marketing: you always need to make sure you are marketing to real people.

Email addresses like “info@mycompany.com” or “customerservice@bigorganization.com” are examples of what we call role addresses. They are not addressed to a person, but rather to a job function and generally include a number of people on the distribution list. They serve a valuable purpose, particularly in larger organizations – if you have a problem with Amazon.com, for example, you don’t want to wait for Cindy to get back from vacation first to respond to you.

You probably realize that role email addresses create the same problems as any other non-person in your marketing database: wasted human effort, lower response rates, bounces, and the like. However, there are several other important reasons to purge role addresses from your contact database:

Bounce Rate. Role emails are generally the responsibility of an email administrator.  These administrators are not always kept in the loop when individuals move onto other positions or leave the company.  This can result in a role email’s distribution list not being up-to-date and emails being sent to inactive email addresses.  These inactive addresses are usually set to automatically bounce emails, resulting in a higher bounce rate and poorer campaign performance.

Blacklisting. Spamming a role email address doesn’t just annoy people. As one article points out, it can trigger spam complaints and damage your sender reputation – in fact, role accounts are often used as spam traps by account holders. This can lead to your IP being blacklisted for the entire organization, cutting you off from leads or even existing customers far beyond the original email.

CAN-SPAM compliance. Permission to send email is fundamentally a contract with an individual, and marketing to a role email address risks having your materials go to people who did not opt-in or agree to your terms and conditions – putting you at risk for being in violation of the US CAN-SPAM act that governs email marketing.

New laws. In Europe, the new General Data Protection Regulation (GDPR) takes effect in 2018, severely restricting unsolicited email marketing. While it is not always clear that you are mailing to Europe (for example, many people do not realize that household names like Bayer and Unilever are based there), you are still bound by their laws and potentially stiff penalties. Eliminating role accounts from your contact database is an important part of mitigating this exposure.

Exponential risk. When it comes to risk, role addresses are the gift that keeps on giving. One of these addresses may go to 10 different people or more – and only one of them needs to complain to get you in trouble. Moreover, you can easily get multiple complaints for the price of one errant message.

Customer reputation. When someone signs up for your contact list using a role address, it is a form of “friendly fraud” that absolves them from personally receiving your emails – much like the person who signs up as “Donald Duck” to receive a free marketing goodie. But when other people start receiving your materials without their permission as a result, it is not a good way to start a customer relationship.

Thankfully, avoiding role-based addresses is relatively easy. In fact, many large email marketing providers won’t import these address in the first place. Or if you manage your contact database from within your own applications environment, we can help. Our email validation capabilities flag role-based addresses in your database like sales, admin, support, webmaster, billing, and much more. In addition, we perform over 50 verification tests, clean up common spelling and syntax errors, and return a quantitative quality score that helps you accept or reject addresses at the point of import.

So, with pun fully intended, your role in data quality is to ensure that your online marketing only goes to live, real people who welcome your message. Our role is to automate this process to make it as frictionless as possible. Together, we can keep your email contact data ready to roll!