How to Read Email Verification Results

An email verification report is a stack of technical clues about each address. It can tell you that a string is shaped like an address, that the domain exists, that the domain publishes a way to receive mail, that the domain is a known throwaway service, or that a receiving server answered a question about that recipient. It cannot tell you that the person still works there, that they want to hear from you, or that their provider will place your message in the inbox.

That limit is easy to forget once a spreadsheet fills with green labels. Mail providers change filtering rules, mailboxes are closed, and some servers deliberately hide whether a recipient exists. A careful sender treats the report as a filter that removes definite waste and separates uncertain rows from stronger ones. The Email Verification Tool is built around that idea: it checks syntax, mail routing, known disposable domains, and role-style mailbox names, and it does not send a message to the contact.

Before you open the report, write down what decision each label is allowed to make. Invalid can leave the send file. Unknown cannot be promoted to valid just because you are in a hurry. A role address can stay if you meant to reach a department and should leave if you meant to reach one named person. Decide those rules once, then apply them to the file, instead of improvising as you scroll.

Every later check assumes the string is an address. If the local part, the @ sign, or the domain is broken, there is nothing useful to look up. Typical breaks are a missing @, two @ signs, a space copied from a spreadsheet cell, a trailing comma, consecutive dots, or a domain with no dot in it. Those rows are not "probably fine". They will bounce, or they will never be accepted by a sending platform.

A syntax failure is also the easiest row to repair, which is why you should read the reason instead of deleting the line on sight. "jane.doe @company.com" is a space that a copy introduced. "jane.doe@company" is a missing top-level domain, and guessing ".com" may create a stranger's address. Fix only the mistakes you can see in the source. If you cannot see the correction, drop the row.

You can do this first pass entirely in the browser. The Email Syntax Checker marks each entry valid or invalid and writes the specific failure, such as a missing @, consecutive dots, or an implausible top-level domain. It uses practical formatting rules rather than every rare form the email standards allow, because those rare forms almost never appear in real lists and would let everyday typos through. A pass here does not contact any server and does not mean the mailbox exists. It only means the shape is good enough to check further.

Keep the original file. The cleaned column is a working copy. Names, signup dates, and the form that produced the row still live in the export, and you will need them when a result is uncertain. Verification answers a technical question. Your spreadsheet still answers who the person is.

Once the shape is acceptable, the next question is whether the domain is set up to receive mail at all. Mail servers publish that setup in DNS, usually as MX records: hostnames, with priorities, that accept mail for the domain. If the domain does not exist, every address on it is undeliverable. If the domain exists but has no mail configuration, the same is usually true.

There is a narrow exception worth knowing so you do not misread it. If a domain publishes no MX record, mail software is allowed to fall back to the domain's ordinary address record. That fallback is uncommon, and a missing MX record is still a warning. This site's verifier treats a domain with no MX record but with an address record as configured for mail, and it records that the MX record itself was absent. A domain that does not exist, or that has neither MX records nor an address record, is invalid. A lookup that times out is not invalid. It is unknown, because the evidence never arrived.

An MX record, or that address-record fallback, proves only that some server is willing to accept mail for the domain in general. It does not prove that jane.doe@ is a real mailbox, that the mailbox has space, or that a future message will be accepted. Many servers accept the domain's mail and then reject unknown recipients later, or they accept every recipient and discard some of them. Reading "mail is configured" as "this person exists" is the mistake that makes a fast report look safer than it is.

The reason text matters more than the colour. "Domain does not exist" and "domain has no mail configuration" are reasons to remove the row. "Mail configuration exists; mailbox is unconfirmed" is a reason to keep the row in a hold or send file only if your policy allows unconfirmed mailboxes. Those two outcomes should never share a filter.

The report uses a small set of labels. Learn them once and the rest of the file is easier to scan. The label is a summary. The reason, and any flag for disposable, role, or catch-all, is the part you act on.

You will also see flags beside the label. A disposable flag means the domain matched a known throwaway provider. A role flag means the local part looks like a function, such as info, sales, support, or admin, including variants such as sales-team. A catch-all flag means the server did not distinguish a real recipient from a fake one. A free-provider flag means the domain is a consumer mailbox service rather than a company domain. Flags can combine with a label. A role address on a domain with working mail is risky even when the rest of the row looks healthy.

Confidence is a relative score for that evidence, not a probability that the person will reply. A malformed address sits at the top of the scale because the failure is certain. A timeout sits near the bottom because the check learned almost nothing. A fast mail-routing result sits in the middle: the domain looks able to receive mail, and the mailbox itself was not tested. Use confidence to sort review queues. Do not use it as a substitute for the reason.

The default check is a fast mail-routing pass. It looks at syntax, disposable domains, role-style names, and whether DNS shows a mail setup. It does not ask the receiving server about one mailbox. Because of that, a normal, well-formed address on a real domain comes back as risky, and the screen labels that group mail-configured rather than valid. A result set with thousands of mail-configured rows and zero valid rows is expected on this pass. It is not a sign that the list is bad.

Read the reason so you can split that large group. "Mail configuration exists; mailbox is unconfirmed without SMTP" describes an ordinary address the fast pass could not confirm. "Role-based mailbox with mail configuration" describes a shared inbox on a domain that can receive mail. Both are risky. They are not the same decision. The first may be acceptable for a permissioned newsletter if you accept some bounce risk. The second should be reviewed against the message you plan to send.

The fast pass is the right default for a large file because it removes the rows that are definitely broken without a slower conversation with each mail server. Use it to delete invalid and disposable addresses, and to see how much of the file is merely unconfirmed. Do not export "everything that is not invalid" and call it verified. Mail-configured means the domain is plausible. It is the start of a send decision, not the end of one.

If a deeper recipient check is unavailable, stay with the fast labels and say so in your notes. Pretending a mail-configured row was individually confirmed will make the next bounce report impossible to explain. The tool's own wording is the safe one: working mail servers on a fast pass are mail-configured, not valid.

A deeper check, when it is offered, goes one step past the domain. It asks the receiving server whether it will accept that recipient, and it also asks about a recipient that does not exist, so a server that says yes to everyone can be recognised. No message is sent. The conversation stops before any email content would be transmitted.

Three answers are common. If the server accepts your recipient and rejects the random one, the mailbox is likely to exist. The row becomes valid, unless it is a role address, which stays risky because a shared inbox is a different kind of risk from a missing mailbox. If the server rejects your recipient, the row becomes invalid even though the domain itself can receive mail. If the server accepts both, the row is catch-all. If the server does not answer, times out, or defers, the row is unknown.

That likely-valid result is still not certainty. Servers can accept a recipient during the check and reject the message later. They can greylist, rate-limit, or refuse the check entirely, which produces unknown rather than invalid. They can accept a mailbox that belongs to someone who left the company last year, because the address was never closed. Use the deeper result to remove clear rejections and to separate catch-all domains. Do not describe the valid file as a list of people who will receive your mail.

Run the deeper check on the rows that survived the fast pass, not on rows you already know are malformed or disposable. Re-checking a missing domain will not create a mailbox. Re-checking a throwaway provider will not make it a lasting inbox. Spend the slower pass where the answer can still change.

Disposable and role are both warnings, and they point in different directions. A disposable domain is a service that hands out short-lived inboxes. People use them to pass a form without sharing an address they read. In a newsletter or a lead file they rarely become customers, and many of them stop existing quickly. The verifier marks a known disposable domain as disposable once it has confirmed the domain can receive mail. Remove those rows from any list you plan to keep.

The disposable list is a curated set of common providers, not a complete census. New throwaway domains appear often, so a row that is not flagged can still be temporary. A local pass with the Disposable Email Domain Checker uses the same kind of domain list and never uploads the file. Treat a clear flag as enough reason to remove the row. Treat a clean result as a strong hint, then glance at domains you do not recognise before you trust them.

A role address is not fake. info@, sales@, support@, billing@, and no-reply@ are often real mailboxes watched by a team or by an autoresponder. They are a poor fit for a note written to one person, and several people may see a message that sounds personal, which raises the chance of a complaint. They are a reasonable fit for a genuine enquiry to a department. The verifier does not delete them. It marks them risky, or it keeps them risky even after a recipient check succeeds, so you can apply your own rule.

Write that rule down. A practical version is: remove no-reply and similar automated names from every send; keep sales@ only when the message is an offer the department asked to receive; remove info@ from any sequence that assumes a first name. The companion guide on how to segment business and personal emails covers how those groups should be written to differently once the technical filter is done. Segmentation chooses the message. Verification chooses which rows are technically worth considering.

Some domains are configured to accept every recipient. The server says yes to jane.doe@ and yes to a random string that nobody created. That pattern is common at companies that would rather catch a typo than bounce it, and at filtering services that hide the real recipient list. A yes in that situation does not identify a mailbox. It identifies a policy.

The report calls this catch-all and keeps it out of the valid bucket. Importing catch-all rows as if they were confirmed is how a "clean" file still produces a wave of later bounces or silent discards. You have three honest options. Leave them out of a cold or high-volume send. Keep them when the person is already a customer and you have other evidence, such as a recent reply or an active account. Or sample a few by sending one plain message you would be willing to have bounce, and watch what happens, instead of mailing the entire domain.

Group catch-all rows by domain before you decide. Fifty uncertain addresses on one company domain are one decision. Fifty uncertain addresses on fifty domains are fifty decisions, and most of them are not worth a guess. The domain is the unit. The local part is what the server refused to confirm.

A fast pass will not show this label, because it never asks the server about a recipient. If you only ran the fast check, you do not know which mail-configured domains are catch-all. Say that in the file notes. Absence of a catch-all flag means the check was not performed, not that the domain is strict.

Unknown is the label people are most tempted to overwrite. The address may be perfect. The check simply did not get an answer: the DNS lookup timed out, the resolver was briefly unavailable, or the receiving server deferred the question. A missing answer is not a rejection. It is also not a confirmation. The honest status is unknown, with a low confidence, until you learn more.

Retry unknown rows once, later, rather than in the same minute. A timeout that hits every address on one large provider is often a temporary limit, and hammering it again immediately repeats the failure. If the second attempt is also unknown, leave those rows out of a send where bounces are expensive. You can keep them in the source file with the date of the attempt. You should not merge them into the valid export to make the count look complete.

Read the reason before you retry. "DNS lookup timed out" and "DNS lookup was unavailable" are infrastructure gaps. "SMTP probe unavailable or temporarily deferred" means the domain's mail setup was seen and the recipient question was not answered. "Deep SMTP probing is unavailable; mailbox remains unconfirmed" means the deeper mode could not run, so the row fell back to an unconfirmed result. Each of those wants a different note in your log, and only the first two are good candidates for a simple retry.

Numbers make the labels easier to trust. The counts below are an illustration, not a benchmark, for a hypothetical file of 1,000 unique addresses from people who registered for a conference. Duplicates are already gone. The first pass is the fast mail-routing check.

After that pass, 92 rows are gone for definite technical reasons and 22 disposable rows are gone by policy. The file people are tempted to call "clean" is the 746. It is not clean. It is unconfirmed. If a deeper recipient check is available, run it on those 746 only. In this illustration that second pass accepts 510 recipients and rejects a random address at the same domain, so those 510 become valid. It rejects 40 real recipients, so those become invalid. It accepts both the real recipient and a random one for 120 rows, so those become catch-all. The remaining 76 get no usable answer and stay unknown.

The send file in this example is the 510 valid rows, plus any of the 71 role addresses you deliberately chose, and none of the catch-all, unknown, disposable, or invalid rows. That is a smaller list than 1,000. It is the list you can explain. The conference source file still holds every row, with the status beside it, so a later retry of the unknown group does not require you to start over.

Notice what the illustration does not claim. It does not say that 510 people will read the message. It does not say the 120 catch-all addresses are fake. It says the evidence was strong for 510, weak for the catch-all and unknown groups, and negative for the invalid and disposable groups. That is all a report can honestly say.

Import the rows whose evidence matches the risk you are willing to take. For a permissioned newsletter, that is usually valid rows from a deeper check, or mail-configured rows from a fast check if you have accepted that those mailboxes were not confirmed and your list is otherwise healthy. For a first send to a new source, prefer the stricter file. A bounce spike on the first campaign is harder to repair than a smaller launch.

• Drop invalid rows. Fix a typo only when the source shows the correction, then check that repaired address again.
• Drop disposable rows from any list you intend to keep.
• Hold role rows in their own file and apply the rule you wrote for shared inboxes.
• Hold catch-all rows by domain. Decide per domain, not per line.
• Hold unknown rows with the date of the attempt. Retry once. Do not merge them into valid.
• Keep the reason and the check mode in a column. A mail-configured export and a valid export must not share a filename.

Name the files after the decision. conference-valid.csv, conference-role-review.csv, and conference-retry.csv will still make sense in a month. conference-clean-final-v3.csv will not. Include the date of the check in the name or in a column, because a result goes stale. Mailboxes are closed and domains lapse. A report from last year is a clue, not a current verdict.

When you import, import one decision file at a time. Mixing the hold file into the send file at the last step is the usual way a careful report is thrown away. If your sending tool accepts a status column, map it and suppress every status except the one you chose. If it does not, the file you upload should already contain only that status.

After the send, compare bounces with the status you stored. A bounce on a valid row is a reason to distrust that domain's server behaviour next time, not a reason to ignore verification. A bounce on a row you marked unknown means the hold policy was right. Write the lesson next to the rule so the next list is classified the same way.

A verified address is still someone's address. The check does not create consent, and it does not repair a list that was collected without a proper reason. Keep opted-in registrants apart from people who were only mentioned in a document or on a page. If you are unsure whether a row may be mailed, leave it out. The cost of a complaint is higher than the cost of a shorter list.

Know what the tool transmits. Spreadsheet and text files are parsed in your browser. The original file is not uploaded. After you review the counts and confirm the job, the normalized addresses are sent to the verification service so the DNS and recipient checks can run. They are deleted when you export the results or reset the job. No verification message is sent to the contact. If you only need a format check or a disposable-domain screen, use the in-browser tools and skip the job entirely.

A single job accepts up to 50,000 unique addresses. Duplicates are removed before the job starts, so the number you confirm may be smaller than the number you pasted. You can pause, resume, or cancel, and an active job can be restored after a reload. Export the full result, a filtered view, or a narrower slice, as CSV, XLSX, or TXT. Exporting is also the moment the working data is cleared, so download the file you need before you reset.

Store the export where the rest of that contact data already lives, not in a downloads folder that nobody owns. Delete the working copies when the import is done. A verification file is a copy of personal data with extra columns, and it deserves the same access limits as the original list.

• Treating mail-configured as valid because the fast pass did not print the word invalid.
• Deleting every risky row, including ordinary unconfirmed addresses, and keeping almost nobody.
• Keeping every risky row, including no-reply and disposable-looking names the flag already explained.
• Guessing a domain ending to "save" a truncated address.
• Re-running the whole file when only one provider timed out.
• Importing catch-all rows into the valid file so the count matches the original export.
• Verifying a list you are not allowed to use, then feeling that the green labels made it acceptable.
• Throwing away the reason column and keeping only the colour.

A reliable habit is short. Back up the export. Check the shape. Run the fast mail-routing pass. Remove invalid and disposable rows. Split role, catch-all, and unknown into their own files. Use a deeper recipient check when you need mailbox-level evidence and it is available. Name the files after the decision. Mail only the file you can explain, and only the people you are allowed to contact.

The report is finished when you can point at any row and say why it is in the send file or why it is not. If the only answer is that the label was not red, you have not read the result yet. Read the reason, apply one written rule, and keep the source. That is the whole job, and it is what keeps a verification report from becoming another spreadsheet nobody trusts.