Major mail systems today, such as Exchange Online or Gmail, enforce a number of controls designed to thwart the spread of ransomware, reduce the chances of identity theft, minimize spear phishing, block malicious links, and filter out spam. Even in the most basic form, these systems can work against your organization's interest when it comes to collecting feedback / forms data from your digital marketing assets.

Feedback form transport is surprisingly complex because of the protection measures as well as the custodial responsibility of your organization over the data that may be submitted. The general strategy for any organization should be to:

Collect data that is material to objectives.
Transport all data securely and protect the confidentiality of the information on arrival.
Put organizational security (including MFA, Identity, and Conditional Access) ahead of feedback form concerns.
Be able to audit every message transported and its delivery easily so that it is routine.

Review your posture.

Before getting started, BCSF encourages to take stock of your feedback systems through the assessment below. Each statement represents a key component of an organization-wide implementation of feedback forms. In the least, a high number of “No” and “N/A” responses is indicative of problematic feedback form strategy.

Assessment:

Yes	No	N/A	Statement
			Organization has valid SPF records with less than 10 lookups.
			Organization has a valid DMARC record meeting the following conditions DMARC policy must be at enforcement – either “p=quarantine” or “p=reject” on the organizational domain No sp=none or pct<100
			Organization has a valid DKIM record.
			Organization has a valid BIMI record.
			Organization meets TLS 1.2 requirements and all support for “legacy” connections has been disabled.
			Organization is able to enforce MFA/2FA authentication through conditional access.
			Organization enforces MFA/2FA authentication globally (all mailboxes protected).
			Organization website(s) publish e-mail addresses.
			Organization website(s) use contact forms.
			Organization website(s) force HTTPS and do not permit form submission using HTTP.
			Organization website(s) are accessible.
			Contact forms use the REPLY-TO parameter.
			Contact forms use the FROM parameter.
			Contact forms send a “thank you for your submission” email to requestor.
			Contact forms include the form data in the requestor “thank-you” email including either the subject, comments, data or a combination of the three.
			Contact forms offer flexible transport options and complete control over how a message with form data is sent.
			Contact forms use the flexible transport options to send mail in a manner consistent with organizational policy.
			Contact forms use a sub-domain or a third-party domain in the FROM parameter.
			Contact forms use web-hooks or integrations to route data to other channels such as Slack, SalesForce, or Google Drive.
			Organization uses a third-party form design and hosting service.
			Organization uses a third-party transactional email service to transport form data.
			Organization uses a mailbox to transport form data.
			Organization uses a mailbox to transport data, whether it be one in their primary email platform or one supplied by a third party.
			Organization has configured transport-level rules to white-list, permit, or otherwise modify delivery of inbound contact forms to ensure delivery.

Problem Statements:

Yes	No	N/A	Statement
			Form data is sent to Junk/Spam or not received.
			Requestors do not receive “thank-you” emails.
			Replies to contact forms by staff are unanswered by the requestor.

Activity Statements:

Yes	No	N/A	Statement
			Forms are routinely tested to verify functionality.
			Form data is routinely reviewed.
			Data handling controls are applied to form data.

Understanding how e-mail through third-parties may flow.

Email Webform Flow Diagram

Most organizations today rely on Exchange or Google Workspace (or similar mail systems) to handle organizational email. These systems offer standard mail filtration in the basic plans, encourage adoption of DMARC/DKIM/SPF to ensure trust in email, encourage use of MFA to restrict mailbox access, and finally offer advanced tiers of security solutions for additional threat protections.

Web forms sending to these organizations must contend and adapt to all of those things to successfully deliver messages. While a contact form may seem simple, the lifecycle of the data inside the form - today - follows this general trend when designed correctly:

Feedback form securely accepts requestor data and builds the message.
Messages are sent with full SPF compliance to the target recipients.
Mail system receiving the message scans the message for threats and delivers the message to the target user or group.

Each of these milestones has a series of much smaller, and much more important, steps and decision points. Collectively, their job is to ensure that the purported sender of the message is the person whose email address is in the FROM field of the message. Let's put that into an analogy we all may understand better.

Suppose you have a letter mailed to you in an envelope from “B. Baz”. If it is an analog envelope and letter, you put some amount of trust that Baz did send the letter, but you also have a few things you can do to try to validate it. For instance, you can look at the cancelled stamp and make a decision as to whether or not the post office the letter moved through makes sense for the letter. If you use a service called “Informed Delivery” you could verify the message went through the Post Office and was not just shoved into your mailbox. If the letter was important, actions on behalf of the sender could have been implemented to help underscore the importance - such as registered mail, priority, and certified. While none of these things are foolproof, they add to the credibility of the message and influence your trust. In e-mail speak, this is effectively called a “spam score”.

Mail systems that leverage filters, SPF, DMARC, and DKIM do all these extra checks to attempt to verify that sender, the message transport services, and the recipient are all valid. If we continue along this analog mail analogy one could say that these systems:

Attempt to verify the sender on the envelope matches the signature in the message.
Attempt to verify that the sender's address is real.
Attempt to verify the recipient address is real.
Attempt to verify that the content of the message is consistent with intent.

Additionally, advanced threat protection will often:

Read the email and assess if the subject matter is applicable to business.
Review relationships of the sender to recipient and attempt to determine if there is ample history or cause for the message to be routed.

Third-party email in real world practice.

Website Feedback Forms

With all this validation it's no surprise that delivering a contact form from a web server to your mailbox can be daunting. Today,

The form must be able to properly set the FROM and the REPLY-TO e-mail addresses so the FROM always passes validation during transport.
Construct the message in a way that does not cause spam filters to think it's junk.
Transport the message through a valid mailbox, authorized SMTP server, or through a transactional email system.
Do the same for a thank-you / confirmation email.

Before talking about the first three points, the fourth one stands out on its own: the thank-you message is an exploitable asset. What typically happens is web-forms are analyzed by bots and malicious actors. If such bot can fill the form out with valid information, and then inject a malicious subject or comment, the thank-you message becomes a vector as it's content is now poisoned. This is why today's BCSF guidance strictly forbids the sending of form data inside confirmation messages to the senders on the form. The risk of spreading malicious content is simply too high.

Successful strategy examples:

Transactional

Yes	No	N/A	Strategy
			Contact form forces HTTPS and securely transports data to recipients.
			Contact form has the ability use different FROM: uses an organization approved value such as “noreply@bentosecurity.org”. REPLY TO: uses the form submitter's email address and user/account if required during transport.
			Contact form integrates with transactional email senders such as SendGrid, MailGun, SparkPost, PostMark, etc and uses API to send the request.
			No-Reply notification is sent to the submitter without form fields.

Dedicated SMTP

Yes	No	N/A	Strategy
			Contact form forces HTTPS and securely transports data to recipients.
			Contact form has the ability use different FROM: uses an organization approved value such as “noreply@bentosecurity.org”. REPLY TO: uses the form submitter's email address and user/account if required during transport.
			Contact form uses SMTP with TLS for SMTP server and authenticated username and password for the send.
			Conditional access permits dedicated mailbox to authenticate without MFA.
			Notification is sent to the submitter with a usable REPLY TO address but without form field data.

Web Hook / Integration

Yes	No	N/A	Strategy
			Contact form forces HTTPS and securely transports data to recipients.
			Contact form has the ability use different FROM: uses an organization approved value such as “noreply@bentosecurity.org”. REPLY TO: uses the form submitter's email address and user/account if required during transport.
			Native integration connects, and successfully authenticates, to a function that writes this form data to a com channel or web application.
			The target application may have its own processor for sending notifications.

Support Systems and Automatic Replies

Your support systems are also affected by e-mail protections. For example, if you use ZenDesk, you may have already realized that they implemented a programming change that prevented certain variables from working on the very first e-mail to avoid abuse. This affected all new tickets as follows:

When a new ticket is created, it is not possible to include the body of the request in the confirmation message
When a new ticket is created, the subject of the message is not honored and the only option is to send a generic subjects such as “Request Received.”

Support systems and CRM should:

Yes	No	N/A	Strategy
			Be authorized to send on your organization's behalf using SPF, DMARC, and DKIM.
			Triggers/Macros that send the “thank you” message should be generic and include none of the submission.
			Procedures must be in place to effectively create tickets on the behalf of customers which bear in mind the lack of detail in the initial message.

E-Mail Marketing

E-mail marketing is most often sent with your organization's domain in the FROM field. All reputable mass mailing systems include detailed guidance on authorizing their systems to send on your behalf. Here is a sample:

Guidance for websites, mass e-mail campaigns, and fax