What is a false negative? In email validation, the term is used when an address is incorrectly identified as being invalid or undeliverable – in other words, it is flagged as being bad when it is actually good. In some cases, false negatives may result in lost leads or unwanted rejections. This blog article looks at how they happen, and what we can do about it.
What causes false negatives in email addresses?
The DOTS Email Validation service offers real-time validation and verification of email addresses. Email verification is handled by directly communicating with an email address’ host mail server(s) via Simple Mail Transfer Protocol (SMTP). The protocol is quite old: the original Request for Comments (RFC) for it was published in 1982 and its most recent definition, RFC 5321, was last updated in October of 2008.
A Request for Comments, or RFC, is an official document by which the Internet Engineering Task Force (IETF) publishes standards, protocols, best practices, or other information relative to the operation of the Internet. With enough interest, an RFC may evolve into an internet standard.
The RFC provides rules and guidelines for SMTP communication and behavior; however, mail transfer agents are free to handle compliance in their own way, while others simply operate out of compliance. Additionally, some mail and network administrators will modify mail transfer agent behavior in an effort to battle large volumes of spam/junk mail and malicious behavior.
Moreover, an admin can configure their servers to lie or behave defensively, misusing SMTP codes and/or using codes with misguiding messages. They can configure firewalls and/or install sophisticated software filters to protect their servers from unwanted exposure, which can result in communication behavior akin to a conversation with Dr. Jekyll and Mr. Hyde. In short, there are many scenarios in which false negatives may occur as well as many opportunities for new ones to arise. This is why we are so vigilant in our monitoring of mail server behavior, and why we take false negative reports so seriously.
Understanding temporary versus permanent rejects
False negatives are commonly broken into two categories, temporary failure rejects (also known as soft bounce backs) and permanent failure rejects (known as hard bounce backs). Temporary rejects are commonly used to graylist incoming email; these account for most of the false negative mail server behavior that we see. Conversely, using a permanent reject code to induce a false negative is much more severe and rare, as doing so can lead to unwanted side effects if not properly implemented by a mail server administrator.
DOTS Email Validation is extremely good at identifying and handling behavior that would result in temporary rejects. Permanent reject false negatives are primarily seen when a mail server implements and uses a blacklist. Other cases stem from edge cases that then result in edge cases of edge cases.
Our Email Validation service handles a variety of blacklist and graylist techniques. New blacklist and graylist techniques are generally rare. However, they are not to be taken lightly. These techniques used by mail servers often leave a lasting, but minimal, effect and we frequently audit the Email Validation system for evidence of unhandled blacklists and graylists. If an unconventional blacklist/graylist technique pops up on the radar, we work quickly to identify the specific behavior. Once identified, we are able to update our data to handle future occurrences when communicating with mail servers.
Common permanent reject scenarios
Permanent rejects are commonly used to help identify undeliverable email addresses. Not all SMTP ‘accept codes’ mean that an email address is deliverable, and conversely not all ‘reject codes’ mean that it is undeliverable. When it comes to email validation and verification there are many gray areas to consider and handle.
Based on client feedback, the Email Validation engines have been tuned to err on the side of caution when handling certain unclear permanent reject behavior from mail servers. The Email Validation service will lean more towards returning an UNKNOWN for the IsDeliverable output value when the SMTP session contains potentially contradicting data. Our clients have expressed that they would rather see an email be left as UNKNOWN than to risk it being a possible false negative. This is why Email Validation has a comprehensive output, containing over twenty warning and note flags to help the user better understand why the Email Validation service scored an email the way it did.
Other permanent reject examples are due to scenarios related to (but not limited to) disabled & suspended email accounts, unreachable domain group errors, and various network and storage related errors. Here’s a brief description for each:
- Disabled and suspended accounts – An email address or domain may be disabled or suspended by the mail host for a variety of reasons. Some examples include delinquency, abuse, exceeding a quota, high traffic, misconfiguration, and migration. These emails will often return a permanent reject code, but can change at any time due to user intervention.
- Unreachable domain groups – Mail servers can sometimes encounter internal errors when trying to find and/or connect to a domain group and will report back a false negative. Likely caused by misconfiguration, ambiguity and/or migration.
- Network and storage related errors – Mail servers and DNS can be configured poorly at times, to the point where they become unreachable or unresponsive.
Even though the above scenarios will often lead to permanent rejects, they can change at any time due to user/admin intervention, or sometimes simply waiting for a change to finish propagating.
In some cases, a mail server may handle the above-mentioned errors poorly and return a wrong or misleading response. For example, the mail server returns a permanent reject code with the description “The e-mail account does not exist. Check the e-mail address, or contact the recipient directly to find out the correct address,” even though the address does exist, but the mail server could not find it at the time. In this case, there is nothing in the SMTP description to indicate that the server encountered an internal error or that the email address is bad.
Service Objects persistently works to improve the Email Validation service to better identify and handle potential false negatives. As mentioned previously, some scenarios cannot always be accurately identified, and new scenarios can always arise, but we will continue to update the service to minimize false negatives as much as possible. If you have a question about false negatives or a scenario to troubleshoot, contact our team to further discuss.
