Often, when I'm consulting with a client and a third-party service provider, I may have the need to bring up a security concern which should be considered, or eliminated, surrounding what the third-party service provider aims to implement. This can be met with a defense of "We have always done it this way and not had a problem yet." which drives me insane!

Example

This particular example is one I have fought a LOT over the last couple of decades but for some reason I'm still having to fight it - Contact Forms on Websites.
I'm a System Administrator ("SysAdmin"), and even though I do a little website work here and there I am not a web designer nor developer. However, I do deal with web servers, email servers, networks and all devices and security in between, so when I'm asked by a third-party web company to set up an email account and provide them the credentials for it to handle the emails sent from a contact form on a website I get very, VERY, angry.

I may get an email like the this:

Hello,
Could you please set up the email account `submissions@$(client_domain_name)` and send us the SMTP username and password so the contact form on the website can send emails to $(client) please?
Thanks,

Looks fairly harmless. Right?
Wrong.

Why is this bad?

  1. Why do we want to use an internal email address to send emails from an external service (the website) to internal staff members... Why!? Why does it need to be an internal address?
  2. If, for some reason, we do want the email to go to the public then I appreciate it would be good to come from the business address but... why is the website doing this?
  3. Why are we giving a web server - possibly the most front-facing and vulnerable server a business can have - knowledge of sensitive business credentials.
  4. Basic SMTP authentication is mostly considered insecure in general these days. Large email operators such as Google and Microsoft have, or are, removing it as an option because of this.

What do we do?

To tackle point [1.] above, as a website operator you could set up a reasonable email service, or use a paid service, which you can configure to use SMTP as you desire. Just send the emails from a domain you set up appropriately (SPF, DKIM, DMARC, etc.) to the client, like "$(clientname)-website@contactforms.ourwebcompany.com". Assuming you've set email security up appropriately, the emails will be delivered to the client successfully and deal with as you need.

Tackling point [2.], if we want to send the contact form to the business and send a confirmation of receipt to the customer, this is not a job for the web server. The web server has zero knowledge of if the email to the business arrived, so sending a "Thanks for your email, we have it" email to the customer at this point is stupid. This whole concept is a task for a CRM system - it receives the email, logs it into the appropriate queue, then confirms to the customer itself that it has been received.

Point [3.]: Please, please, please don't put sensitive business credentials on your front-facing web server. If that server is compromised you've just given the attacker access to that email account (and potentially access to internal systems too). With that email account an attacker can send spam messages, or worse, to whomever they want and because they're authenticated, the emails are coming from a legitimate server, as your brand. Just don't do it. that's how you solve this one.

Point [4.]: If the email service doesn't support it, then you can't do it anyway. In my most recent experience of this the web company involved said they had 350 clients set up with SMTP authentication and it's normally easy. Which may well be true - but Microsoft are removing support for SMTP by April 2026 as far as I understand. Imagine if those 350 clients all used 365 and in April suddenly all their contact forms stopped working. Bit of an issue, right? Fix it now, problem solved.

Other Options

Personally, I have no idea why businesses are so adament they want their contact forms to arrive via email. It's silly. Website services don't help as they just say "what email account do you want this form to go to?" and be done with it. Typically a web site platform (such as WordPress) when sending these emails just uses an SMTP tool to fire the email off and have nothing else to do with it, it's gone. So how do we ensure an email has been received? Who wants to trawel back though their mailbox to find previous contact forms? Nobody, that's who.

A form on a website is not linked to email, it just sends data to an endpoint which itself can handle the data as it is built to do so. This could be an email, sure, but also it could save a file, or send an API request to a service. Or to put it a simpler way:

WE DO NOT NEED TO CONNECT CONTACT FORMS TO EMAIL ACCOUNTS!!!

With this tiny bit of knowledge comes great power. We can make our contact form interface directly with another system i.e. a basic form handling service or CRM system. I'll leave the use of a CRM system as an exercise for those that need it, but a form handling service is a great option for those who just need contact forms.

Form Handling Solutions

I try not to make recommendations so I'm not going to link right here but two options I have used in the past are Formspree ([dot]io) and Basin (usebasin[dot]com).

I'm sure there's some open source and self-hostable solutions too - if you know of one, let me know and I'll list them here! (Ability to adequately secure self-run email services required - why don't you Run Your Own Mail Server?)

A brief overview is with these services you just change the action url in your form to a "Form Endpoint" url they will provide to you and you're done! Your contact form, when submitted, simply sends the data to this endpoint where it is stored (for 30 days on the free tier) and it notifies you of the submission receipt.

No messing around setting up email accounts and securing them appropriately, just plumb that url in and that's it.

Minor issues

The only potential issue with these services is with the free tiers they just accept forms from anywhere, so a submission to it doesn't have to come from your website. If somebody knows the endpoint url, they can submit to it.
To counter this you would need to use the paid tier and middleware to accept the form submission then authenticate and send the form to the handling service.
Regardless, I think the payoff of not risking your entire business email service is worth it, so this problem is minimal.

Wrap Up

So that's my rant about contact forms on websites. A problem that still exists in 2025 even though numerous options are available to eliminate it completely.
Far be it from me to compliment Microsoft, but I am very much looking forward to April 2026 when I suspect quite a large chunk of contact forms are just going to stop working. I bet I'll get some panicked calls, and I'll be happily wearing my "I told you so" hat.