A valid email address has exactly one @ sign, a local part before it and a domain with a proper ending after it, in the pattern local-part@domain.
So why can an address pass a format check and still bounce? Because a correctly written address isn't necessarily a working mailbox, and a website that rejects an address isn't necessarily applying the full email standard.
If you're asking what is a valid email format, the useful answer separates structure, compatibility and delivery. That distinction helps you fix genuine errors without deleting legitimate contacts from a signup form, CRM import or outreach list.
What a Valid Email Address Looks Like
An email address works a little like an addressed envelope. The local part identifies the recipient within the destination system, while the domain tells the network which destination handles the message.
The envelope analogy makes that split easier to picture.

Take alex.smith@example.com. You can separate it into recognizable pieces:
alex.smithis the local part, which the receiving system interprets as a mailbox identifier.@separates the mailbox identifier from its destination.example.comis the domain responsible for directing the message toward the receiving mail system.
The Internet Message Format standard, RFC 5322, defines this structure as addr-spec = local-part "@" domain. The standard also permits less familiar forms, including quoted local parts and domain literals, so ordinary examples don't represent every technically acceptable address.
A name isn't proof of a mailbox
The local part doesn't have to be someone's legal name. A department, shared inbox or internal identifier can occupy that position. Likewise, recognizing the domain doesn't establish that the particular mailbox exists.
Think of writing a plausible name and street address on an envelope. The writing may follow the expected structure even if the intended recipient has moved away.
Practical rule: Format validation checks how an address is written, not who owns it or whether anyone reads its messages.
For an ordinary address, ask: Is there a separating at-sign? Is there a nonempty local part before it? Is there a properly formed domain after it? Those questions establish a starting point, not permission to send.
The Rules for Each Part of an Address
Use this table as a reference for ordinary, unquoted addresses. Quoted and internationalized addresses need a validator that understands their additional syntax.
| Part | Allowed characters | Rule or limit | Example |
|---|---|---|---|
| Local part, before @ | Letters, digits, and permitted symbols such as ! # $ % & * + – / = ? ^ _ ~ and periods | Maximum 64 characters in SAP's validation guidance; no leading, trailing or consecutive periods in ordinary unquoted form | alex.smith |
| At sign, @ | The separating @ symbol | Exactly one separator, with content on both sides | alex@example.com |
| Domain, after @ | Letters, digits, hyphens and separating periods | Maximum 255 characters in the guidance cited above; ordinary public-address checks expect a dotted domain and labels without edge hyphens | example.com |
| Top-level domain, last label | Letters in ordinary examples | Must be present for the public-domain pattern; reject an all-digit ending in common checks | uk in example.co.uk |
| Whole address | The permitted components above | A 254-character practical ceiling, rather than the theoretical 320-octet calculation, follows the interoperability guidance associated with RFC 3696 | alex.smith@example.com |
Symbols follow different rules on each side
The local part has a broader character set than the domain. An underscore can appear before the at-sign, but it doesn't belong in an ordinary domain label. A hyphen can appear inside a domain label, but not at its beginning or end.
Periods also have specific jobs. In an unquoted local part, they separate groups of permitted characters; they aren't padding that can be added at either edge. In the domain, they separate labels, such as example, co and uk.
The top-level domain is the final label. For example.co.uk, that's uk, not co.uk. Don't build a validator around familiar endings alone, because recognizing an ending and checking its syntax are different tasks.
Length needs careful implementation
For ordinary ASCII addresses, character counting is straightforward. Protocol implementations also need to consider octets, meaning bytes, because a Unicode character can occupy more storage than an ASCII character.
Don't independently maximize each component and assume the combined address will work. Apply both component limits and a practical whole-address limit in your form, importer or validation library.
An address inside every format limit can still point to an unavailable destination.
For business workflows, these checks are useful before a CSV reaches the sending platform. They catch malformed input without pretending to establish mailbox availability.
Valid and Invalid Examples Side by Side
| Address | Verdict | Reason |
|---|---|---|
alex.smith@example.com |
Valid | Has the expected local part, separator and dotted domain |
alex+sales@example.com |
Valid | A plus-tag is permitted in the local part |
"user name"@example.com |
Valid under the standard, sometimes rejected by forms | Quoting permits a space within the local part |
alex.@example.com |
Invalid | Local part ends with a period |
alex..smith@example.com |
Invalid | Local part contains consecutive periods |
alex@@example.com |
Invalid | Contains an extra unquoted at-sign |
alex.example.com |
Invalid | Has no at-sign separator |
alex smith@example.com |
Invalid | Contains an unquoted space |
alex@exam_ple.com |
Invalid | Contains an underscore in a domain label |
alex@example |
Invalid for most public-facing uses | Lacks the fully qualified domain pattern expected for public delivery |
The address grammar in the RFC 5322 specification with inline errata supports both ordinary dot-separated local parts and quoted forms. That's why the quoted-space example deserves a different verdict from the unquoted-space example.
Clean passes and awkward passes
alex.smith@example.com is an uncomplicated format pass. The plus-tagged example also passes without needing an exception: the plus sign belongs to the permitted local-part character set.
The quoted example is more awkward. Its syntax is legitimate, but a form or CRM may support only ordinary unquoted addresses. That makes the address incompatible with that implementation, not automatically malformed under the standard.
If you maintain the form, give a useful explanation rather than a blanket invalid-address error. If you're entering your own address, use an alternative you control when the service cannot support the original.
Fix errors without inventing a recipient
A trailing period may be accidental punctuation from copied text. Confirm the original address before removing it. For consecutive periods, an unquoted space or an extra at-sign, ask the owner or check an authoritative listing rather than guessing.
A missing separator is especially risky to repair automatically. You can't reliably determine where the local part ends just by looking at a continuous string.
For domain errors, confirm the intended spelling and complete destination. Replacing an underscore with a hyphen or guessing a missing ending might create a different, perfectly well-formed address.
A successful repair needs confirmation, not just a green result from the same pattern checker that rejected the original.
How to Check an Address Yourself in Seven Steps
Use a basic format check first, then investigate the destination. This sequence keeps simple typing errors separate from questions that require a network lookup or the recipient's involvement.
The visual checklist summarizes the main inspection points.

Find the separator. Confirm that an ordinary address has an at-sign with text before and after it. If the input contains quotation marks or additional at-signs, send it through a standards-aware parser instead of applying a simple counting rule.
Inspect the local part. Look for unquoted spaces, unsupported characters and periods at an edge or beside another period. Trim accidental whitespace around the entire input, but don't delete characters inside the mailbox name.
Check length with your validator. Apply both the component and full-address limits supported by your sending system. For internationalized input, use a library that understands byte-based protocol limits rather than relying only on a spreadsheet's text-length function.
Read the domain ending. Confirm that the address uses a complete public-domain pattern rather than an unfinished company name. Don't assume an unfamiliar ending is invalid because you haven't encountered it before.
Inspect the domain labels. Check for spaces, underscores and hyphens at label edges. If you suspect a misspelling, suggest a correction for confirmation instead of rewriting the destination automatically.
Look up the domain's mail routing. Use a DNS lookup tool and inspect the mail-exchange, or MX, result. Missing MX records warrant further investigation, not an automatic declaration that delivery is impossible, because mail routing can sometimes fall back to address records.
Confirm the mailbox when appropriate. For a signup, send a confirmation message that asks the user to verify control. For a contact list, use a verification service and keep uncertain results separate from confirmed failures.
What you can automate
A spreadsheet pattern can flag obvious structural problems. A proper parser handles unusual syntax more reliably, while DNS and mailbox checks require additional tools.
Our guide to what email validation checks explains why those tasks shouldn't be collapsed into a single format test.
A clean preliminary result means the address parses successfully and the domain has plausible mail-routing evidence. Mailbox verification and recipient permission remain separate decisions, even when those earlier checks pass.
Unicode, Plus-Tags and Strict Rules
A validator that accepts only letters, digits and periods will reject legitimate addresses. Local parts can include punctuation such as apostrophes, hyphens and plus signs, so o'brien@example.org shouldn't fail merely because its spelling looks unfamiliar.
Internationalized addresses introduce another compatibility question. RFC 6531 extends email transport to support UTF-8 mailbox addressing through SMTPUTF8, allowing non-ASCII characters in supported systems.
That permission doesn't mean every website, CRM or sending platform can handle the address. The relevant sending and receiving infrastructure must support the required transport features.
Validity and software support are different tests
An accented mailbox name may be standards-compliant but rejected by an ASCII-only form. A CRM might store it correctly while a connected sending service fails to transmit it. Neither outcome proves that the person supplied a false address.
Test the entire path: capture, storage, export, import and sending. A successful form submission alone doesn't establish that the later systems preserve the address.
For international contacts, use these handling practices:
- Preserve the original. Keep the user-facing address intact so staff can recognize it and investigate problems.
- Create a comparison key carefully. Use a documented normalization strategy for duplicate detection without overwriting the original local part.
- Handle domains appropriately. Use IDNA/Punycode conversion where the domain-processing system requires it.
- Explain compatibility failures. Tell the user which feature isn't supported rather than discarding the address without notice.
Validator design: Distinguish malformed input from an address your particular software cannot support.
Avoid treating every unfamiliar character as a risk signal. Equally, don't accept internationalized input while assuming an ASCII-only sending pipeline will deliver it.
For a global contact database, platform compatibility deserves its own status field. That lets a team retain a legitimate contact while investigating whether its current tools can send to that address safely.
Why a Valid Format Still Bounces and What to Do
A valid format does not mean the email will arrive. A syntax checker examines the recipient string, while delivery also depends on the receiving system, the sender's configuration and the recipient's mailbox status.
An address written on an envelope is only the beginning of the delivery process.

Separate recipient checks from sender requirements
Address-level checks examine structure, domain routing and evidence that the mailbox accepts mail. They can't establish whether the recipient wants your message.
Sender-level checks concern your own sending infrastructure. Gmail's sender guidelines, effective February 1, 2024, require senders to use SPF or DKIM authentication, maintain valid forward and reverse DNS, and format messages according to RFC 5322.
DMARC alignment, complaint handling and recipient consent also belong in the sending workflow. A stricter recipient-address pattern won't correct missing authentication or make an unwanted campaign welcome.
Publicly listed addresses need particular care. At EmailScout, the addresses we show are those found in the source code of the page being visited. Their appearance there establishes where they were discovered, not whether the mailbox is current or its owner has agreed to receive marketing.
A page might still list an employee who has left, or a shared inbox intended for customer support rather than sales pitches.
This video offers an additional viewing resource.
Make list decisions from the evidence
Use explicit outcomes rather than a single valid label:
- Format passes and mailbox verification succeeds. Retain the address for an appropriate, consent-based communication workflow. Verification isn't permission.
- Format passes but routing is uncertain. Hold the address for further investigation. A missing MX record alone isn't sufficient grounds to declare every domain unreachable.
- Format fails. Correct only an error you can confirm from the original source or recipient. Otherwise, request the address again or exclude it from sending.
- Internationalized address needs support. Test it in the actual sending platform before including it in a bulk run.
- A permanent delivery failure occurs. Suppress the address and retain the failure reason so a later import doesn't reactivate it.
Track temporary failures separately from permanent ones. Understanding what email bounce rate measures helps you interpret sending results instead of blaming every failure on address formatting.
Store the original address, its discovery source, the checks performed and the latest outcome. That record lets your team improve the list without repeatedly guessing why a contact was rejected.
EmailScout is a Chrome extension that finds email addresses in the source code of pages you visit. Visit EmailScout to discover contacts, then apply format, routing and mailbox checks before adding those addresses to an appropriate outreach workflow.

























































