mailtanimailtani
Free Tool

Free Email Address Validator

Check whether an email address is correctly formatted. Instantly validate syntax, catch common typos, and identify malformed addresses before they enter your list.

Enter an email address to validate

How to Use This Tool

Step 01

Enter the email address

Type or paste the email address you want to validate. The tool checks it against RFC 5322 syntax rules.

Step 02

Review the result

The tool shows whether the address is valid, and if not, explains exactly what's wrong — missing @, invalid characters, bad domain format, etc.

Step 03

Clean your list

Remove or correct invalid addresses before importing to mailtani or any other ESP to protect your sender reputation and reduce hard bounces.

What Email Syntax Validation Does and Does Not Tell You

Email address syntax validation checks whether a string conforms to the structural rules defined in RFC 5322 and related standards. A syntactically valid email address has a local part before the @ symbol, the @ symbol itself, and a domain part after it that includes at least one dot separating labels. The local part can contain alphanumeric characters, dots, hyphens, plus signs, and underscores; certain special characters are technically permitted under RFC 5322 but rarely accepted in practice by real mail systems.

What syntax validation cannot tell you is whether the address will actually receive mail. A syntactically perfect email address may point to a domain that has no MX records and has never hosted email. It may be a user that was deleted six months ago on an otherwise valid mail domain. It may be an address the user typed correctly but that does not belong to them. Syntax validation catches typos, malformed strings, and structural errors — it does not confirm deliverability, inbox existence, or ownership.

This distinction matters enormously in practice. Treating syntax validation as deliverability verification leads to list quality problems: you accumulate addresses that look valid but bounce on delivery, damaging your sender reputation with each hard bounce. The right mental model is that syntax validation is the first gate in a multi-stage validation pipeline, not the entire pipeline. It removes garbage — obviously malformed strings — before the more expensive downstream checks.

RFC 5322 Syntax Rules and Common Malformed Patterns

RFC 5322 specifies the grammar for email addresses in precise detail. The local part (before @) allows printable ASCII characters except for a handful of prohibited specials. The domain part follows standard hostname syntax: labels of 1–63 characters consisting of letters, digits, and hyphens, separated by dots, with the overall domain not exceeding 253 characters. An address with two consecutive dots, a local part starting or ending with a dot, or a domain starting or ending with a hyphen is syntactically invalid.

The most common malformed patterns at list import time are: missing the @ symbol entirely (usually a data entry error or paste truncation), spaces within the local part (often from copy-paste of a display name alongside the address), double @ symbols (from concatenation errors in form field processing), and domain parts with invalid characters. Addresses like `user@domain` with no TLD are technically valid in RFC 5322 but indicate local network addresses that are never valid for internet email.

Internationalised email addresses defined in RFC 6530 extend the syntax to allow non-ASCII characters in both the local part and the domain. These are valid under modern standards but require explicit SMTPUTF8 support from both sender and receiver infrastructure, which is not universal. Syntactically validating these addresses requires a validator that explicitly handles UTF-8 local parts and IDNA-encoded domains, not a simple ASCII regex.

Why Validation at List Import Time Protects Your Sender Reputation

The practical case for email validation is fundamentally about bounce management. Every hard bounce — a permanent delivery failure due to an invalid or nonexistent address — is a negative signal that inbox providers record against your sending domain and IP. Google, Microsoft, and Yahoo all factor bounce rates into their sender reputation scoring. Keeping bounce rates below 2 percent is a widely cited threshold; the 2024 bulk sender requirements have made this more explicit.

Validating at list import — rather than discovering bounces on delivery — is economically rational. The cost of validation is incurred once, before you send. The cost of bounces compounds: each bounce degrades reputation, and reputation degradation affects deliverability for your entire sending domain, not just the messages to invalid addresses. If you import a list of 50,000 purchased contacts with no validation and receive a 15 percent hard bounce rate, the reputation damage affects every subsequent campaign you send from that domain.

Syntax validation at import catches the cheapest class of problem: addresses that will never work because they are structurally invalid. Domain validation — checking that the domain exists and has MX records — catches the next class: structurally valid addresses on nonexistent domains. SMTP validation — actually connecting to the mail server and checking if the mailbox exists — catches the most, but is more expensive, slower, and increasingly blocked by major providers who return false positives to prevent harvesting.

Building a Validation Pipeline for Real Applications

In production applications, email validation happens at multiple points with different techniques at each stage. At the form field level, client-side validation with a well-tested regex or a validation library provides instant user feedback for obvious syntax errors. This improves form completion rate by helping users correct typos before submission. However, client-side validation is easily bypassed and should never be treated as the sole gate.

Server-side syntax validation is the authoritative check. On form submission, validate the email against RFC 5322 rules before storing it. Reject syntactically invalid addresses with a helpful error message — this protects your list quality without burdening the user. For higher-stakes use cases, add domain-level validation by resolving the MX record of the email domain before accepting the address. An address with a syntactically valid domain that returns NXDOMAIN on MX lookup has no mail infrastructure and will always hard bounce.

For list imports, run both syntax and domain validation as a batch process before your first send. Flag addresses that fail either check for removal or review rather than sending to them immediately. Track bounce rates by import source and validation state over time to understand where your list quality problems originate. An ongoing discipline of validation at both acquisition and import, combined with regular list hygiene to remove chronic non-openers, is what maintains the list quality that underpins long-term sender reputation health.

Key Features

RFC 5322 Strict Validation

Checks full RFC 5322 syntax rules including local part, domain label, and character restrictions.

Specific Error Descriptions

Identifies and describes specific syntax errors like double dots, missing TLD, and invalid characters.

Common Typo Detection

Flags common domain misspellings like gmial.com or yahooo.com and suggests the correct domain.

Domain MX Record Check

Optionally verifies that the email domain has published MX records, catching valid-looking but undeliverable addresses.

Batch List Validation

Paste or upload a list of addresses and receive a flagged report of invalid entries in one pass.

Validation Level Explained

Explains the difference between syntax, domain, and SMTP validation and what each level can confirm.

Frequently Asked Questions

Clean Lists, Better Deliverability

mailtani's list management tools help you keep your audience clean and your sender reputation strong — all in one platform at a one-time price.

  • List validation on import
  • Hard bounce protection
  • Deliverability monitoring
  • One-time price

14-day free trial · €89 lifetime access after