Be smart about “dummy” email addresses

Sanford Whiteman -

Sometimes you need a valid-looking email address as a placeholder, but you must be sure that it truly doesn't exist — so you don't send, or even attempt to send, unwanted email — and that it's unique across your whole database.

For example, a lead's Email Address can be blank or have a basic syntax error (username missing @domain, only a domain with no username, etc.) in Marketo itself, but validation errors can stop the lead from syncing to your CRM. Not so good, since those are the very leads Sales needs to track down using other info.

But what value can you fill in that simultaneously…

  • [a] is unique,
  • [b] uses valid address syntax, yet
  • [c] is immediately fake-looking to the naked eye, and
  • [d] per technical rules, can't ever be a real-world mailbox?

Marketo user JA asked a related question on the Community. Her door-to-door reps carry tablets with a Marketo LP and form for leads to fill out, but the Email field is not required. (This is a deliberate choice to smooth conversion: assume a direct mail campaign follows.)

In order to create a unique dummy email when a value isn't present, you can use the following Forms 2.0 API code:

MktoForms2.whenReady(function(form){   
  form.onSubmit(function(form){  
    form.getValues().Email || form.setValues({   
      Email : 'Unknown-' + 
              new Date().getTime() + 
              Math.random().toString().substring(2)  
    });   
  });  
});

This will generate a new value each time, like Unknown-14886205862763624906795830931 or Unknown-14886206420675276376347497573. Note the value must be unique (not just nonexistent) in this scenario because the form will be filled out by lots of leads and we don't want them all merged into the same lead in Marketo!

So this works on the Marketo side, but JA pointed out that the generated value (which doesn't have a domain part) won't sync to SFDC. Here's where things got interesting.

Her touchup was to change the random email to

      Email : 'Unknown-' + 
              new Date().getTime() + 
              Math.random().toString().substring(2) +
              '@noemail.com'

So values are then like Unknown-14886205862763624906795830931@noemail.com.

But my SMTP & DNS senses got to tinglin'. From my days as a sysadmin, I remembered the regrettable error of using the so-called “dummy” TLD .local for corporate networks. We'd choose teknkl.local for internal nets, thinking there's no way they could be confused for a public server (and so we'd avoid the security and uptime catastrophe of using “somebody else's domain”).

We were wrong: it may have sounded internal-ish, but .local wasn't a special domain. Nothing stopped .local from becoming a TLD sold at GoDaddy or Dotster (think http://your-gourmet-grocery.local) and breaking thousands of networks overnight.

(Luckily, no one tried to operate a .local registry before ICANN, aware of the potential disaster, proactively marked it reserved so it couldn't be a public suffix in the future. But it could've happened, as it could happen to any domain that's currently not in use but isn't specifically reserved.)

So back to the noemail.com domain. We know the .com TLD exists, of course, and sure enough noemail.com exists, too! It's registered to an ad company, and these are some of its public servers for receiving mail:

  noemail.com.            914     IN      MX      0 mail.b-io.co.  
  mail.b-io.co.           188     IN      A       198.133.159.136  
  mail.b-io.co.           188     IN      A       198.133.159.123  
  mail.b-io.co.           188     IN      A       198.133.159.119

So this is definitely not a “dummy” domain: it's a real production domain. Sure, 4789105458120111@noemail.com may be unlikely to have an inbox (although if there's a wildcard inbox for all usernames, it could) but even without a deliverable inbox you can still send mail to it, since its MX is ready and waiting. And if they report you to a blacklist for barraging them with bad addresses… you get the idea.

The Official dummy domains

It may surprise you to learn that the IETF (the internet standards body, if you don't know) has already been there, done that. There's an official standard that dictates three TLDs, and one special 2LD, designated for special use.

RFC 6761 lists these domains, each with a specific (and guaranteed never to change) purpose:

  • .test for testing scenarios
  • example.* for illustrating examples in documents (that's why I almost always use example.com when I post sample code)
  • .localhost to refer to the local machine (don't worry if this doesn't make sense)

and (drum roll)

  • .invalid for names that are expressly defined as nonexistent!

So the only domain that is guaranteed appropriate for dummy addresses — addresses that self-describe as not-real, never-real addresses — is one that ends with .invalid, like 4789105458120111@noemail.invalid.

So to update the code to generate unique dummy addresses, you want:

      Email : 'Unknown-' + 
              new Date().getTime() + 
              Math.random().toString().substring(2) +
              '@noemail.invalid'

Learn something today? :)

Addendum: What if you do send to <username@noemail.invalid>?

It's best to keep .invalid addresses out of your Smart Lists, but don't worry: emails to these addresses will never leave Marketo. The RFC guarantees that they will never have an MX or A record to accept mail, so no connection will be attempted.