Is there any way to block spam form sign ups?

[Meghan_Souza3]

Ok, so to have this accept indeterminate results would this also mean in this config you would also allow in false domains (before re-checking and spitting out)? Or is indeterminate a level above "fake" altogether?

[SanfordWhiteman]

Indeterminate is a level above and considered separate from nonexistent, but someone could put up an MX (like yours) that makes every mailbox indeterminate.

[Meghan_Souza3]

Alright, last thing, the spam we've been getting makes me think this is a human logging hundreds of form fills - almost always come from @qq.com - so the goal is not only to check the domain but also verify the recipient is legitimate, it sounds like this tool just checks domain validity - is that correct? or the webhook checks both just after submission? Wish we could keep this out of the db altogether of course

[SanfordWhiteman]

Verify checks, end-to-end, the mailbox@domain. Not just the domain!

The question is whether the domain's MX gives a real-time result for whether the mailbox exists. If it refuses to give a real-time answer you must continue to check periodically (although it may refuse indefinitely). Because you need to retry at least a full minute later you can't do that within the form itself, you have to let the form post and then check using a 'hook.  This means you will likely still get an actionable pass/fail but that happens after the lead is in the system -- you need to defer processing a lead any further until you get firm knowledge either way. Note it's exactly the same with reCAPTCHA, though they are targeting different cases. With reCAPTCHA you must let the form submit, then check if the reCAPTCHA matched. You can't check the match in the browser, that's where the hacking happens.

[Meghan_Souza3]

Thanks for the thorough explanation! I'll look through the recapctha implementation docs you've made for the rest of my implementation q's on this further then! Much appreciated