Wouldn’t it be great if there were a service where you could enter an email address, and it would be validated and automatically corrected when an error was found?
The good news is that this service already exists: we do have email correction embedded in our DOTS Email Validation service. However, it is turned off by default. Turning it on is as simple as setting the service’s ‘AllowCorrections’ input value to true. But there are good reasons you might not want to do this. This blog will examine when you should consider automatic email correction, and when you shouldn’t.
The pros and cons of email correction
Of course, the idea of email correction sounds and seems simple enough. In this day and age of auto-correct, why would you not want to correct? But like auto-correct on your phone, when it gets it wrong, the outcomes can range from hilarious to frustrating. With email address correction, getting it wrong can have far more expensive outcomes, from inefficiencies to expensive penalties. To help avoid these outcomes, it is best to focus on how your email addresses are collected, how you plan to use them and ultimately if allowing email addresses to be corrected makes sense for your needs.
Correcting email addresses
First, it is important to understand that when we talk about email corrections, we are generally talking about the domain portion of the email address – the part after the @ symbol. The alphanumeric characters before the @ symbol are usually left untouched.
With that understanding, what kind of corrections can be expected from our Email Validation service when the ‘AllowCorrections’ input field is set to true? This question gets to the heart of why we added this functionality in the first place.
Before we added the option to correct emails, our clients would ask us why we are not able to fix basic typos, like ‘@gmial.com’ corrected to ‘@gmail.com’. On the surface that seems like a reasonable request, and depending on what your user base looks like, you may want these kinds of corrections.
On the other hand, you may also want “@ymial.com” email addresses corrected to “@gmail.com”. There is a problem here though: “ymail.com” is a legitimate domain and changing the domain to ‘@gmail.com’ would be taking a legitimate address and ‘correcting’ it to a bad or incorrect address.
Collecting email addresses
The two most common scenarios for collecting email addresses are; real-time collecting of email addresses through data entry forms, like a web registration form, versus importing or using existing email lists. In the latter case, these emails have already been previously collected or purchased and are stored in your CRM or marketing database. Using these two common scenarios, we can deduce how best to handle most situations where email validation and correction is deployed.
When to allow email address corrections
Setting ‘AllowCorrections’ to equal true is ideal to use as a suggestion for corrections on real-time forms. Using the setting and the result, organizations may choose to alert the user to potential errors and the suggested correction, since the user is present at the time of validation, and can update or correct any data before it is submitted. The key is to make sure your business rules do not interfere with your user’s intention. You do not want to end up in a frustrating loop of suggesting a correction to someone who is happy with their input.
When validating an email list, checking and allowing for corrections is really about your intentions. Are you trying to reach as many people as possible, regardless of accuracy? Setting the ‘AllowCorrections’ value to true will give you the highest number of mailable email addresses, with the understanding that accuracy will likely suffer.
To accommodate those who want email corrections and those who do not, we added the AllowCorrections option to the input parameters of the Email Validation service. Using it is as simple as setting the input value for ‘AllowCorrections’ to true or false.
It bears repeating that since the variation of possible good emails (based on only the domain check) is nearly limitless, applying corrections can be dangerous: this is simply the nature of these corrections. There are, of course, uses cases where you may choose to do them, but we reiterate that using them is risky and requires really examining your use case for it.
If your organization is not sure what is the best option, you can always reach out to us and we can help you make the best decision.