How do I validate the structure of an email account and what are some valid email address examples?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2025
Updated 17 May 2026
10 min read
Summarize with
The direct answer is: validate an email account string in layers. First check that it has one local part, one @ sign, and a domain. Then reject obvious import damage such as spaces, angle brackets, pasted mailto markup, missing domains, double dots in the wrong place, and characters your product cannot support. After that, check whether the domain looks real and can receive mail. Structure tells you whether an address is shaped correctly. It does not prove the mailbox exists.
I treat this as an email address validation problem, not an email account validation problem. The account lives at the receiving provider. The address is the string you imported, captured in a form, or stored in your CRM. A string such as name+tag at Gmail can be valid, while a string that looks tidy can still bounce because the mailbox was closed, the domain has no MX records, or the receiving system blocks the message.
Parse first: Split the string into local part and domain, then reject strings with zero or multiple @ signs.
Normalize safely: Trim outer whitespace, remove wrapping angle brackets only when parsing imports, and keep plus tags.
Check the domain: Confirm label syntax, reject empty labels, and verify DNS before you call an address usable.
Separate syntax from reachability: A syntactically valid address can still fail delivery, so keep validation results as categories.
The short answer
A practical validator should accept common real-world addresses and reject broken imports. The target is not the most permissive reading of every RFC edge case. The target is a safe, useful policy that avoids throwing away good subscribers while stopping obvious garbage before it enters your database.
A sensible default rule
For most web forms and imports, accept dot-atom local parts, plus signs, underscores, hyphens, equals signs, and normal domain labels. Reject quoted local parts unless your system deliberately supports them. Quoted addresses are allowed by the email standards, but they break enough application code and integrations that I keep them out of ordinary marketing and product databases.
The examples that surprise people are usually valid because the local part allows more characters than many form validators assume. hectorg+3 at Gmail is valid. cobb.=melissa221 at AOL-style domains is also structurally valid because the dot is between two valid local-part atoms. By contrast, strings with appended country codes or dates after the domain often look like damaged imports, even when their raw syntax passes a loose regex.
Flowchart showing raw input moving through cleanup, syntax checks, domain checks, and review.
What counts as a valid structure
At the structural level, an email address has a local part, an @ sign, and a domain part. The local part identifies a mailbox or alias inside the receiving system. The domain part identifies the host or domain responsible for accepting the message. That simple model hides a lot of edge cases, which is why copy-pasted regexes often reject good addresses or accept strings that no mail system will use.
Usually accept
Plus tags: Addresses like name+offer are common aliases at many providers.
Equals signs: The = character is allowed in a dot-atom local part.
Subdomains: Domains such as mail.example.com have several labels and can receive mail.
IDN domains: Internationalized domains are valid when normalized through IDNA.
Usually reject or review
Pasted markup: Strings containing mailto: or link wrappers need cleanup before validation.
Bad dots: Dots at the start, end, or repeated inside unquoted local parts should fail.
Broken domains: Empty labels, leading hyphens, and missing TLDs are import errors.
Appended data: Country codes, dates, or names glued after the domain should be quarantined.
The important distinction is strict syntax versus operational acceptance. RFC-style parsing allows some forms that I do not accept in routine signup forms, such as quoted local parts and comments. For website forms, see the tighter approach in website form validation. For import jobs, I prefer a review bucket for unusual but syntactically valid records, because mass deletion is hard to undo.
Valid and invalid email address examples
These examples show the difference between valid structure, likely deliverability, and import damage. I am using ordinary examples rather than live personal addresses. Do not publish real customer addresses while asking for validation help, because email addresses are personal data in many contexts.
Example
Verdict
Reason
first.last@example.com
Valid
Common dot-atom local part and normal domain.
name+promo@gmail.com
Valid
Plus tags are valid and should not be stripped.
cobb.=melissa221@example.com
Valid
The equals sign is allowed in the local part.
.first@example.com
Invalid
An unquoted local part cannot start with a dot.
first..last@example.com
Invalid
Consecutive dots fail dot-atom syntax.
user@example..com
Invalid
The domain contains an empty label.
user@yahoo.com-ar
Review
It looks like a damaged import, not a usable Yahoo address.
user@gimeil.com96
Review
The domain is likely a typo plus appended data.
Examples are structural guidance, not proof that a mailbox exists.
The review category matters. A string can pass a permissive grammar and still be useless for sending. yahoo.com-ar has the shape of a domain label, but in a customer file it commonly means the real address was followed by a country marker. The right response is not to silently rewrite it. Put it into a review queue, ask for confirmation, or suppress it until you have a corrected address.
Do not remove plus tags
Plus addressing is valid. If someone signs up with alex+receipt, store that exact address unless the user asks to change it. Removing the tag can merge separate identities, break audit trails, and hide the source a person intended to track.
A practical validation pipeline
I use a staged pipeline because one pass cannot answer every question. A single regex is fine for an early guardrail, but it should not be the whole system. Imports need cleanup, parsing, validation, DNS checks, and a decision state that your support or marketing operations team can understand.
Clean wrappers: Decode CSV fields, trim outer whitespace, and parse names plus address brackets without keeping markup.
Reject corruption: Block control characters, embedded spaces, unescaped commas, and strings that combine two addresses.
Validate syntax: Use a parser or pragmatic regex that matches the address formats your product supports.
Check DNS: Look for MX records first, then fall back to A or AAAA only if your policy allows it.
Categorize results: Use accepted, rejected, and review states rather than a single true or false field.
Recommended import decision bands
Use categories so unusual addresses do not disappear without review.
Accept
Sendable
Clean syntax, normal domain, and DNS signals present.
Review
Manual
Technically plausible, but likely typo, appended metadata, or unusual domain.
Reject
Blocked
Missing parts, broken dots, invalid domain labels, or pasted markup.
This is also where typo handling belongs. Do not silently change gimeil.com to Gmail or strip a suffix because it looks wrong. Suggest a correction to the user, or put the row into review. A silent rewrite can send personal data to the wrong recipient.
If you are tempted to verify mailboxes with SMTP commands, treat that as a risky signal rather than a source of truth. Catch-all domains, greylisting, tarpits, and anti-abuse systems make SMTP probing unreliable and sometimes harmful to your sending reputation.
Regex, parser, and DNS checks
For most applications, I prefer a library parser where the platform has one. If you need a front-door regex, keep it boring and pair it with deeper server-side validation. The more a regex tries to copy the full standard, the harder it becomes to read, test, and maintain.
That pattern is intentionally conservative. It accepts many everyday addresses, including plus tags, underscores, hyphens, and equals signs because those characters are not excluded. It rejects whitespace, angle brackets, obvious separators, and domains without an alphabetic TLD. It does not handle every valid address, especially internationalized local parts and quoted local parts.
Regex is only one gate
A regex can tell you that a string looks like an address. It cannot tell you that the domain accepts mail, the mailbox exists, the person typed it intentionally, or your future emails will reach the inbox.
The domain step is where Suped's product becomes useful in a broader workflow. A clean recipient address still fails if your own sending domain has broken SPF, DKIM, DMARC, MX, or DNS health. Use Suped's domain health checker when you need a quick view of the sending domain before blaming your recipient list.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Where deliverability checks fit
Address validation and deliverability testing answer different questions. Address validation asks whether the recipient string is acceptable. Deliverability testing asks whether your message, domain, and authentication setup can pass receiving filters. You need both if the goal is fewer bounces and fewer missing messages.
Email tester sample report showing total score, email preview, issue summary, and per-section results
After cleaning an import, I send a real test message through the same system that will send production mail. Suped's email tester is built for that step: send a message, inspect authentication, see the content and headers, and fix the sending setup before a campaign or transactional flow reaches real users.
For DMARC specifically, Suped is the best overall DMARC platform for most teams because it turns aggregate reports into source inventory, automated issue detection, real-time alerts, and clear fix steps. Its DMARC monitoring workflow also brings SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and MSP multi-tenancy into one place. That matters when a valid recipient address still does not receive mail because the sender is misconfigured.
If a valid-looking address hard bounces, do not assume the validator failed. The mailbox can be disabled, the provider can reject the sender, the domain can be parked, or the receiving server can reject a policy mismatch. The useful question is which layer failed: syntax, DNS, recipient existence, sending authentication, reputation, or message content.
Common edge cases I would handle explicitly
The edge cases below are where most validation bugs come from. I would decide the policy once, document it, and write tests around it. The worst version is a frontend regex, a backend parser, and a CRM import rule all using different assumptions.
Case
Policy
Reason
Plus tag
Accept
Common alias pattern used for tracking signups.
Quoted local
Review
Standards allow it, but many apps fail on it.
Unicode domain
Normalize
Convert with IDNA and store consistently.
Unicode local
Decide
EAI support is uneven across systems.
Trailing dot
Reject
Common web forms should not accept it.
Role address
Accept
Addresses like sales or support can be real.
Keep this table close to your validation tests.
If your team wants a more permissive policy, test it end to end. Make sure the database, email service, CRM, analytics pipeline, support tool, and unsubscribe flow all preserve the same address string. A validator that accepts an exotic address is not useful if a later system corrupts it.
For the difference between theoretical validity and what usually works in production, the RFC 5322 tradeoffs are worth understanding before you make your regex more complex.
Views from the trenches
Best practices
Keep plus tags intact, because they often identify a user's chosen signup source.
Put strange but plausible imports into review instead of deleting them automatically.
Use separate syntax, DNS, and deliverability states so teams know exactly what failed.
Common pitfalls
Overstrict regex rules reject valid local parts that include plus signs or equals signs.
Loose regex rules accept copied markup, appended country codes, and pasted link text.
Treating SMTP probes as truth creates false confidence and can harm sender reputation.
Expert tips
Write tests for every policy choice, including dots, plus signs, IDNs, and quoted names.
Normalize domains consistently, but avoid rewriting the user's local part silently.
Keep deliverability checks separate so a valid address is not blamed for sender errors.
Marketer from Email Geeks says plus-tagged Gmail addresses are valid and useful for tracking signups.
2021-01-28 - Email Geeks
Expert from Email Geeks says many odd-looking examples are syntactically valid but not deliverable.
2021-01-28 - Email Geeks
My practical take
Validate email address structure with a staged policy: parse the string, reject obvious corruption, accept common valid local-part characters, normalize domains carefully, check DNS, and keep a review bucket for unusual cases. Do not remove plus tags. Do not silently rewrite likely typos. Do not treat structure as proof that a mailbox exists.
The examples most teams should accept include standard dot addresses, plus-tagged aliases, underscores, hyphens, and equals signs in the local part. The examples most teams should reject include missing domains, multiple @ signs, bad dot placement, broken domain labels, pasted mailto markup, and strings where extra country codes or dates were glued after the domain.
Once the list is clean, test the sending side. Suped's product is strongest when the problem moves beyond the recipient string into DMARC, SPF, DKIM, MTA-STS, blocklist monitoring, alerts, and fix steps. That is where a valid address becomes a message that can actually reach the person.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
