Maintaining good sending practices is key to ensuring your reputation with ISPs remains high and your emails get through in a timely manner
Our sending practices documentation states:
Typos happen. Pre-screen the email addresses you collect before you send the invitation. Ensure addresses are syntactically correct, and that the domain part of the address has a DNS MX record (which indicates that the domain accepts mail).
Even if you do all the appropriate checks on the client side, such as checking for valid formatting, you’re still going to end up with some addresses in your system that are probably less than perfect.
The format of an email address is a little more straightforward than determining whether the domain can accept emails. I just wrote a bunch of these checks for a service I’m putting together and rolled the tricky DNS MX check into a handy library I called Legit.
Keeping Things Legit
When screening addresses you should be always be validating on the client side, checking for @ symbols and dots at the very least. Some people even check the domain validity but I think that’s an expensive process that doesn’t always need to happen at that stage.
I break my email address validation into two stages; a client side validation and a server side validation. The server side validation happens in the background so doesn’t affect the user journey by going off to check a domain that could be wrong, time out, or not have any MX records attached to it.
Once an email address has been received (having passed client side validation), it is stored in the database with a boolean flag called ‘canEmail’ set to false. It’s set to false because we haven’t checked if the domain attached to the address can even accept emails.
A background worker process checks the email address using the Legit library, which wraps the NodeJS Dns.resolveMx method in a super simple way. Here it is in action:
In the above example the results are being logged out to the console but in production, when an email address is deemed legit, the ‘canEmail’ flag is then set to ‘true’, ready to receive our inbox wonder.
The Legit library is tiny. It’s performing a very simple operation but I’ve written it so many times that I decided it was time to stop repeating myself. This is it:
It checks specifically for the existence of MX records on a domain and if there are some (more than 1), it returns both a validation and the list of MX records.
Why the MX too?
That’s where things get fun (as fun as checking the validity of email addresses can be). The returned MX records can also be checked and used to decide on further sending rules depending on the ISP. You may want to log the fact that the domain uses Google Apps to handle that email so you can bundle your sending to Google in one go. You may have different template layouts for Yahoo! email addresses – you can get creative with this stuff.
Your SendGrid analytics dashboard will tell you how you’re doing with deliverability and you can apply the learning from that to your sending practices. Applying some logic to screening your email addresses will go a long way to making sure you’re sending appropriately and it’s really not a lot of extra work.