Layered architecture diagram for invalid email filtering in registration

Invalid Email Filtering in User Registration: A Low-Cost Layered Approach

USpeedo
Knowledge Guides
23 Jul, 2026

When users enter an email address on a registration page, they often make mistakes that look absurd but are actually very common:

Entering gmail.cn instead of gmail.com;
Entering gmaii.com instead of gmail.com;
Adding spaces before or after the domain, or using full-width ＠ and ． characters;
Misremembering uspeedo.console@gmail.com as uspeedo-console@gmail.com;
Entering an address with valid syntax and a real domain, even though the specific mailbox does not exist.

For a registration system, these mistakes do more than waste a verification email. They generate hard bounces, pollute the user database, and increase retry and customer support costs. Once invalid addresses reach a certain percentage, they can also damage the reputation of the sending domain and IP address.

The good news is that most basic mistakes do not require SMTP probing. A few layers of local validation, plus a cacheable DNS lookup, can block most problematic addresses at a very low cost.

A high-quality email service provider: uSpeedo

Layer 1: Normalize the Input, but Do Not “Fix” the Address Automatically

When users copy and paste an email address, they may accidentally include leading or trailing spaces. Mobile input methods may also produce full-width characters. These issues can be handled immediately on the frontend:

Remove leading and trailing spaces;
Convert full-width ＠ and ． characters to their half-width equivalents;
Convert the domain to lowercase;
Apply IDNA/Punycode processing to internationalized domain names.

However, do not silently remove characters from the middle of an address or automatically change gmaii.com to gmail.com. A domain that looks like a typo may still be a legitimate corporate domain. A safer approach is to display a suggestion:

You entered name@gmaii.com. Did you mean name@gmail.com?

Letting the user confirm the correction is more reliable than rewriting the address automatically in the background.

Layer 2: Use Practical Syntax Rules to Catch Obvious Errors

Email syntax standards are complex. A registration page does not need a giant regular expression that attempts to cover every possible case. A maintainable set of practical rules is more appropriate:

The address must contain exactly one @;
Neither side of the @ may be empty;
The domain must not contain spaces, consecutive dots, or empty labels;
Each domain label must not begin or end with a hyphen;
Check the maximum lengths of the local part, domain, and complete address;
If the product does not support internationalized email addresses, explain this clearly instead of treating all non-ASCII characters as invalid user input.

Syntax validation can only prove that an address “looks like an email address.” It cannot prove that the address can receive email. However, because it requires almost no network resources, it should be the first line of defense on every registration page.

Layer 3: Suggest Corrections for Common Email Domains

Maintain a list of common email domains that match your target users, such as Gmail, Outlook, Hotmail, and Yahoo, along with popular email providers in your target markets. Calculate the Damerau–Levenshtein distance between the entered domain and the domains on this list—that is, the number of insertions, deletions, substitutions, or adjacent-character transpositions required to transform one into the other.

Typical cases include:

Input	Possible Issue	Product Action
`gmaii.com`	`l` was entered as `i`	Suggest `gmail.com` and ask the user to confirm
`gmial.com`	Adjacent characters were swapped	Suggest `gmail.com` and ask the user to confirm
`gmail.con`	The top-level domain was mistyped	Suggest `gmail.com` and ask the user to confirm
`gmail.cn`	The wrong domain suffix may have been selected	Display a warning based on DNS results, but do not change it automatically

The distance threshold should not be too broad. For short domains, even a one-character difference can be significant. Corporate email domains should never be blocked simply because they resemble a well-known provider’s domain.

Layer 4: Add a Small Number of Provider-Specific Rules

Some addresses comply with general email syntax but violate the username rules of a specific email provider.

For example, Google’s published Gmail username rules allow letters, numbers, and periods, but not hyphens. Therefore, although uspeedo-console@gmail.com may pass many general-purpose email regular expressions, it should still trigger a warning during registration.

Another common source of false positives is Gmail’s handling of periods. For personal @gmail.com addresses, Google ignores periods in usernames, so uspeedo.console@gmail.com and uspeedoconsole@gmail.com are delivered to the same inbox. However, this rule does not apply to corporate or school domains using Gmail, and you should not assume that every email provider ignores periods.

Provider-specific rules should cover only the leading platforms and should be configurable, gradually deployable, and easy to roll back. Avoid hard-coding assumptions about hundreds of providers.

Layer 5: Check DNS to Determine Whether the Domain Can Receive Email

Correct syntax and the absence of obvious typos do not mean that the domain can receive email. The backend can perform the following checks:

If the domain does not exist (NXDOMAIN), mark it as invalid;
Query the domain’s MX records;
If the domain publishes a Null MX record, mark it as not accepting email;
If there is no MX record, follow the email standards and check the A/AAAA fallback path. The presence of an A/AAAA record only means that fallback delivery can be attempted; it does not prove that a mail server is running;
If there is neither an MX record nor a usable A/AAAA record, mark the domain as undeliverable;
If the DNS query times out or returns SERVFAIL, return unknown instead of treating the domain as permanently invalid.

DNS checks can eliminate some clearly undeliverable domains, but they cannot prove that a specific mailbox such as alice@example.com exists. However, DNS results can be cached by domain, keeping the average cost low even with a large volume of registration requests.

A Practical Validation Flow

It is better not to return only true or false. Separating the result into a status, reason, and suggestion makes frontend messaging, log analysis, and future rule adjustments much easier.

type EmailCheck = {
  status: "valid" | "confirm" | "invalid" | "unknown";
  reason?:
    | "syntax_invalid"
    | "provider_rule"
    | "possible_typo"
    | "domain_no_mail"
    | "dns_temporary_failure";
  normalized: string;
  suggestion?: string;
};

async function checkRegistrationEmail(raw: string): Promise<EmailCheck> {
  const normalized = normalizeEmailInput(raw);

  if (!passesPracticalSyntax(normalized)) {
    return { status: "invalid", reason: "syntax_invalid", normalized };
  }

  const providerIssue = checkProviderSpecificRules(normalized);
  if (providerIssue) {
    return { status: "confirm", reason: "provider_rule", normalized };
  }

  const suggestion = suggestCommonDomain(normalized);
  if (suggestion) {
    return {
      status: "confirm",
      reason: "possible_typo",
      normalized,
      suggestion,
    };
  }

  const dns = await checkMailDnsWithCache(domainOf(normalized));
  if (dns === "no_mail") {
    return { status: "invalid", reason: "domain_no_mail", normalized };
  }
  if (dns === "temporary_failure") {
    return { status: "unknown", reason: "dns_temporary_failure", normalized };
  }

  return { status: "valid", normalized };
}

At the product level, the four statuses can be handled as follows:

Status	Frontend Behavior	Send Verification Email?
`valid`	Continue to the next step	Yes
`confirm`	Display the issue and suggestion, then ask the user to confirm	Send after confirmation
`invalid`	Block the submission and explain the reason	No
`unknown`	Allow the user to continue cautiously or retry later	Depends on business risk

Advanced Considerations

These low-cost measures can reduce email delivery costs, but they still have limitations:

There are too many email providers to maintain a complete list. For example, both gmail.com and mail.com are legitimate email domains, and maintaining accurate provider data requires ongoing effort.
These methods are ineffective against disposable and high-risk email addresses because such services frequently rotate their domain names.
SMTP probing provides the most accurate results, but email providers impose strict restrictions on it.

Therefore, if you want to improve your domain reputation, you can combine your own email format validation with an email validation service. This can help protect your sending-domain reputation and reduce hard bounces.