Glossary

What Is Email Address Syntax?

The format rules an address must pass before any server is asked about it, and what a syntax pass does not prove.

Get your free API key →Free to start. No credit card. 1,000 records to spend whenever you like.

Email address syntax is the set of format rules an address must follow to be valid: a local part, an @ sign and a domain, in that order.

The format is defined in RFC 5322 (September 2026), which calls it an addr-spec. The transport limits come from RFC 5321 (September 2026). Section 4.5.3.1 caps the local part at 64 octets and the domain at 255.

Why it matters for outbound

A syntax check is the cheapest filter in a verification pipeline. It runs offline, costs nothing and removes typos such as a missing @ or a space in the domain.

It is also the weakest filter. An address can be perfectly formed and still bounce, because nobody owns it. Syntax tells you the string could be an address. It does not tell you a mailbox exists.

Run the syntax check first, then DNS, then the SMTP check. Skipping the first step wastes the paid steps on strings that were never addresses.

Example

Three placeholder addresses and what a syntax check says about each:

code
jane.doe@acme.com     passes
jane.doe@acme         fails: the domain has no suffix such as .com
jane doe@acme.com     fails: an unquoted space is not allowed in the local part

The second case is a judgment call. RFC 5322 allows a bare hostname, but nothing on the public internet accepts mail for one, so most verifiers reject it.

Real-world checks are stricter than the RFC. The RFC permits quoted strings and comments in the local part, and almost no sales data contains them. A practical rule set is letters, digits and a few symbols before the @, then a domain with at least one dot and a valid suffix.

The whole address is usually capped at 254 characters, because RFC 5321 limits a path to 256 octets including the angle brackets. Two dots in a row, a leading dot and a missing local part are all syntax failures. Upper and lower case are treated alike by almost every provider, though the RFC lets the local part be case-sensitive.

In LeadOcean data

LeadOcean has no standalone syntax field. The outcome of all checks sits in email_status on each search row, and in the status of each address in an enriched record. You filter on it with emailStatus on /v1/people/search. The values are verified, catch_all_valid, catch_all, risky, unknown, untested, invalid, role, disposable, spam_trap, abuse, derived and none (openapi.json, September 2026).

A malformed string cannot be verified, so it cannot reach the verified status. Read email_status before you send. LeadOcean gives no refund or credit for bounced emails.

The count_leads MCP tool counts verified, catch_all_valid and catch_all people by default, and it is free. Pricing is on /pricing. More terms sit in the glossary.

Start with emails that already passed the checks

Free to start. No credit card. 1,000 records to spend whenever you like.

Get your free API key →