Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.spotzee.com/llms.txt

Use this file to discover all available pages before exploring further.

An email syntax validator checks whether an address is structured correctly per RFC 5321 and RFC 5322. The check runs on the string itself, splitting at the @, validating the local part and the domain, and returning a single verdict: valid format, or not. It is the cheapest first step in any list-cleaning workflow because it catches the most obvious failures before you spend a credit on deeper checks.
Run a one-off check at spotzee.com/tools/email-syntax-validator. The result is a binary pass or fail. Use this guide for the rules behind each check and the patterns that fail most often in real list imports.

​
Why syntax matters

Sending to a malformed address always ends in a hard bounce. Hard bounces hit your sender reputation, and a damaged sender reputation drags inbox placement down for the legitimate addresses too. Filter syntax failures first, and the rest of the list moves through verification cleanly. There is also a cost angle. Provider lookups, MX resolution, and SMTP verification each deduct a small per-call amount from your Spotzee credit. Running them on an address that has no chance of working is wasted budget. The syntax pass runs in your browser, costs nothing, and catches the obvious junk in milliseconds.

​
What the validator checks

A correct email address has three parts: a local part before the @, a separator, and a domain. The validator walks each part against the RFC rules.
1

Parse the input

Split the string at the last @. The two halves become the local part and the domain. If there is no @ at all, or more than one outside a quoted form, the address is invalid.
2

Validate the local part

RFC 5321 caps the local part at 64 octets. Letters, digits, plus a small set of punctuation are allowed. Leading dots, trailing dots, and consecutive dots in the unquoted form all fail.
3

Validate the domain

The domain must be a fully-qualified hostname or an IP literal in square brackets. Each label is at most 63 characters, the full domain at most 253, and the domain must contain at least one dot for public mail.
4

Return the verdict

If every rule passes, the address is syntactically valid. Anything else fails. The tool returns Valid or Invalid so you can drop the failures straight from your list.

​
What to watch for in real lists

Five patterns account for almost every syntax failure on a typical exported list.
  • Missing @ or two @s. usercompany.com, user@@example.com. Usually paste errors or a CRM column merge that went wrong.
  • Empty local part. @example.com. Frequent in bot signups and form scrapes.
  • Domain without a dot. user@localhost is fine for internal mail and broken for marketing.
  • Leading or trailing dots in the local part. .user@example.com, user.@example.com. They look harmless and they break RFC 5321 every time.
  • Consecutive dots. john..doe@example.com. The most common typo on lists exported from spreadsheets.

​
What syntax validation is not

Syntax validation tells you the string is shaped correctly. It does not tell you the mailbox exists, that the domain accepts mail, or that the address belongs to a real person. To answer those questions, chain in the related checks: Run syntax first, then layer the deeper checks onto the survivors.

​
FAQs

It checks the rules in RFC 5321 and RFC 5322. That covers presence and position of the @, length and character rules for the local part, and domain format including label lengths and at least one dot. It does not contact a mail server, so a syntactically valid address can still bounce in real life.
The usual culprits are leading or trailing dots in the local part, consecutive dots, missing top-level domain (user@localhost), or unsupported characters. Strict validators follow the unquoted-form rules word-for-word; permissive ones accept edge cases that work in practice but break the spec.
No. Syntax validation checks the format of the string. Full verification adds an MX lookup to confirm the domain accepts mail, and an SMTP handshake to ask the server whether the mailbox exists. Use syntax first to filter the obvious failures, then verify the survivors.
No. gmial.com, outlok.com, and yaho.com are all syntactically valid; they just point at domains that don’t exist. To catch them, pair this tool with an MX lookup or a typo-detection step that compares the domain against a list of known providers.
The format check is exact. If the tool says Valid, the string conforms to RFC 5321 and RFC 5322. If it says Invalid, the string fails at least one rule. Whether the address actually delivers is a separate question that needs MX and SMTP checks to answer.

​
Try it

Head to the live email syntax validator and paste an address. Results come back instantly and you can run as many checks as you need from a single page.