What this RFC defines
RFC 3696 provides practical guidance for applications that need to validate or transform email addresses, domain names, and URLs. It clarifies common misconceptions about what constitutes a valid email address, the local part rules are more permissive than most developers realise, and what is a valid domain name or URL for application-level checking.
Where you see it in practice
The notorious difficulty of email address validation in application code is partly addressed by RFC 3696. It clarifies that email local parts can contain characters that most regex-based validators reject, such as plus signs, dots at arbitrary positions, and even spaces if quoted. It also notes that full validation of an email address ultimately requires attempting delivery, no syntax check can confirm an address actually exists or accepts mail.
How it connects to other RFCs
RFC 3696 is an informational RFC that references RFC 5321 (SMTP), RFC 5322 (message format), and RFC 3986 (URI syntax). It is a practical companion to the formal syntax specifications. RFC 5321 and RFC 5322 define what is syntactically valid; RFC 3696 explains the implications for application developers implementing validation logic.
Current status
RFC 3696 is a current informational RFC, published February 2004. It is a useful reference for developers implementing email address or URL validation, though it was updated by errata that corrected several errors in the original examples. Always check the published errata before using its examples as authoritative.
Verification techniques for names
RFC 3696 is an informational document by John Klensin, published in February 2004, providing guidance on how to check and transform names used in internet applications: domain names, email addresses, and hostnames. It covers common pitfalls in each domain: what makes an email address syntactically valid per RFC 2822 (later RFC 5322), how to detect when a domain name is likely misspelled, and how to handle internationalized names properly.
Email validation guidance
The most-cited part of RFC 3696 is section 3, on checking and transforming email addresses. Klensin observes that most regex-based email validators are wrong: they reject valid addresses (quoted local parts, IP-literal domains, plus signs, uncommon TLDs) and accept invalid ones. The document recommends against attempting full syntactic validation in most contexts; instead, send a verification email and let the recipient prove they can receive at that address. This is why almost every serious signup flow includes an email confirmation step.
Domain name common errors
RFC 3696 discusses domain-name errors: leading or trailing dots, consecutive dots, invalid characters in the label, missing top-level domain, IDN homograph confusion. Applications that accept user-entered domain names should validate against these rules. IDN homograph attacks (where visually-identical Unicode characters substitute for ASCII: Latin “a” versus Cyrillic “a”) remain a real threat in 2026; browsers and mail clients apply various defenses, but validation logic should also detect them at the input stage.
RFC 3696 (February 2004), authored by John Klensin, provides Application Techniques for Checking and Transformation of Names: practical guidance on validating email addresses, domain names, and URLs. Documents what is legal vs what is safe vs what is common in real-world addresses. Foundational reference for email-validation code. Not a wire spec; a practical companion to RFC 5321 and RFC 5322 for developers who need to validate user input.
RFC 3696 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Practical guidance on validating names and addresses |
| Author | John Klensin |
| Type | Informational (application guidance) |
| Topics | Email address validation, domain name validation, URL validation, common pitfalls |
| Published | February 2004 |
Email address validation summary
| Aspect | Legal per RFC 5321 | Common practice recommendation |
|---|---|---|
| Local-part maximum length | 64 characters | Same |
| Domain maximum length | 255 characters | Same |
| Total address length | 320 characters (256 in some interpretations) | 256 for compatibility |
| Special characters in local-part | Many legal: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ | Legal but rarely used; validate but do not reject |
| Quoted local-parts | Legal: "weird name"@example.com | Rarely used; accept but warn users |
| Dots in local-part | Legal except at start/end or consecutive | Accept per spec |
| Comments | Legal: (comment)local@domain (comment) | Strip before use; rarely encountered |
Two-tier validation strategy
Common validation mistakes
user+tag@example.com). Plus addressing is legal per RFC 5321 and widely used for tagging (Gmail, ProtonMail, corporate). Rejecting these disenfranchises users who intentionally structure their addresses. Accept unless you have a specific reason not to.gmial.com, yaho.com, hotmial.com. Suggest corrections at input time. Levenshtein distance against a common-domain list catches most typos. Improves signup conversion.раyраl.com that looks like paypal.com. Validation should detect mixed-script domains at input time and warn or refuse. Complement with IDNA 2008 awareness.用户@例え.jp). Validation code hardcoded to ASCII rejects these. Modern validation should accept UTF-8 addresses; downstream code must handle SMTPUTF8 for delivery.Related standards and further reading
- RFC 7505: Null MX (definitive “does not accept mail” signal)
- RFC 8398: Internationalized email addresses in X.509
Frequently asked questions
What is the maximum length of a legal email address?
Per RFC 5321: local-part maximum 64 characters, domain maximum 255 characters. Total 320 including the @. Some implementations enforce 256 total for compatibility with older buffers. In practice, keep addresses under 256 characters total to avoid compatibility issues; users almost never need longer.
Should I reject “+” characters in email addresses?
No. Plus addressing (user+tag@example.com) is legal per RFC 5321 and widely used for tagging (Gmail plus-tagging is popular for filtering). Rejecting alienates users with valid, deliberate addresses. Accept unless there is a specific security or business reason (rare in practice).
How do I validate an email address is real?
Confirmation. Send a message with a click-through link; users who cannot receive drop out naturally. This is the most reliable validation. Syntactic checks catch obvious typos; DNS checks (MX record existence) catch non-mail domains; confirmation catches all remaining. Third-party bulk validation services also exist for pre-signup checks.
Does a valid email address require a top-level domain?
Practically yes for public Internet; not strictly by protocol. Addresses like user@localhost are legal within a private network but do not resolve on the public Internet. Public-facing validation should require at least one dot in the domain. Note: some new gTLDs are short (.co, .io, .ai); do not restrict to specific TLD lists that become outdated.
How do I detect IDN homograph attacks?
Detect mixed-script labels. If a domain contains characters from multiple Unicode scripts (Latin + Cyrillic), warn or refuse. Modern browsers implement this for displayed URLs. Mail-related validation should also check: paypal.com is all-Latin; раyраl.com is mixed Latin + Cyrillic (three Cyrillic characters). Libraries like ICU or Unicode security tools provide script detection.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
