Email validation

[Karen_Black]

Has anyone done email / account validation using Marketo? If so, can you share examples of how it works?

[Anonymous · Accepted solution]

Could you be more specific?

Do you mean validation on the field that the entered data is an email address? Or do you mean checking that the email address is valid, form the standpoint of being able to send an email and not have it bounce?

If you mean verify, I like to use a webhook and pass the data to an api like; http://verify-email.org/register/levels.html Then based on the repsonse, flag is the email is valid or not valid with an Email Valid field. I don't believe Marketo has a built in validator that I know of. 

[Josh_Hill13]

You can use StrikeIron which uses webhooks. Seems to work well and returns various validation codes.

[Anonymous]

In the case of validation upon form submission, can't you just create the email field as a "text" type and set the mask input rule?

[Scott_Kendrick]

how do you get marketo just to validate it has the right email form, meaning

no special characters, contains an @ and ends with a dot something.  It seems like the form designer has an error message for invalid email, but you can enter in something with out the doman e.g. persona@marketo

the problem with this is when it syncs with salesforce, SFDC throws an error

[SanfordWhiteman]

Technically persona@marketo is a valid email address.  It may not be routable on the public internet, but it's valid (in fact most early email addresses had exactly this form, because they were relayed between hosts with simple names).

I agree that in the case of a marketing form it shouldn't be allowed, but this is just one of the myriad problems with thinking email validation is a simple test for "no special characters."  There is no specification (as in Internet standard/RFC) that will parallel exactly what you expect, so you have to make up a non-standard -- either less or more stringent but at the same time somewhat arbitrary -- set of validation rules.

I recommend you start by implementing my solution at the base of this post: Re: How to correct typos in email addresses? By default, this code will check if the TLD is valid.  We can go deeper with it and check to see if the domain has an MX record... which you might think would suffice, but actually you have to see if it has an A record as well.  Beyond that, of course, is actual real-time email validation by attempting to connect to the remote server.  But those services cost $$.

[Elliott_Lowe1]

The odd thing is that while Marketo's form will allow an email address like persona@marketo, their email server won't send it, the field on the lead record has a red squiggly line under it and the same happens when you enter it into a report subscription.

[SanfordWhiteman]

I agree, inconsistency in different parts of the same app is itself a problem.  I was just trying to show that gut feelings about the range of truly valid email addresses are usually wrong.  This applies to the publicly usable addresses as well.  Back in the day, when testing mail servers, we used to use the address literal form a lot -- elliott@[1.2.3.4] -- but few people understand that's a totally legit pattern.  Same with quoted addresses with spaces, and punycode.  One of the most easily fixable mistakes, in my experience, is made-up length restrictions.  The would-be "geek" site Newegg.com has a 40-character limit, I think, so I had to create an alias just for them... sigh.

Anyway, doing validation against a standards-based mail server is the happy side effect (latency notwithstanding) of validating email addresses.  The "shortcut" to knowing if an email address format is legit is checking to see if it can receive mail!