Top email Questions

List of Tags

Over the years I have slowly developed a regular expression that validates MOST email addresses correctly, assuming they don't use an IP address as the server part. Currently the expression is:


I use this in several PHP programs, and it works most of the time. However, from time to time I get contacted by someone that is having trouble with a site that uses it, and I end up having to make some adjustment (most recently I realized that I wasn't allowing 4-character TLDs).

What's the best regular expression you have or have seen for validating emails?

I've seen several solutions that use functions that use several shorter expressions, but I'd rather have one long complex expression in a simple function instead of several short expression in a more complex function.

Answered By: bortzmeyer ( 499)

There is no simple regular expression for this problem: see this fully RFC‑822–compliant regex, which is anything but simple. (It was written before the days of grammatical patterns.) The grammar specified in RFC 5322 is too complicated for primitive regular expressions, although the more sophisticated grammatical patterns in Perl, PCRE, and PHP can all manage to correctly parse RFC 5322 without a hitch. Python and C should also be able to manage it, but they use a different syntax from those first three.

However, if you are forced to use one of the many less powerful pattern-matching languages, then it’s best to use a real parser. But understand that validating it per the RFC tells you absolutely nothing about whether the person entering the address is its true owner. People sign others up to mailing lists this way all the time. Fixing that requires a fancier kind of validation that involves sending that address a message that includes a confirmation token meant to be entered in the same web page as was the address.

That’s the only way to know you got the address of the person entering it, which is why most mailing lists now use that mechanism to confirm sign-ups. After all, anybody can put down, and that will even parse as legal, but it isn’t likely to be the person at the other end.

For PHP, you should not use the pattern given in Validate an E-Mail Address with PHP, the Right Way from which I quote "There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard." That is no better than all the other non-RFC patterns. It isn’t even smart enough to handle even RFC 822, let alone RFC 5322. This one, however, is.

If you want to get fancy and pedantic, implement a complete state engine. A regular expression can only act as a rudimentary filter. The problem with regular expressions is that telling someone that their perfectly valid e-mail address is invalid (a false positive) because your regular expression can't handle it is just rude and impolite from the user's perspective. A state engine for the purpose can both validate and even correct e-mail addresses that would otherwise be considered invalid as it disassembles the e-mail address according to each RFC. This allows for a potentially more pleasing experience, "The specified e-mail address 'myemail@address,com' is invalid. Did you mean ''?"

See also Validating Email Addresses, including the comments. Or [Comparing E-mail Address Validating Regular Expressions][5].

How can an email address be validated in Javascript?

Though this solution may be simple, I'm sure this is one of those useful things that people will be Googling for and deserves its own entry on the site

Answered By: sectrean ( 475)

Using Regular Expressions is probably the best way. Here's an example (live demo):

function validateEmail(email) { 
    var re = /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\
    return re.test(email);

But keep in mind that one should not rely only upon JavaScript validation. JavaScript can easily be disabled. This should be validated on the server side as well.

Mike Wills

Instead of relying on my host to send email, I was thinking of sending the messages though my Gmail account. The emails are personalized emails to the bands I play on my show. Is it possible to do?

Answered By: Domenic ( 350)

Be sure to use System.Net.Mail, not the deprecated System.Web.Mail. Doing SSL with System.Web.Mail is a gross mess of hacky extensions.

using System.Net;
using System.Net.Mail;

var fromAddress = new MailAddress("", "From Name");
var toAddress = new MailAddress("", "To Name");
const string fromPassword = "fromPassword";
const string subject = "Subject";
const string body = "Body";

var smtp = new SmtpClient
               Host = "",
               Port = 587,
               EnableSsl = true,
               DeliveryMethod = SmtpDeliveryMethod.Network,
               UseDefaultCredentials = false,
               Credentials = new NetworkCredential(fromAddress.Address, fromPassword)
using (var message = new MailMessage(fromAddress, toAddress)
                         Subject = subject,
                         Body = body
Leon Bambrick

This is a tricky one and I've always relied on techniques, such as permission-based emails (i.e. only sending to people you have permission to send to) and not using blatantly spamish terminology.

Of late, some of the emails I send out programmatically have started being shuffled into people's spam folder automatically and I'm wondering what I can do about it.

This is despite the fact that these particular emails are not ones that humans would mark as spam, specifically, they are emails that contain license keys that people have paid good money for, so I don't think they're going to consider them spam

I figure this is a big topic in which I am essentially an ignorant simpleton.

Answered By: Michiel de Mare ( 180)

Use email authentication methods, such as SPF, and DKIM to prove that your emails and your domain name belong together, and to prevent spoofing of your domain name. The SPF website includes a wizard to generate the DNS information for your site.

Check your reverse DNS to make sure the IP address of your mail server points to the domain name that you use for sending mail.

Make sure that the IP-address that you're using is not on a blacklist

Make sure that the reply-to address is a valid, existing address.

Use the full, real name of the addressee in the To field, not just the email-address (e.g. "John Smith" <> ).

Monitor your abuse accounts, such as and That means - make sure that these accounts exist, read what's sent to them, and act on complaints.

Finally, make it really easy to unsubscribe. Otherwise, your users will unsubscribe by pressing the spam button, and that will affect your reputation.

That said, getting Hotmail to accept your emails remains a black art.


What is the maximum length of a valid email address? Is it defined by any standard?

Answered By: Dominic Sayers ( 239)

[UPDATED] The correct answer of 254 has now been accepted by the IETF following the erratum I submitted here.

You can get a full diagnosis of any given address here.

The original version of RFC 3696 did indeed say 320 was the maximum length, but John Klensin subsequently accepted this was WRONG.

The maximum length is specified in RFC 5321: "The maximum total length of a reverse-path or forward-path is 256 characters"

RFC 3696 was corrected here

I note for the record that John Klensin may actually be wrong in his correction: a Path is defined as

Path = "<" [ A-d-l ":" ] Mailbox ">"

So the Mailbox element (i.e. the email address) has angle brackets around it to form a Path, so the Mailbox must be no more than 254 characters to keep the path under 256.

I've now collated test cases from Cal Henderson, Dave Child, Phil Haack, Doug Lovell and RFC 3696. 158 test addresses in all.

I ran all these tests against all the validators I could find. The comparison is here:

I'll try to keep this page up-to-date as people enhance their validators. Thanks to Cal, Dave and Phil for their help and co-operation in compiling these tests and constructive criticism of my own validator.

People should be aware of the errata against RFC 3696 in particular. Three of the canonical examples are in fact invalid addresses.