Email Address Format: Valid Syntax Rules, Examples & Provider Limits

A valid email address follows the structure local-part@domain.tld, for example, jane.doe@company.com. The local part (before the @) can be up to 64 characters, the domain up to 255 characters, and the full address up to 320 characters combined, per RFC 5322. But the spec and real inbox providers don’t fully agree: Gmail, Outlook, and Yahoo each enforce their own, stricter rules on top of it, which is where most confusion about “what’s actually valid” comes from Getting this wrong is one of the most preventable causes of bounces in any email marketing campaign.

Components of an Email Address

Every standard email address has four parts:

• Local part (username) — identifies a specific mailbox on the domain, e.g. jane.doe
• @ symbol — separates the local part from the domain
• Domain — the organization or provider that owns the mail server, e.g. company
• Top-level domain (TLD) — the suffix that categorizes the domain, e.g. .com, .org, .io

Some addresses also include a subdomain, sitting between the @ symbol and the domain: jane.doe@mail.company.com.

When you send an email, the sending server looks up the domain’s MX record, connects to that mail server, and asks whether the local part is a recognized mailbox. This is the exact failure point that quietly damages email marketing campaigns — not spam filters or content, just a malformed address that never had a chance to arrive

If the format is wrong at any stage, the message bounces before it ever reaches an inbox, terminology like MX record and local part is covered in more depth across Gamalogic’s email validation glossary.

RFC-Valid vs. Provider-Valid

This is the part most guides on this topic skip, and it’s the source of almost all the confusion. RFC 5322 — the technical standard defining email syntax — is genuinely permissive. It allows quoted local parts like "john..smith"@example.com, where consecutive periods (normally forbidden) become legal once wrapped in quotes, along with a wider range of special characters than most people have ever seen in a real address.

Real inbox providers don’t implement the full RFC. Gmail, Outlook, and Yahoo each layer their own, stricter rules on top of the spec, mainly to reduce parsing errors, spoofing, and abuse. So an address can be fully RFC-valid and still get rejected by Gmail’s signup form.

The practical takeaway: “is this address in valid format” has two different correct answers depending on whether you mean valid per the internet standard, or valid on the specific provider it’s registered with. Most validation tools only check the first one — which is part of why claimed accuracy numbers vary so much between vendors; see how we define and measure ours in our accuracy methodology.

Local Part (Username) Rules

The local part can contain:

• Uppercase and lowercase letters (A–Z, a–z)
• Digits (0–9)
• The special characters . _ - + in most standard, non-quoted implementations
• A period, as long as it’s not the first or last character, and never two in a row unless the whole local part is quoted

Length limit: 64 characters, per RFC 5322 section 4.5.3.1.1.

Casing and periods barely matter in practice. Most major providers treat the local part as case-insensitive, and Gmail specifically ignores periods entirely — john.doe@gmail.com and johndoe@gmail.com reach the same inbox. That’s a Gmail-specific routing quirk, not a universal rule.

One local-part pattern worth flagging separately: generic addresses like info@, support@, or sales@ are structurally valid but behave differently for outreach and marketing purposes than a named individual’s address — see our breakdown of role-based email addresses for why that distinction matters.

Domain Rules

The domain can contain:

• Letters and digits
• Hyphens, never as the first or last character
• Periods, to separate subdomains

Length limit: 255 characters, giving a combined maximum of 320 characters for the full address.

A domain also needs a valid MX record, the DNS entry telling other mail servers where to deliver mail for it. A syntactically perfect domain with no MX record can’t receive anything at all. It’s also worth noting that a domain can be perfectly valid in format and still be a problem address in practice disposable and temporary email domains pass every syntax and MX check while still being throwaway addresses nobody checks twice.

How Gmail, Outlook, Yahoo, and Zoho Rules Actually Differ

[Insert real Gmail + Outlook signup-error screenshots here, see note in the meta block above]

(These reflect each provider’s signup-form restrictions specifically, a mail server may still accept and deliver to addresses with characters it wouldn’t let you register at signup.)

If you’re validating a list of unknown addresses, you can’t assume one provider’s rules apply to all of them. An address that looks “wrong” by Gmail’s standards might be completely normal on Zoho or a custom company domain.

Internationalized Email Addresses

Almost every other guide on this topic treats email addresses as ASCII-only. That stopped being fully accurate over a decade ago.

RFC 6531 (SMTPUTF8) is an SMTP extension, published in 2012, allowing non-ASCII characters accented letters, Cyrillic, Chinese, Arabic script, directly in the local part of an email address. Support for it varies by mail server and client, which is why it hasn’t fully replaced ASCII addresses, but it’s a real, standards-track part of modern email, not a theoretical edge case.

Internationalized domain names work differently: since most of the DNS system still runs on ASCII, a domain containing non-Latin characters gets converted to a special ASCII form called Punycode, always prefixed with xn--. A domain like münchen.de transmits as xn--mnchen-3ya.de behind the scenes mail clients typically handle this conversion automatically.

For most B2B and marketing use cases, ASCII addresses still dominate, but if you operate internationally, it’s worth knowing whether your validation tool actually supports SMTPUTF8 rather than silently rejecting every non-ASCII address as invalid.

Common Email Typo Domains

A meaningful share of “invalid format” addresses aren’t random garbage they’re one-keystroke typos of a handful of major domains.

A syntax-only validator will pass jane@gmial.com — it’s a structurally fine-looking domain, it just doesn’t exist as the one the person meant. Catching this class of error takes either a live MX/domain check or a typo-suggestion feature, not syntax rules alone. It’s also worth knowing that a domain reactivated specifically to catch senders with bad list hygiene — a spam trap — can look exactly like a normal, syntactically valid address, which is a separate risk from a simple typo.

Valid vs. Invalid Examples

Key Terms Reference Table

How to Check Email Format at Scale

Manually checking a list against these rules works for a handful of addresses. It doesn’t work for a a real email marketing list of 10,000 contacts, and it won’t catch typo-domains, missing MX records, or provider-specific quirks all of which look structurally valid while still failing to deliver.

Gamalogic’s email validation API checks syntax, MX records, and disposable-domain status in the same real-time or bulk request, so a malformed address, a typo-domain, and a dead domain are all caught in one pass instead of needing separate manual checks.

If you’re building a list by guessing likely addresses from a name and company domain rather than validating an existing one, the API runs the same checks programmatically against bulk lookups too useful context on that specific workflow is in our FAQ below.

FAQ

What is the correct format for an email address? local-part@domain.tld — for example, jane.doe@company.com. The local part identifies the mailbox, the domain identifies the mail server, and the TLD categorizes the domain.

Can an email address contain special characters? Yes, but which ones depends on the provider. Periods, hyphens, underscores, and plus signs are common, but Gmail specifically disallows hyphens and underscores at signup, while other providers allow them.

Why does my email address work on one site but get rejected on another? Different websites implement different validation rules — some check only against the RFC spec, others add their own stricter rules. This is a site-side validation choice, not a property of your address being wrong.

Can an email address have Unicode or non-English characters? Yes, since RFC 6531 (2012) added SMTPUTF8 support for non-ASCII characters in the local part. Support varies by mail server, so an internationalized address may not work everywhere, but it’s a legitimate, standards-track format.

What’s the maximum length of an email address? 320 characters total (64 for the local part, 1 for the @ symbol, 255 for the domain), though 256 characters is the safer practical limit due to separate constraints on the mail-forwarding path.

Does capitalization matter in an email address? Generally no for the domain, and usually no for the local part on major providers, though the RFC technically allows the local part to be treated as case-sensitive — almost no provider enforces this in practice.

If I’m guessing someone’s email address rather than validating one I already have, does format still matter? Yes — a guessed address still has to be format-valid before it’s worth verifying at all. Our guide on how people actually find email addresses covers the common local-part patterns (first.last@, flast@, etc.) companies actually use, which is the practical starting point before you check format or run verification.

Conclusion

A valid email address follows one simple structure: local-part@domain.tld. But “valid” isn’t a single fixed rule. RFC 5322 sets the technical baseline, and Gmail, Outlook, Yahoo, and Zoho each add their own stricter rules on top of it — same address, different verdicts depending on where it’s checked.

Format is also only half the picture. A typo’d domain, a dead mailbox, or a missing MX record can all look perfectly valid and still fail to deliver and still fail to deliver, quietly dragging down every email marketing campaign sent to that list.

For one address, checking by eye works fine. For a real list, it doesn’t scale which is why validation exists as its own step, not a formatting afterthought.

Run a list through Gamalogic’s email validation API to catch format errors, typo-domains, and dead mailboxes in one pass, 500 free credits, no card required, to test it on your own list first.