Global Email Update: Syntax Validation

Ensuring proper email syntax is a crucial step in validating an email address. At Melissa, we strive not only to provide the most accurate logic for validating syntax, but to perform corrections to some of the most common mistakes, turning otherwise invalid email addresses into perfectly usable ones.

We at Melissa are continually improving our logic based on widely accepted RFC (Request for Comments) documents published by the IETF (Internet Engineering Task Force) - the closest thing we have to an authority on Internet protocols. As discussed there, with the sheer number of email domains in use, it’s important to consider some of the variations you may encounter from one domain to another. For this reason, it’s important we consider those variations, such as the use of special characters or quoted mailboxes.

Here’s an overview of some improvements we’ve made with our most recent update.

Character Escaping

Most people have probably never seen a space character or a double-quote in an email address. This is a fringe case, but you wouldn’t want to dispose of a perfectly valid email if you encountered it. Melissa supports this functionality while also giving you the control to disable it if it doesn’t fit your needs.

For example, this could be perfectly valid syntax, depending on the mail server:

• “test email”@example.com

Normally, without the quoted mailbox, we’d strip the whitespace as a likely typo:

• test email@example.com → testemail@example.com
  

We understand that might not be something you want, even if it is technically correct. Just set the new option, AllowQuotes, to OFF to strip out quotes and special characters from quoted mailboxes instead.

Extra Characters

On to some of the typos we can fix… ever hit the period key twice? It’s an easy mistake to make and would be an unfortunate reason to lose a good email. Likewise, adding those characters to the beginning or end of a mailbox is probably unintentional, and definitely invalid.

Let’s look at a couple of straightforward corrections:

• test..email@example.com → test.email@example.com
• .testemail@@example.com → testemail@example.com

Special Characters

For a number of good reasons on the programmability and readability standpoint, some special characters are viewed as particularly bad practice and aren’t considered valid as part of a mailbox or a domain name. We’ve always stripped these characters from the mailbox, but we’ve enhanced our ruleset and buckled down on the domain part as well. Valid domain names are much more restrictive and shouldn’t generally include items other than dashes or dots.

For instance:

• test[email@example.com → testemail@example.com
• testemail@example,com → testemail@example.com

How Will These Changes Impact My Service?

Most likely, you’ll see a higher validation rate and a better rate of deliverable email addresses. In addition, we’re giving you even more information to make informed business decisions.

Look out for these result codes:

• ES10: Syntax Changed - you’ll see this code in the results any time we make corrections to your emails.
• ES31: Suspicious Characters (new) - you’ll see this code in the results when your email addresses have some unusual characters, like brackets or semicolons (we’ll probably strip those out - unless they’re in a quoted mailbox).

Syntax validation and correction can make all the difference for malformed or even suspicious emails. Even valid emails can raise suspicion - odd symbols or characters can be hints that a mailbox might be auto-generated or not from a real person.

At Melissa, we’re always looking for ways to improve our services and stay current with the ever-evolving landscape of the Internet. Take advantage to keep your emails clean and protect your web reputation with our Global Email Web Service.