Email field in forms- making sure it only accepts correct email formats

[Anonymous]

Hello,

When leads are asked to provide their emails in forms on our landing pages, currently you can type in anything, eg.: a@a and it will be accepted as a correct email format. Is there a way to make sure only correct email formats (or at least consisting of a@a.com, etc.) are accepted in marketo?

Any help would be much appreciated.

Many thanks!

Joanna

[Grégoire_Miche2]

Hi Joanna,

This is possible using the Forms2.0 API (Forms 2.0 » Marketo Developers

It will require some Javascript coding though.

Sanford Whiteman​ may have done it already it his longly awaited cookbook 🙂

-Greg

[SanfordWhiteman]

Greg, yes, I've already published this recipe: MktoForms2 :: Force known TLD - DNS API

Joanna, this code uses a simple real-time check that someone has entered a currently valid TLD, i.e. joanna@a and joanna@a.11223344 will currently fail.  Bear in mind that the list of acceptable TLDs is constantly changing over time (net growing, of course, but sometimes a TLD is removed).

More advanced forms of verification are possible by extending the same model, but be warned that fully validating email addresses (without false positives) is quite complex. You'd probably be surprised at what addresses are crazy-looking but totally legit.  At a certain point, the only way to see if an email address would work in practice is to, in a sense, put it in practice: connect to the destination mailserver and (start to) send mail.  There are indeed services that do that, but -- understandably, due to their resource overhead -- they all charge per lookup.

[Anonymous]

I had been wondering about this. I've created a number of forms that, of course, include e-mail address fields. The default functionality on the e-mail field allows for the entry of e-mail addresses like: osman.erzinclioglu@somethingmissingthetld

That is, addresses without any top level domain at all. Although this is technically valid​, it's far from typical. What's more, Marketo treats it as though it's invalid only after it accepts the submission.

The program I built is meant to send an e-mail after the user submits their information, but Marketo, by its own standard, evaluates the address and immediately marks it as invalid. (When the lead record is created, but not on the form itself.)

Beside the e-mail address field on the lead record in Marketo is a warning: This field should be an e-mail address in the format "user@example.com". The "Email Invalid" Boolean field is flagged "true", and the "Email Invalid Cause" field is populated with the statement "Invalid data type in field Email Address".

My take on this? Marketo shouldn't evaluate the e-mail address as invalid after the form has already accepted it. The default behavior for the e-mail fields on a form should be updated to deny addresses in this format. The default behavior on the form field and on the lead record is inconsistent.

[SanfordWhiteman]

Ya, it's frustrating. Few things:

1. Marketo's client-side validation of user@example is not just consistent with the underlying SMTP standard but also with the HTML5 <input type="email"> (so not an old-fashioned spec).
2. The HTML5 input validation is still only a subset of publicly routable addresses.
3. Marketo's server-side validation is also broken as it blocks valid -- and publicly routable -- addresses, like quoted LHS and address literals.

I agree that reaching some sort of parity would be nice, but I think this should be via a checkbox (in Form Editor) for "stricter validation" with the boldface caveat that it may reject addresses using rare, but valid syntax.

But really both sides need to be fixed to allow all publicly routable addresses. I don't see any reason for an ESP (to the degree that Marketo is one) to refuse to send mail to valid addresses, even if they are somewhat obscure. At that point rejecting non-publicly routable user@example would be a no-brainer.

[Anonymous]

Absolutely. Yes. I'd prefer consistency between these two areas. (The form and the lead record.)

Personally, based on what I've seen, I'd feel comfortable restricting the format of the e-mail address to the most common format. The few records that have been flagged that don't conform are definitely errors. (Missing the "." in ".com, ca, et cetera.)

Although, to be fair, I'm not sure just how many valid addresses are being entered that are both atypical and are screened out by the code on the form itself.