Valid email address format guidelines and examples

Valid Email Address Format: The Practical Rules

A valid email address has two main parts: the local part before the @ symbol and the domain after it.

local-part@example.com

The local part identifies the mailbox. The domain tells mail servers where that mailbox is hosted. If either side is malformed, the message can bounce before it ever reaches a real inbox.

Email syntax can get surprisingly technical, but most business and marketing teams do not need to memorize every edge case. You need reliable rules that work for signup forms, CRM imports, cold outreach lists, newsletters, and internal data cleanup.

The Local Part

The local part sits before the @ symbol:

maya.chen@example.com

In this address, maya.chen is the local part.

Commonly accepted characters include:

• Letters: a-z
• Numbers: 0-9
• Periods: .
• Hyphens: -
• Underscores: _
• Plus signs: +

The local part should not start or end with a period, and it should not contain consecutive periods. Spaces are not valid in normal email addresses. Quoted local parts can technically allow more unusual characters, but they create compatibility problems and should not be used in marketing or product databases.

Good local-part examples:

• maya
• maya.chen
• maya_chen
• maya+newsletter
• sales-team

Risky or invalid examples:

• .maya
• maya.
• maya..chen
• maya chen
• maya@chen

The Domain Part

The domain sits after the @ symbol:

maya.chen@example.com

In this address, example.com is the domain.

A domain must be real and able to receive email. A syntactically valid address like person@example.invalid is still not useful if the domain has no DNS records or mail servers.

A practical domain checklist:

• It contains at least one period.
• It does not contain spaces.
• Each label uses letters, numbers, or hyphens.
• It does not start or end with a hyphen.
• It has a valid top-level domain such as .com, .org, .io, or a country-code TLD.
• It has MX records, or at least a valid fallback mail host.

Valid-looking domains:

• example.com
• mail.example.org
• company.co.uk

Invalid or suspicious domains:

• example
• example..com
• -example.com
• example-.com
• example .com

Valid Email Address Examples

These are normal, practical email formats:

• alex@example.com
• alex.smith@example.com
• alex-smith@example.com
• alex_smith@example.com
• alex+events@example.com
• sales@example.co.uk
• support@mail.example.com

These should be rejected or reviewed:

• alexexample.com - missing @
• alex@@example.com - two @ symbols
• alex @example.com - space before @
• alex@example - incomplete domain
• alex@example..com - consecutive periods
• alex@.example.com - domain starts with a period
• alex@example.com. - trailing period

Format Validation vs. Email Verification

Format validation only answers one question: does this look like an email address?

That is useful, but it is not enough. A perfectly formatted address can still bounce. For example:

this-address-does-not-exist@gmail.com

The syntax is fine, but the mailbox may not exist.

Full email verification checks more than format:

• Syntax validation
• DNS lookup
• MX record detection
• SMTP mailbox probing
• Disposable-domain detection
• Role-based address detection
• Catch-all classification

If you are collecting emails for a newsletter, sales campaign, waitlist, webinar, or customer account, format validation should happen at signup and full verification should happen before high-volume sending.

Common Data-Entry Mistakes

Most invalid addresses come from ordinary mistakes:

• gmail.con instead of gmail.com
• gmal.com instead of gmail.com
• Missing @
• Copying a trailing comma from a spreadsheet
• Leaving a leading or trailing space
• Using a phone number or name in the email field
• Exporting CRM records with hidden characters

These mistakes are easy to miss manually, especially in large CSV files. A verifier catches them before they damage sender reputation.

Best Practices for Forms and Imports

For signup forms, validate the format immediately and show a clear correction message. Do not block useful characters such as +, _, or -; many legitimate addresses use them.

For CSV imports, normalize before verification:

1. Trim whitespace.
2. Lowercase the domain.
3. Remove duplicate addresses.
4. Reject rows with no @.
5. Verify the cleaned list before sending.

For business databases, store verification status with the contact record. A simple status field such as valid, invalid, accept_all, role_based, or unknown helps your team segment safely.

Role-Based and Shared Addresses

Some addresses are valid but still risky for outreach. A role-based address represents a function or team instead of one person:

• info@example.com
• sales@example.com
• support@example.com
• admin@example.com
• billing@example.com

These can receive mail, but they often have lower reply rates and higher complaint risk in cold outreach. For customer support, billing, or account management, they may be perfectly appropriate. For personalized sales campaigns, they should usually be segmented or reviewed.

Verification should not automatically delete every role-based address. It should label them so your campaign strategy can decide. A newsletter for existing customers may keep them. A cold sequence to decision-makers may suppress them.

Disposable and Temporary Addresses

A disposable email address can pass basic format checks and even receive mail for a short period. That does not make it good data. Temporary inboxes are commonly used to claim downloads, trials, coupons, or gated content without giving a long-term contact address.

Examples of risk signals include:

• Domains associated with temporary inbox services
• Addresses created only for one signup
• No history of engagement
• Low likelihood of future replies

If you collect leads, disposable detection is worth enabling. It keeps short-lived addresses from entering your CRM and prevents campaign metrics from being polluted by people who never intended to receive follow-up.

International Email Addresses

Modern email can support internationalized domain names and, in some systems, non-ASCII characters in the local part. In practice, support varies across mail clients, CRMs, and marketing platforms. If your audience is global, your validation rules should not be so strict that they reject legitimate regional domains.

The safe approach is to avoid homemade regular expressions that only understand a narrow set of addresses. Use a validation library or verification service that understands current email syntax and then checks deliverability beyond syntax.

Why Regex Alone Is Not Enough

Many teams try to validate email addresses with one regular expression. A basic regex can catch missing @ symbols and spaces, but it cannot answer the questions that matter most:

• Does the domain exist?
• Does it accept mail?
• Is the mailbox real?
• Is the address disposable?
• Is the domain catch-all?
• Has the address already hard bounced?

Use lightweight format validation in the browser for user experience, then verify addresses server-side or before campaigns. That combination is far more reliable than trying to make one complex regex handle every case.

Quick Checklist

A valid, campaign-ready email address should:

• Have one @ symbol.
• Have a local part before the @.
• Have a real domain after the @.
• Avoid spaces and consecutive periods.
• Resolve to a domain with mail handling.
• Pass verification before you rely on it for sending.

Good formatting prevents obvious bounces. Verification protects the send itself. You need both if you care about deliverability, clean reporting, and sender reputation.