How a Website Contact Form Sends Email

A contact form is only the interface. When someone presses Send, your website still needs a backend or email service to turn that form submission into a real email and deliver it to an inbox.

What happens when someone presses Send?

1. A visitor fills out the contact form: their name, their email address and a message.
2. When they press Send, the browser sends the form data to your backend — for example as a POST request to /api/contact.
3. The backend validates the submission and turns away anything empty, malformed or abusive.
4. It asks an email service to send the message, signing in with SMTP credentials or an email API key that only the server can read.
5. The email service accepts the message and passes it into the email system, where the receiving side decides what happens to it.
6. If delivery succeeds, the message arrives in your inbox — or in your spam folder, if the receiving side decides it looks suspicious.

The main pieces

Visitor — Someone on your website who wants to reach you. They type their name, their email address and a message, then press Send. Everything after that happens out of their sight — all they see is whatever the form shows next.

Contact form — The fields and the Send button on your page: frontend code running in the visitor's browser. It collects what they typed and submits it to an address on your server. It cannot deliver email itself, and it must never contain an SMTP password or a private email API key — anyone who opens the page can read its code.

Form submission — What travels when the visitor presses Send: the name, email and message, usually as an HTTP POST request to an address such as /api/contact — the same kind of request any API call is. No email exists yet; this is data on its way to your backend, nothing more.

Your backend — Your server-side code — an endpoint on a Node.js or PHP backend, a route in a full-stack app, or a serverless function. It receives the submission, validates it and can turn away spam and abuse. Then it uses credentials only the server can read to ask the email service to send the message, and tells the form whether that request succeeded. It may also save a copy of the message.

Email service — The service that actually sends mail for you: your hosting provider's email, an SMTP server or a transactional email provider. Your backend hands it the message over SMTP or through an HTTP email API, signed in with a private credential. Once it accepts the message, it takes over sending it — accepted, but not yet delivered.

Mail delivery — The sending mail server passes the message to the recipient's mail system, which decides what happens to it: deliver it to the inbox, file it as spam, or reject it. Your code does not control that decision. Checks such as SPF, DKIM and DMARC help the receiving side trust your domain, but nothing guarantees the inbox.

Your inbox — Where the message lands — for a contact form, usually your own business inbox. It arrives from an address on your own domain, with a subject such as New message and the visitor's text inside. Sending it as the visitor's own address would usually fail the receiving side's checks, so their address goes in Reply-To instead: pressing Reply answers them.

Why can't a contact form send email by itself?

A form is frontend UI. It runs in the visitor's browser, and all it can do is collect what they typed and submit it somewhere. (A mailto: link is different again: it only opens the visitor's own email app, and your website sends nothing.)

Sending email safely takes private credentials — an SMTP password or an email API key — and a service that is allowed to send mail for you. Anything in browser code can be read by every visitor, so a password placed there is a password you have published: anyone could copy it and send mail through your account.

So the form hands the submission to your backend, and only the backend — which keeps those credentials private — talks to the email service. The form collects; the server sends.

SMTP or an email API — what is the difference?

Both are ways for your backend to hand a message to an email service. SMTP is the standard protocol for sending email through a mail server: your backend connects to the server and signs in with its credentials, usually a username and password.

With an email API, your backend sends an HTTP request to an email provider's API, authenticated with a private API key, and the provider sends the email.

Both can deliver real email, and neither is always the better choice. Hosting email accounts usually offer SMTP; transactional email providers usually offer an API, and often SMTP too. Either way, the credential stays on the server.

Why did my form say “Message sent” but no email arrived?

Because a success message on the page is not proof that an email was delivered. Depending on how the form is built, it usually means your backend or the email service accepted the request — and some forms show it without sending anything at all.

Common causes: the form was never connected to a real backend; the backend failed or isn't running in production; the email credentials or settings are wrong or missing; the provider refused to send; the receiving server rejected the message; it was filtered as spam; or the sending domain isn't properly authenticated.

Check the spam folder first, then your backend's logs and — if your email service has one — its sending log, which shows whether each message was accepted, delivered or bounced.

What are SPF, DKIM and DMARC?

Three email authentication standards, published as DNS records for your domain, that help receiving mail systems judge whether mail using your domain is legitimate.

SPF lists which servers are allowed to send email for your domain. DKIM adds a cryptographic signature to each message that the receiving system can verify. DMARC sets your domain's policy for mail that fails those checks or doesn't align with your domain, and can ask receivers to send you reports.

Your email or hosting provider usually tells you which records to add. They help receiving systems trust your mail, but they do not guarantee that a message reaches the inbox.

How do you protect a public contact form?

Anyone on the internet can submit your form, bots included — so treat every submission as untrusted input, whatever the browser already checked.

Validate it again on the server, limit how often one visitor can send, and add spam protection such as a hidden honeypot field or a challenge when abuse appears. Fix the recipient on the server so a visitor can never choose who receives the email, and never expose your email credentials to the browser.

Where does the backend run?

The code that receives the form and sends the email has to run on the server side. Depending on how the project is built, that can be a Node.js backend, the backend routes of a full-stack app, a PHP endpoint on your hosting, or a serverless function — no one stack is required.

What matters is that it runs somewhere the visitor cannot read, so the SMTP password or email API key can live in server-side environment variables instead of in code the browser downloads.

A purely static site — files served as they are — has nowhere to keep those credentials safely. It needs one of these runtimes, or a hosted form service that plays the backend's part for you.