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!

The DOTS Email Validation 3 (EV3) service has been designed to be robust enough to accommodate the particular needs of a detailed oriented programmer and simple enough to be used by a marketing assistant who needs to run an email campaign. The service can meet various needs that can essentially be narrowed down to two use cases, form validation and post-processing jobs such as batches and database hygiene. Before we discuss those two cases we will first go over the recommended service operation and review some of the important result fields.

Which Operation Should I Use?

The recommended service operation for EV3 is the ValidateEmailAddress method. This operation performs real-time server-to-server email verification. It lets the user specify a timeout value, in milliseconds, for how long it can take to perform real-time server checks. A minimum value of 200 milliseconds is required; however, results are dependent on the network speed of an email’s host, which may require several seconds to verify. Average mail server response times are approximately between 2-3 seconds, but some slower mail servers may take 15 seconds or more to verify.

Please note that the above information is also available in the service developer guide.

Understanding the Results

The service returns many results that can be used to meet a programmer’s particular email validation needs, but the easiest way to determine if an email should be accepted or rejected is by looking at either the IsDeliverable value or the Score value.

Score:

For most cases it is recommended to use the Score along with other output values to cater to your particular needs. Here are the possible score values.

Score	Description	Notes
0	Email is Good	Indicates with high confidence that the email address is deliverable and good. The email address was verified with the host mail server and no malicious warnings were found.
1	Email is Probably Good	Indicates that the email is deliverable but one or more lesser warnings were found. For example the email may be a potential alias or a role, which are sometimes used as disposable addresses.
2	Unknown	Indicates that not enough information was available to determine deliverability and integrity. Unknowns most commonly occur for slow mail servers that do not respond to the web service in time. They also occur for catch-all mail servers and greylists.
3	Email is Probably Bad	Indicates that one or more warnings were found, such as a potential vulgarity or a string of garbage-like characters.
4	Email is Bad	Indicates with high confidence that the email address is bad and/or undeliverable. Occurs for email addresses that fail critical checks such as syntax validation and DNS verification. Most commonly occurs for email addresses where the actual host mail server verified that the email does not exist. Also occurs for deliverable email addresses that are known spam traps or bots.

IsDeliverable:

The simplest way to use the service is to look at the IsDeliverable field. This field will return true, false or unknown. If your primary concern is to be able to send out email with the lowest possible chance of a hard bounceback then this field alone will suffice. However, this field does not take spamtraps, vulgarities, bots or other factors into consideration. It simply indicates if the service was able to verify the deliverability of an email address with the host mail server. It does not measure the overall integrity of the email address.

If you choose to only look at one result value then it is our recommendation that you use the Score value instead of the IsDeliverable value. The Score evaluates the overall integrity of the email address and not just its deliverability. Either one of these fields can be used in conjunction with other result values to more intelligently evaluate an email address if the need arises. For example, if an email comes back as unknown in either the Score or in IsDeliverable, then we can refer to the following outputs to help us decide if we should accept, reject or retry the email address.

IsSMTPServerGood:

Returns true, false or unknown to indicate if the email’s host mail server was responsive at the time of the check. This is a one of the service’s critical checks. If this value comes back false then it will be reflected in the IsDeliverable value and in the score. Refer to this value if the email is unknown. If the value for this field is also unknown then the service most likely did not have enough time to finish verifying the email address with its host mail server. In these cases the service will continue to try and verify the email in a background process even though the request has finished. Chances are high that if you wait one or more hours and check the email again that the service will have been able to finish verifying the email addresses with the host mail server.

IsCatchAllDomain:

Returns true, false or unknown to indicate if the email’s host mail server is a catch-all. A catch-all mail server will say that an email address is deliverable even if it is not.  This is because catch-all mail servers do not reject email addresses during the initial SMTP session. This means that a catch-all mail server cannot be trusted to verify the deliverability of an email address because it may or may not reject the email address until after an email message is sent. If an email address is unknown and this value is false then chances are good that if the email is checked again at a later time then the service will have verified its deliverability. If catchall is true and there are no warnings, then we know that the mail server is good and that the email does not appear to be bad. In general this scenario leads to a 55% chance that the email is deliverable and won’t result in a hard bounce.
IsSMTPMailBoxGood:

Returns true, false or unknown to indicate if the service was able to verify the email address with its host mail server. This value can be treated similarly to the IsDeliverable value. A true value indicates that the email address is deliverable. If the value comes back false then the mail server verified that the email is undeliverable. A false will be accompanied by the warning flag, ‘Email is Bad – Subsequent checks halted.‘ Some common reasons why this value will return unknown; the mail server is a catch-all, the service ran out of time when communicating with the host mail server or the host mail server used a defensive tactic such as a greylist.

A complete list of the output fields and values are available in the service developer guide.

The result fields given above are useful when it comes to sorting, grouping and filtering all of your validated email addresses. This is useful when working on a post-processing email job, which we will discuss later. Next, we will look at some of the descriptive flags that the service will return. These flags can be used programmatically or at a glance to determine the status of an email address.

Warning Codes & Descriptions:

There are many warning flags that the service may return but we will look at some of the more common and critical ones.

DisposableEmail, SpamTrap, KnownSpammer and Bot

An email address may be deliverable but if one or more of these warning flags is returned then it is highly recommended to reject it.

Alias, Bogus and Vulgar

If one of these warning flags is returned then you may want to either reject the email or set it aside for later review, depending on how strict you want to be.

InvalidSyntax, InvalidDomainSpecificSyntax and InvalidDNS

These are warnings for critical checks that failed. If one of these flags appears then it will be immediately followed by the warning flag ‘Email is Bad – Subsequent checks halted.‘

Email is Bad – Subsequent checks halted

This warning indicates that the email failed a critical check and is undeliverable. If the flag is not preceded by one of the critical warning flags then it simply means that the email’s host mail server verified that the email address is undeliverable.

A complete list of warning codes and their descriptors are available in the dev guide.

Note Codes & Descriptions:

The note flags will return descriptive information about the email, not all of which will affect the score, but we will focus on the ones that will explain why some email addresses came back as unknown.

GreyListed

The service is good at detecting greylist behavior from mail servers and has procedures in place to avoid them, but not all greylists are avoidable. If the service encounters a greylist then it is temporarily unable to verify the email address with its host mail server. If you encounter a greylist then chances are good that if you try to validate the email again a couple of hours later that you will get a better response.

MailServerTemporarilyUnavailable

This flag indicates that the service was able to connect to the email’s host mail server, but that the server was temporarily busy or unavailable and it was unable to verify the email for us. If you encounter this flag then try and validate the email again a few of hours later to see if the server becomes more responsive then.

ServerConnectTimeout

This flag indicates that the service was unable to establish a connection with a host mail server. A possible reasons for the connection failure could be that the mail server is completely offline or it is responding too slow and unable to respond in time. Some mail servers are configured to commonly respond slowly, taking as long as 60 seconds to respond to a connection. This behavior is rare but it is not entirely uncommon. If an email returns this flag then try and enter a longer timeout time to allow the service the time it needs to verify the email.

MailBoxTimeout

This flag indicates that the service was unable to finish verifying the email address with the host mail server in the time allowed. The mail server could be responding very slowly or the timeout time given to the service was too short. If an email returns this flag then try and enter a longer timeout time to allow the service the time it needs to verify the email.

A complete list of note codes and their descriptors are available in the developer guide.

Use Case 1 – Using Validate Email Address for Form Validation

The ValidateEmailAddress method has four input fields that are all required.

Input Field Name	Description	Notes
EmailAddress	The email address you wish to validate.
AlowCorrections	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.	The majority of the email corrections are being performed on the domain. The local part of the email address, the portion before the @ symbol, is generally left untouched.
Timeout	Accepts an integer as a string. Timeout time is in milliseconds. Do not include any commas or non-numeric values. This 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. A minimum value of 200ms is required.	When it comes to form validation it is recommended to use a timeout time that is short enough to not keep your user impatiently waiting, but long enough to allow the server-to-server communication time to finish. A relatively short timeout time between 2 to 4 seconds is generally recommended.
LicenseKey	Your license key to use the service.

Accept, Reject or Review & Retry

ACCEPT

Emails with a score of 0, 1 or 2. In general it is recommended to not be too strict when accepting emails in a form because you do not want to potentially lose an end user.  Also, when performing form validation an end user may become agitated if they have to wait more than 5 seconds for the validation process to complete, but some slow mail servers may not be able to respond in that short amount of time.

REJECT

Emails with a score of 3 or 4. If you do not want to be too strict then you can accept 3 for review, but you should always reject an email that receives a score of 4.

REVIEW & RETRY

Depending on how strict/cautious you want to be you can choose to not initially accept emails with a score of 2 and instead put them aside to have them reviewed. If the IsCatchAllDomain field is not true then you can try and validate the email again later. Email addresses that return a score of 3 can also be set aside for review if you do not want to initially reject all of them. An email will commonly be given a score of 3 if a potential vulgarity or string of garbage characters is found.

In form validation the programmer is sometimes allowed some luxuries while others are taken away. For example, a programmer can be given the opportunity to communicate a result back to the end user but is usually restricted to a shorter timeout time so that the end user is not kept waiting too long. If you have the ability to communicate back the end user then ask the user to check for a typo and try again or try a different email address. If you don’t want to accept a role or alias type email address because they are commonly not accepted by mass email marketers then you can catch for that and tell the user to try again with a different email address.

Use Case 2 – Using ValidateEmailAdress for Batches, Email Campaigns and Data Hygiene

The ValidateEmailAddress method has four input fields that are all required.

Input Field Name	Description	Notes
EmailAddress	The email address you wish to validate.
AlowCorrections	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.	The majority of the email corrections are being performed on the domain. The local part of the email address, the portion before the @ symbol, is generally left untouched. Since you are unable to ask a user to re-enter and try again if they make a mistake you can set this value to true and allow the service to make corrections.
Timeout	Accepts an integer as a string. Timeout time is in milliseconds. Do not include any commas or non-numeric values. This 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. A minimum value of 200ms is required.	For non-form validation it is recommended to give the service plenty of time to verify an email address with its host mail server. Most mail servers will only take about 2 seconds on average to verify an email address, but for the occasional slow mail server that requires more time it is recommended to set the timeout time to 65 seconds. The number of mail servers that require this much time is generally minimal, so the long timeout should not make a big impact on the overall batch job.
LicenseKey	Your license key to use the service.

Accept, Reject or Review & Retry

ACCEPT

Emails with a score of 0 or 1.

REJECT

Emails with a score of 3 or 4. If you do not want to be too strict then you can accept 3 for review, but you should always reject an email that receives a score of 4.

REVIEW & RETRY

Emails with a score of 2, unless the IsCatchAllDomain field value is true. An email that gets an unknown score  due to a greylist, timeout or temporarily busy server should be checked again a couple of hours later.

If you would like to discuss your particular use case for recommendations and best practices contact us!

You probably know what omnichannel means, but a quick definition is always helpful. It refers to the various touch points by which a business/organization can reach a customer. The idea — and the ideal — is to get the offer in front of them at the time they’re most likely to be interested. Typically in the modern business ecosystem, omnichannel refers to:

• Website
• Brick and mortar locations
• Social media
• Other digital efforts
• How you come across on mobile
• Face-to-face interactions between customers and employees

There is more you could group under omnichannel, but that’s a good start. Unfortunately, in a few years from now, we may need a different approach entirely.

Why?

OMNICHANNEL AND THE RAPID SCALE OF BIG DATA 

Consider this: in 2020, it’s possible 1.7 megabytes of new data will be created for every person on the planet every second. If you do the full math on that, the total volume of data globally in 2020 might be around 44 zettabytes. A zettabyte is a trillion gigabytes. This is somewhat because of “The Internet of Things” — connected devices and sensors — which should have an economic value of $3 trillion by 2025. Internet of Things tech alone will be 3-6 zettabytes of that total.

Now we know the rapid scale of Big Data. It’s actually arriving in daily life maybe faster than even mobile did. What are the repercussions?

THE REPERCUSSIONS FOR OMNICHANNEL

As noted in this post on Information Age:

Companies hoped “omnichannel experiences” would enable them to anticipate customers’ needs to provide them with a personalised response, which meets or even exceeds their expectations. And this effort is based on the company’s ability to mobilise the necessary data to deliver.

But what happened?

Today, these same companies struggle to draw together all the information required to give them a unified view and appreciation of their customers’ needs. The result is a mixed bag of omnichannel initiatives, many of which result in failures. In the retail sector, for example, only 18% of retailers claim to have an engagement strategy, which covers all channels.

The sheer math looks like this: 44 zettabytes of generated data in 2020 is 10 times — yes, ten times — what we are generating now, three years earlier. Companies are already struggling to manage data properly towards better customer experience. What will happen when 10 times the data is available in 33 months or so?

WHAT’S THE FUTURE LOOK LIKE FOR OMNICHANNEL AND CX?

This is obviously hard to predict. In times of great complexity, though, sometimes sticking to the basics — i.e. The Five Customer Experience Competencies — isn’t a bad idea. A strong base almost always beats an all-over-the-place strategy.

In my mind, this is what needs to happen:

• Companies need a good handle on what really drives their business now and what could drive it in the future.
• This involves products/services but also types of customer and platform they use.
• Once that picture is mostly clear, senior leaders need to be on the same page about the importance of customer-driven growth.
• “Being on the same page” also involves, ideally, vocabulary and incentive structures.
• If the customer-driven plan/platforms and senior leadership alignment are there, now you need to make sure the work is prioritized.
• No one should be running around on low-value tasks when great opportunity is right there.
• Kill a stupid rule, etc. Basically move as many people as possible to higher-value work, especially if lower-value work can be more easily automated.
• It’s all been important so far, but let’s bold this: You don’t need to collect all the data. You need data that relates to your priorities and growth. 
• That data should be analyzed and condensed for executives. You may need “data translators,” yes.
• Decision-making should come from relevant information and customer interactions.

This flow is hard to arrive at for some companies, but essential.

Phrased another way: trying to be “omnichannel” in five years and looking at an Excel with trillions of touch points/data on it? That will just burn out employees and managers alike. You need a prioritized, aligned plan focused on customer-driven growth and well-articulated goals. That will get you there post-omnichannel.

Reprinted from LinkedIn with permission from the author. View original post here.

Author’s Bio: Jeanne Bliss, Founder & CEO, CustomerBliss

Jeanne Bliss pioneered the role of the Chief Customer Officer, holding the first-ever CCO role at Lands’ End, Microsoft, Coldwell Banker and Allstate Corporations. Reporting to each company’s CEO, she moved the customer to the strategic agenda, redirecting priorities to create transformational changes to each brands’ customer experience. Her latest book, “Chief Customer Officer 2.0” (Wiley) was published on June 15, 2015.

For most organizations, one of the most critical assets of their marketing operations is their email contact database. Email is still the lingua franca of business: according to the Radicati Group, over a quarter of a trillion email messages are sent every business day, and the number of email users is expected to top 4 billion by 2021 – roughly half of the world’s population. This article will explore current best practices for protecting the ROI and integrity of this asset, by validating its data quality.

The title of this article is not just a cute play on words – and it has nothing to do with Santa. Rather, it describes an important principle for your game plan for email data quality. By implementing a strong two-step email validation process, as we describe here, you will dramatically reduce deliverability problems, fraud and blacklisting from your email marketing and communications efforts.

The main reason we recommend checking emails in two stages revolves around the time these checks take: many checks can be performed live using a real-time API, particularly as email addresses are entered by users, but server validation in particular may require a longer processing time and interfere with user experience. Here are 3 of the most important checks that are part of the email validation process:

• Syntax (FAST): This check determines if an email address has the correct syntax and physical properties of an email address.

• DNS (FAST): We can quickly check the DNS record to ensure the validity of the email domain (MX record) for the email address. (There are some exceptions to this – for example, where the DNS record is with a shoddy or poor registry and the results take longer to come back.)

• Email Server (VARIABLE, and not within the email validation tool’s control): Although this check can take from milliseconds to minutes, it is one of the most important checks you can make – it ensures that you have a deliverable address. This response time is dependent on the email server provider (ESP) and can vary widely: large ESPs like Gmail or MSN normally respond quickly, while corporate or other domains may take longer.

There are many more checks in Service Objects’ Email Validation tool, including areas such as malicious activity, data integrity, and much more – over 50 verification tests in all! We auto-correct addresses for common spelling and syntax errors, flag bogus or vulgar address entries, and calculate an overall quality score you can use to accept or reject the email address. (For a deeper dive, take a look at this article to see many of the features of an advanced EV tool.)

Here are the two stages we recommend for your email validation process:

Stage 1: At point of entry. Here, you validate emails in real-time, as they are captured. This provides the opportunity for the user to correct mistakes in the moment such as typos or data entry errors. Here you can use our EV software to check for issues like syntax, DNS and the email server – however we recommend setting the API configuration settings to no more than a wait of a couple of seconds, for the sake of customer experience. At this stage either the user or validation software has a chance to update bad addresses.

Stage 2 – Before sending a campaign. Validate the emails in your database – using the API – after the email has been captured and the user is no longer available in real-time to make corrections. In this stage, you have more flexibility to wait for responses from the ESPs, providing more confidence in your list.

It is estimated that 10-15% of emails entered are not usable, for reasons ranging from data entry errors to fraud, and 30% of email addresses change each year. Together these two steps ensure that you are using clean and up-to-date email data every time – and the benefit to you will be fewer rejected addresses, a better sender reputation, and a greater overall ROI from your email contact data.