Email Validation Before Sending: Syntax, MX, Disposable, Role and Catch-All Checks

Every address on your list is a small bet. If it is real and wanted, the message arrives. If it was mistyped, abandoned or invented, the message bounces, and mailbox providers notice who sends to many addresses that do not exist. Email validation is the practice of checking addresses before you send, so that the bad bets are removed early. In this guide we explain what each check actually does, what each result means, what to do with it and, just as important, what validation cannot promise.

Why validate at all

A hard bounce is a permanent failure, usually because the mailbox or domain does not exist. We explain the codes in SMTP bounce codes explained. Providers treat a high share of such failures as a sign of careless list collection. Sending platforms also watch bounce rates, because a sender with many bad addresses is a risk to everyone who shares infrastructure. Validation lowers that risk before it appears in your numbers.

There are also plain business reasons. Every bad address costs sending volume, adds noise to your reports and, for a person who made a typing mistake, means a welcome message or a receipt that never arrives. Catching the error at the form, while the person is still there, fixes the problem for them as well as for you.

The checks, one by one

Check	What it looks at	What it can tell you	What it cannot tell you
Syntax	Structure of the address against the rules of RFC 5321 and RFC 5322	The address is malformed or plausible	Whether the mailbox exists
Domain	Whether the domain exists in DNS	A nonexistent domain cannot receive mail	Whether anyone reads mail there
MX records	Mail exchangers published for the domain	The domain is set up to receive mail, or explicitly is not	Whether a specific mailbox exists
Address type	Disposable provider lists, role names such as info or support	Short-lived or shared mailboxes	Whether the person is genuine
Mailbox behaviour	How the receiving server answers at the SMTP stage, including catch-all tests	Sometimes a clear yes or no	Anything, when the server accepts everything or refuses to answer

Syntax checks

The structure of an address is defined in RFC 5321 for transport and RFC 5322 for message headers. In short, there is a local part, an at sign and a domain. RFC 5321 limits the local part to 64 octets and the full path to 256. The rules are more permissive than most people expect: plus signs are allowed, quoted local parts exist, and RFC 6531 allows non-ASCII characters in internationalised addresses.

This is why we advise against clever patterns. A strict regular expression written from memory often rejects addresses that work, and each false rejection is a lost customer. A sensible form check looks for a single at sign, a non-empty local part, a domain with at least one dot and no spaces. Anything beyond that belongs to the later checks and to confirmation.

Domain and MX checks

Next, the validator looks up the domain in DNS. Mail for a domain is routed to the hosts in its MX records. If a domain has no MX record but does have an address record, RFC 5321 says senders fall back to that host, so a missing MX is not always fatal. A domain that does not exist at all certainly is. A domain can also publish a null MX, defined in RFC 7505, which states that it accepts no mail whatever, and that should be treated as invalid.

This check catches typos in the domain part, abandoned domains and made-up names. It does not tell you whether the mailbox before the at sign exists.

Disposable and role addresses

Disposable addresses come from services that hand out temporary mailboxes, so someone can reach a download or a trial without giving a real address. Validators compare the domain with maintained lists of such services. No list is complete, because new services appear all the time, so treat the result as a strong hint rather than proof.

Role addresses are named after a function and not a person, such as info, sales, support, admin or billing. RFC 2142 defines a set of well-known mailbox names for organisations. Several people may read a role mailbox, which means a marketing message can reach someone who never signed up and is more likely to complain. For invoices, notices and account messages they are normal and often the right choice.

Mailbox checks and catch-all domains

Some validators go further and open an SMTP conversation with the receiving server, then ask whether it would accept a recipient, without sending a message. When a server answers clearly that the user is unknown, the address is invalid. Many servers do not cooperate, though. Some accept every recipient during the conversation and bounce later, some delay or block repeated probing, and some give different answers depending on who is asking.

A catch-all domain is configured to accept mail for any local part. For such a domain, a made-up name and a real one get the same yes, so no outside check can tell them apart. Validators usually test this by asking about an address that cannot plausibly exist, and if the server says yes, the whole domain is marked catch-all. The correct reading is uncertainty, not validity. Catch-all setups are common in business domains, so you will see them on real B2B lists.

Typo suggestions

Many bad addresses are honest mistakes: gmial.com for gmail.com, a missing letter in a popular provider, a comma instead of a dot. A form can compare the domain with a short list of widely used providers and offer a suggestion such as Did you mean the corrected domain? The rules that keep this safe are simple.

• Suggest, never replace silently. The person may really own the unusual domain.
• Make accepting the suggestion one click, and keep the original editable.
• Limit suggestions to close matches of well-known domains, to avoid annoying people.
• Apply the same logic to imports in bulk, but have a person review the changes, because a wrong correction mails a stranger.

What to do with each result

Tools name their categories differently, but results almost always fall into four groups. Define the action for each one in advance, so the decision does not depend on who handles the list that day.

Result	Meaning	Recommended action
Valid	Passed all checks, and the server gave a positive signal	Mail normally. Still confirm new sign-ups and watch bounces
Invalid	Bad syntax, a nonexistent domain, a null MX or a clearly unknown user	Do not send. Ask for a correction at the form, or suppress the address
Risky	Catch-all domain, disposable address, role address, or other warning signs	Decide by use case. Confirm by opt-in, send in a small first batch, or route to a separate list
Unknown	The check could not finish because of timeouts, blocking or greylisting	Retry later. If it remains unknown, treat like risky and confirm before regular sending

Notice that only one category is an automatic yes and only one is an automatic no. The two in the middle are where judgement matters, and they are also where the money is saved: a policy that mails risky addresses carefully, in stages, recovers real customers that a blunt filter would throw away.

When to validate

Moment	Best for	Typical checks	Watch out for
At sign-up or checkout	Catching typos while the person is present	Syntax, domain, MX, typo suggestion, disposable flag	Slow lookups blocking the form, and false rejections. Fail open if the check times out
On import	Lists from events, partners or old systems	Full set, including mailbox behaviour	Never import purchased lists. Consent is a separate problem from validity
Before a campaign	Older segments that have not been mailed recently	Full set, then small test batches	Addresses can go bad the day after validation, so do not rely on old results

Both moments matter. Validation at the form is cheap and prevents the problem. Validation before a campaign deals with decay: people leave jobs, close accounts and abandon mailboxes, so a list that was clean a year ago is not clean now. Our guide to list hygiene and sunset policies covers the engagement side of the same problem.

Validation, double opt-in and suppression: three different jobs

It is easy to treat these as alternatives. They are not. Each answers a separate question, and a healthy list uses all three.

1. Validation asks whether the address can receive mail. It works without the owner doing anything.
2. Double opt-in asks whether the owner wants your mail. A click on a confirmation link proves control of the mailbox and consent in one step. See sign-up forms and double opt-in.
3. Suppression remembers who must not be mailed: hard bounces, complaints and unsubscribes. Without it, a clean-up is undone the next time someone re-imports the old file. See suppression list management.

A practical flow for a new sign-up looks like this: validate syntax and domain at the form, offer a typo correction, send the confirmation message, and add the address to the active list only after the click. If the confirmation bounces, suppress the address. Risky addresses are not a special problem in this flow, since the confirmation step settles whether the mailbox is real.

A worked example: cleaning an aged import

A small business has 20,000 addresses collected over several years from a webshop and event sign-ups. Nobody has mailed the older part of the list for about a year, and the team plans a re-introduction campaign. Sending to everyone at once would risk a spike in bounces.

The team validates the whole file first. Syntax and domain checks remove addresses with malformed text and domains that no longer exist. Typo candidates are listed for a person to review, and a few are corrected. The valid group is mailed in stages, starting with a small slice, while the team watches the bounce rate. The risky group, which includes catch-all and role addresses, receives a single plain confirmation message asking whether the person wants to stay; those who click move to the active list. The unknown group is re-checked a few days later and then treated like risky. Everything that bounces or never responds is added to the suppression list. The numbers in such a project vary a lot from list to list, so we do not give percentages, but the order of operations is the part to copy: remove the certain failures, stage the certain successes, and ask the uncertain middle.

What validation cannot guarantee

• Delivery. A valid mailbox can still reject or filter your message because of authentication, reputation or content. See email deliverability metrics for what to measure.
• Permanence. A result is a snapshot. A mailbox can fill, close or be deleted soon after the check.
• Consent or identity. A real address might belong to someone else, perhaps through a typo that happens to hit a real mailbox, or through someone who signed up another person. Only confirmation addresses this.
• Engagement. Valid addresses can still be uninterested and report your mail as spam. Complaints are a separate signal, discussed in our guide to the spam complaint rate.
• Completeness of lists. Disposable and role detection depends on maintained data, so it will miss some cases and wrongly flag others.

Different tools will also disagree on the same address, especially for catch-all and unknown cases, because they probe differently and keep different data. Compare your own bounce results with the validator verdicts over time, and adjust your policy to what you see.

Choosing and using a validation service

You can run the cheap checks, syntax and DNS lookups, inside your own application. Mailbox probing and disposable lists are usually bought as a service, because they need maintained data and careful handling of probing. Whichever route you choose, ask a few practical questions.

• Does it return categories like risky and unknown, or only a yes or no?
• How does it handle catch-all domains and timeouts, and does it say so in its results?
• Where does the address data go, and is that acceptable under your privacy policy? Addresses are personal data, so check the provider privacy terms against your own obligations.
• Does it probe from its own infrastructure, so that your sending IPs are not involved?

For what your own MigoSMTP account offers around validation, check your MigoSMTP dashboard or API reference. We do not assume that any particular validation feature exists, and you should confirm what is available before building a process around it.

A short checklist

1. Sign-up forms use a permissive syntax check and a domain check, and fail open on timeouts.
2. Typos get a one-click suggestion and are never changed silently.
3. Disposable and role addresses have a written policy per form or use case.
4. Every result category has a defined action: send, correct, confirm, retry or suppress.
5. New sign-ups confirm by double opt-in before joining the active list.
6. Hard bounces and complaints go to the suppression list automatically.
7. Old or imported lists are validated and then mailed in stages before a campaign.
8. Bounce results are compared with validator verdicts, and the policy is adjusted.

Further reading and sources

• RFC 5321: Simple Mail Transfer Protocol (address limits and MX fallback)
• RFC 5322: Internet Message Format (address syntax)
• RFC 7505: A Null MX No Service Resource Record for Domains That Accept No Mail
• RFC 2142: Mailbox Names for Common Services, Roles and Functions