When we can’t verify an email address, we’ll tell you why. There are a number of reasons, here’s a guide to the most common ones.


Mail server configuration - often when configured to have anti-spam measures


Have you ever sent an email to someone and received a reply asking you to click a link and validate that you are a real person, as the company you’re emailing has anti-spam measures, or strict firewall practises? These security measures are often in place in public service organisations, technology companies or companies that may be prone to spam and cyber attacks.


In order to verify an email address we need to connect with the mail server. If we aren’t able to connect we can’t verify whether the email address you’ve submitted for checking is real. That’s why we’ll return unverifiable as a result. We simply don’t know.


Catch All servers (ServerIsCatchAll)


Some mail servers are configured to accept all emails to a domain. Literally ‘catch all’. No matter what email address being validated, assuming the domain is input correctly, we’ll receive a response telling us everything is OK.


That may sound good but in terms of validating your data and leaving you with knowledge about your emails, it’s not much use. For example, if our server was configured as catch all, you could email [email protected] and the email would still be received positively by the mail server.


Catch all servers are more numerous than you’d think. Often the email addresses that don’t reach an individual’s mailbox are collected and deleted. It’s a server set-up that large organisations might adopt, as it enables easy centralised management of mailboxes when staff change. If catch all was a physical mail delivery system, your letter would be sent to a mailroom where it would be manually sorted and handed to the recipient. Every letter would get through the mailbox but only letters addresses to real people would be delivered.


When we find a catch all server we’ll tell you it’s unverifiable and then give you ServerIsCatchAll as a reason code. It’s important not to keep trying to validate emails that have ServerIsCatchAll as a response code as the result will never change.


Greylisting


This process is a mail server tactic designed to slow down and challenge the authenticity of incoming requests. Our request to the mail server is met with a response along the lines of ‘come back in 20 minutes’. Our IP address is noted, along with the time. If we come back with another request in the wrong time frame we’ll be given a second strike, come back again and we might get third strike and our IP address blocked by that mail server, usually for a period of time rather than forever.


Greylisting servers are set-up by the person configuring the mail server, so there is no set rule and the rules can change at any time. If we meet a greylisting server when validating emails by our bulk service, we’ll do as we’re told (within reason) and come back later. Our Realtime API will always return ‘unverifiable’ when experiencing a greylist request.


Transient Network Fault


Sometimes there is a blip and we encounter a transient fault, somewhere on the network that connects our attempt to validate with the mail server that we’re asking to respond.


Think of your computer or company network. How often does your machine boot up slowly, or something strange occurs that clears when you reboot? There are many reasons for temporary glitches, and sometimes the stars align and we are trying to validate just as something odd happens. When we return unverifiable results due to these unforeseeable temporary issues, future results are likely to be different - it’s worth trying again.