How an email address that doesn't exist can ruin my business?
Mail servers do not only exchange messages between them; they also have several mechanisms to fight against spam. An email server that receives too many messages destined to non-existing domains can automatically report the emitting domain as a potential spamming source.
Once your domain name received multiple spam suspicion reports, you could be considered a spammer and your mail server could be blacklisted. The consequence is that most of your emails will be blocked by spam filters before they have a chance to reach your recipients' mailboxes.
There are several ways to reduce the risk of being blacklisted. The first and easiest mechanism to set-up is to implement an email address verification script which ensures that the recipient's domain exists and contains email servers.
Why not check the existence of the mailbox against the recipient's SMTP server?
Those who know the SMTP protocol might want to implement a verification script to send the recipient's mail server the VRFY command. The VRFY command allows you to verify a mailbox's existence on an SMTP server, which could have been convenient in our situation. Unfortunately, most SMTP servers do not respond correctly to the VRFY command, making it unusable.
What is the best method to verify MX fields and SMTP configuration?
The fastest and cheapest way is to use an API to verify the email address's domain configuration.
Abstract Email Verification API is free and easy to use. It provides information on the MX fields and the SMTP server and additional interesting data about an email address, in real-time.
To use it, you only need to create an account on the Abstract website. Then you are ready to use the API.
How to check the health of an SMTP server?
Once you have the names of the SMTP servers of the recipient's domain, you should check that its service is working.
The common way to do this is to use the telnet utility and connect to the SMTP port to check that the server responds. The SMTP port number is generally 25, and here is how to proceed:
$ telnet alt2.aspmx.l.google.com 25
Trying 2404:6800:4003:c06::1a...
Connected to alt2.aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP f18si9212169pgg.271 - gsmtp
We received a response from the SMTP server and can deduct for sure that it's up and running.
Note that depending on the server configuration, it is possible that the server is not listening on port 25 but ports 465, 587, or 2525.
How to automate checks on MX records and SMTP servers?
Even if these manual methods allow you to obtain results in a few minutes, it is inconceivable to proceed this way when you have a multitude of email addresses to be checked.
It is then necessary to use a service capable of providing this information automatically and quickly.
Abstract provides an API that allows you to check MX records and SMTP servers from an email address for free. Besides, the analysis data that the Abstract API provides contains a lot of additional information about the recipient's email address and its configuration.
Register on the Abstract site with your email address and your chosen password, which does not require a credit card. You are ready to use the API with a simple GET call. Here is an example of use with curl from the command line:
$ curl "https://emailvalidation.abstractapi.com/v1/?api_key=YOUR_API_KEY&email=johnsmith@gmail.com"
{
"email": "johnsmith@gmail.com",
"autocorrect": "",
"deliverability": "DELIVERABLE",
"quality_score": 0.90,
"is_valid_format": {
"value": true,
"text": "TRUE"
},
"is_free_email": {
"value": true,
"text": "TRUE"
},
"is_disposable_email": {
"value": false,
"text": "FALSE"
},
"is_role_email": {
"value": false,
"text": "FALSE"
},
"is_catchall_email": {
"value": false,
"text": "FALSE"
},
"is_mx_found": {
"value": true,
"text": "TRUE"
},
"is_smtp_valid": {
"value": true,
"text": "TRUE"
},
"quality_score": 0.90,
}
The Domain Name System, commonly known as DNS, is mainly used to match a domain name with an IP address. This is how most Internet users can easily access their favorite websites. But DNS records are not simply limited to websites' IP resolution. They actually provide a whole configuration about a domain name. Among these configurations are MX records, which is an abbreviation of mail exchange. MX records are used to indicate to which mail server to connect to reach the mailboxes hosted on a domain. So an SMTP server needing to send an email will first examine the MX fields of the destination domain to find out which mail server to address next.
Frequently Asked Questions
What is an MX check and why does it matter for email validation?
An MX check looks up the DNS MX (Mail Exchange) records for an email address's domain to confirm that the domain is configured to receive mail. If no MX records exist, any email sent to that domain will bounce. Running this check before sending lets you remove undeliverable addresses before they damage your sender reputation.
What does an SMTP check actually verify?
An SMTP check connects to the domain's mail server on a standard port (25, 465, 587, or 2525) and performs a handshake to confirm the server is live and responding. It is the closest you can get to confirming deliverability without actually sending a message. A failed SMTP check means the mail server is unreachable or rejecting connections.
How do I look up MX records manually?
You can query MX records using the dig command on Unix/Linux (e.g., dig MX example.com) or by entering the domain at Google's DNS lookup service at dns.google.com. The result lists the mail server hostnames responsible for the domain, along with their priority values. If the lookup returns nothing, the domain has no MX records and cannot receive email.
Why can't I just use the SMTP VRFY command to check if a mailbox exists?
The VRFY command was designed to let senders verify individual mailboxes on a mail server, but nearly all modern SMTP servers disable or ignore it to prevent address harvesting by spammers. Because VRFY is unreliable in practice, email validation services instead perform a full SMTP handshake up to the RCPT TO step to infer whether a mailbox accepts mail.
What is a catch-all email server and how does it affect validation results?
A catch-all server accepts any message sent to the domain regardless of whether the specific mailbox exists. This means an SMTP check will return a positive result even for made-up addresses like xyz123@example.com. To detect catch-all behavior, a validation service sends a second probe with a randomly generated address and flags the domain as catch-all if that also succeeds. Abstract's Email Validation API surfaces this in its response so you can decide how to handle those addresses.
When should I use an API instead of running MX and SMTP checks myself?
Manual checks with dig or telnet work fine for one-off debugging but are not practical at scale. An API like Abstract's Email Validation API handles DNS lookups, SMTP handshakes, catch-all detection, and disposable-domain filtering in a single call, returning a structured JSON response. This is the right approach when validating addresses in a signup form, cleaning a bulk list, or running checks programmatically in your backend.
