Every website eventually needs a form that ends up in an inbox, and there are exactly three ways to get there: make the visitor's mail client do it, run the sending yourself, or use a service. We sell the third, so discount accordingly - but the tradeoffs below are real either way, and for some sites the right answer genuinely is not us.
Option one: mailto
<form action="mailto:you@example.com" method="POST" enctype="text/plain"> <input name="message"> <button>Send</button> </form>
Zero setup, and it silently fails for a large slice of visitors. A mailto form does not send anything - it asks the visitor's default mail client to open a draft. On machines with no mail client configured, which includes most work computers and plenty of phones, nothing happens. The visitor assumes it sent; you never know it existed. The failure leaves no trace on either side, which is what makes it worse than an error.
Defensible use: a personal page where losing some messages is acceptable and the address is public anyway. Anything with revenue attached, no.
Option two: your own handler
A serverless function with nodemailer, or a PHP mail() call, and an SMTP credential. This genuinely works, and if you already operate transactional email - SPF, DKIM, DMARC aligned on a warmed domain - it might be the right call, because the marginal cost of one more sender is near zero for you.
If you do not already operate email, the code is the cheap part. The expensive part is that deliverability is an ongoing property, not a setup step: a misaligned DMARC record or a burst of bot submissions relayed through your sender can land your domain on a blocklist, and you find out weeks later when someone mentions your invoices go to spam. The form also needs its own spam filtering, because mail-provider filters act after your sender reputation has already absorbed the hit.
Option three: a form backend
The form posts to a service; the service delivers to your inbox from its own warmed sending infrastructure. Your HTML stays exactly as plain as the mailto version - the difference is one attribute value. Spam filtering happens before delivery, failures appear in a log instead of vanishing, and your domain's reputation is never in the sending path.
<form action="https://send.webforms.to/wft_your_key" method="POST"> <input name="email" type="email" required> <textarea name="message" required></textarea> <button>Send</button> </form>
The honest downside is dependency: you have added a vendor between your form and your inbox. Judge a vendor on whether you can see what happened to every submission (a delivery log), whether spam filtering is layered rather than a single captcha, and whether the free tier covers a real site's volume rather than functioning as a demo. Ours covers 300 submissions a month free, which for most contact forms is simply free.
The short version: mailto if lost messages are acceptable, your own handler if you already run email infrastructure well, a backend otherwise. Most sites are in the third bucket, which is why the category exists.