Hello!
Here the deal - We have a form on one of our sites - the email alert we (the company) gets when the form gets filled out is from the user who filled out the form. Great! However, we are getting a few here at there that are going straight to the junk/spam folder. This is not great as we want these leads to go to our inbox - not spam - in order to get them taken care of quickly. It seems as if the "spam" filter doesn't like the names and email addresses that come through causing it to go to spam. As we have legitimate form fills that are from not common names. Here is what the form looks like when we built it.
Is there a way to stop this from happening? Is it as easy as taking the "spam" filter off the form? Or should we have our email alert emails sent from us not the person who filled out the form?
Thank you for your help!
If this is happening internally on your alerts, that is actually a great problem to have. The reason being is that you can pretty much control what happens on your side of things. The email alert emails should be sent from your internal From address. This is the same address that you would be using for all of your outbound/promotional emails. This should solve the majority or all of your issue. There are also a few other things that you can do:
Thank you Bryan Epstein! Let me look into these points and will let you know how it goes!
Bryan's advice above is spot-on -- the key thing to note is that the cause of this issue is likely in your email, not the form itself. If you want to share a screenshot of your email in the editor (and potentially your SPF/DKIM settings in Admin), we may be able to help troubleshoot more specifically.
Thank you Michael White! Here is a screenshot of the email in the editor -
For our alerts, I will typically do the following:
From: Your Company or Name
From Address: YourCompanyEmail@email.YOURCOMPANY.com [or whatever you have in your SPF/DKIM records]
Reply-to: Your Email Address or a My Token that includes multiple people on the reply
Subject - You can add the full name lead token here, so that people know who it is coming from.
Since these are internal alerts, it helps more to know that it is coming internally and is standardized rather than from potentially unknown names.
Got it -- so yes, this ties back into Bryan's comment -- you're using the Person-level "Proxyemail" field address as the From Address/Reply-To in your alert, but assuming that Proxy Email is the value that is written by the person in the form, there's no way to ensure that it's going to match the signing domain that your Marketo instance is sending email from, and it's going to in all likelihood fail SPF/DKIM validation. *
Your company's receiving email server is basically interpreting the email as saying it's coming from a person at one domain, but actually being signed by your Marketo sending domain, so it's flagging it as potential spam. Like Bryan mentioned, changing the From and Reply-To fields to be addresses at your internal domain should resolve this. *
*Edit: See Sandy's clarification below re: the technical aspects that are likely at play here.
...there's no way to ensure that it's going to match the signing domain that your Marketo instance is sending email from, and it's going to in all likelihood fail SPF/DKIM validation.
Few corrections/clarifications here:
Re: DKIM, it will be unsigned in this case, which is very different from failure (i.e. bad signature). If a domain isn't set up for DKIM in Admin, Marketo signs the email only with its own @mktomail.com key and skips signing the email on behalf of the customer domain. It doesn't use the key from another customer domain. Lack of a signature means the email can be repudiated, and it'll be deprived of any positive weighting given to signed mail by anti-spam scanners. But it won't get negative weighting just by being unsigned, nor will it have a broken signature (broken sig would be a fatal error).
Re: SPF, since (like the majority of Marketo customers) Carly's envelope sender domain is {verp address}@{something}.mktomail.com, it's only {something}.mktomail.com's SPF TXT record that gets checked. SPF only relates to the SMTP envelope, not the From:/Reply-To: headers. (See the posts at https://blog.teknkl.com/tag/spf/, especially the earliest one.)
Re: DMARC, that's where there could be a true failure. If (and only if) a domain publishes a DMARC policy requiring either an SPF pass or a DKIM pass, and the receiving server enforces DMARC, then simply not failing those checks is no longer acceptable. You'd have to actively pass one of them.