Better verifications for better sending
Mailgun is so excited to tell you about our new v4 email verification service because it gives you what you were missing — guidance. Read more...
Once upon a time, and by “a time” we mean a few years ago, companies sent emails to their contacts and customers somewhat blindly. To a large extent, they didn’t know if the addresses they had in their databases or forms were correct in syntax or one-time-use email addresses or distribution lists that go to 20 different people. All of which could adversely impact their sending domain’s reputation — essentially, it was chaos.
Table of content
Table of content
There were different attempts at addressing this, and the start of it was modest. In the beginning, programmers would use a complex regular expression to validate based on syntax.
However, it didn’t quite cut it. That method didn’t account for misspellings (take a minute and laugh at the idea of malegun.com – go ahead, we did too) or disposable email addresses used to collect coupon codes or role-based addresses that generally lead to higher complaint rates. The problem persisted until different validation services came into the picture.
Around that time, we rolled out our first version of an email verification service. Back then, it was a simple HTTP request to the API as well as a mailbox verification. The mailbox verification checked for the existence of MX records for a domain as well as if the inbox in question actually exists or not.
When we launched it, the feedback we got from customers was fantastic; they needed this ten years ago! But there was something missing to make it truly revolutionary for customers.
What was it?
Here we are in 2019 and what a time to be alive. We are so excited to tell you about our new v4 email verification service because it gives you what you were missing — guidance. Guidance as to whether or not you should send to an email address based on what we know about the address.
Essentially, our verifications service now offers a definitive result of our verification check as well as the risk of sending to such address. All you have to do is submit an HTTP GET request to https://firstname.lastname@example.org and we’ll give you feedback about the address.
How to interpret results and risks
So, let’s take a minute to define the results and risks to get a better understanding of the output v4 validations provides you.
For starters, the result parameter can take one of four values described below. This is the definitive answer for whether or not a sender should use an address and replaces the is_valid parameter in v3 validations.
deliverable – An address that has a high likelihood of being legitimate and has passed all validation checks.
undeliverable – An address that is confirmed invalid and should be discarded from a list or corrected. Sending to this address may damage sender reputation.
do_not_send – An address that may damage sender reputation if messages are sent.
unknown – Unable to make a decision about the validity of the supplied address, usually due to a timeout when attempting to verify an address.
The risk parameter can take one of three values, described below. Risk helps senders understand how sending to an address may impact reputation or the potential impact of allowing a user onto a platform.
low – An address that is likely legitimate and sending to that address has a low likelihood of damaging reputation if the address has been obtained legitimately. We’ll make this assumption based on well-known domains (hotmail.com, gmail.com, etc.)
medium – The default or neutral state for risk calculation. An address that isn’t deemed a low or high risk will default to medium risk.
high – An address that has a high risk of damaging sender reputation or when used for verification should be challenged for validity.
Validations at work
Here are some examples of what these results look like to give you a better idea of what to expect. To start, we’re going to try a valid email address that happens to be role-based, like email@example.com:
Given the results, yes, you can send to this address. However, you’re running a slight risk as it distributes to many people, and your emails have a high likelihood of being marked as spam.
Now let’s try a disposable address, and in the interest of not calling anyone out, we’re going to obscure the domain:
Steer clear of this one — disposable addresses are ripe for abuse.
Finally, how about a known-good address of an individual?
This one is good to go! You can rest assured if you send to this address, your email will deliver and not bounce.
Pretty cool, right?
Mailgun is proud of what we’ve accomplished with this new functionality of our verifications, and we hope you enjoy it! We highly encourage anyone currently using our older v3 verifications to consider migrating their applications to make use of the newest iteration of validations. It’s a massive improvement, both in performance and feedback.
Got any questions? Let us know in the comments!
Build Laravel 10 email authentication with Mailgun and Digital Ocean
When it was first released, Laravel version 5.7 added a new capability to verify user’s emails. If you’ve ever run php artisan make:auth within a Laravel app you’ll know the...
Here’s everything you need to know about DNS blocklists
The word “blocklist” can almost seem like something out of a movie – a little dramatic, silly, and a little unreal. Unfortunately, in the real world, blocklists are definitely something you...