How to make a website contact form deliver reliably

A contact form that appears to submit successfully but whose emails never arrive is one of the most common website complaints, and it is almost always caused by how the message is sent rather than anything wrong with the form itself. Website software has a simple built-in way to send mail, and that simple way is exactly the part worth replacing.

Why the default sending method is unreliable

Most website platforms and scripting languages include a basic built-in mail function that sends a message directly from the web server, without logging in to a real mailbox first. Mail sent this way has no authentication behind it — no SPF alignment with a real sending mailbox, no DKIM signature tied to an actual account — which makes it look exactly like the kind of unauthenticated mail that spam filters are designed to catch. It often works fine in testing and then quietly fails or lands in spam once a receiving mail provider's filtering catches up with the pattern.

The fix: send through a real, authenticated mailbox

Configure the form to send using SMTP — logging in with a genuine mailbox's username and password — rather than the server's default mail function. This gives the message the same authentication backing as mail sent from an ordinary email client, since it is genuinely coming from an account that SPF and DKIM can vouch for.

1. Create a mailbox for the form to send through

   A dedicated address such as forms@yourdomain.com works well, kept separate from a personal or shared mailbox so its sending activity is easy to identify. See setting up email on your domain.

2. Configure the form or plugin to use SMTP

   Most website platforms and contact form plugins have an SMTP option, usually under a mail or notifications settings screen, asking for the same server name, port and login details as any mail client.

3. Enter the outgoing server details

   Use the outgoing server hostname from your control panel, port 587 with STARTTLS (or 465 with SSL), and the mailbox's full address and password.

4. Send a genuine test submission

   Submit the form as a real visitor would, and confirm the message arrives at the destination inbox, checking the spam folder as well as the inbox on the first few attempts.

Make sure SPF and DKIM cover this sender

If your domain already has an SPF record, confirm it includes your host's mail servers — the same ones the form is now sending through — and that DKIM is enabled for the mailbox. See SPF, DKIM and DMARC explained if these are not set up yet.

Setting the From and Reply-To addresses correctly

A common further mistake is setting the visitor's own submitted email address as the message's "From" address. This fails SPF and DKIM outright, since the message is authenticated as coming from your mailbox but claims to be from someone else's domain entirely — exactly the mismatch these records are designed to catch.

If mail still is not arriving after this

• Check the destination mailbox's spam folder specifically, since a form that previously failed authentication may have already been flagged by the recipient's mail provider and take a little time to be trusted again.
• Confirm the sending mailbox is not at its quota, which would prevent it sending anything at all.
• Check you have not hit a sending limit if the site receives a high volume of submissions.
• Review the plugin or script's error log, if one exists, for a specific SMTP error rather than a generic failure.

If the form is built with custom code rather than a plugin, sending email from PHP covers the same SMTP approach at the code level.

Confirmation emails to the visitor need the same treatment

If the form also sends a confirmation back to the person who submitted it — an order receipt, a "we've received your enquiry" message — that outgoing mail benefits from exactly the same authenticated SMTP setup as the notification sent to you. A form that sends notifications reliably through an authenticated mailbox but still sends visitor confirmations through the server's default mail function will keep seeing confirmations land in spam for recipients, even though the side you personally check looks fine.

Testing from outside your own network

Submitting a form while connected to the same network as the server can sometimes behave differently to a genuine visitor's submission from elsewhere, particularly if any security rule treats requests from familiar addresses differently. Test using a mobile connection or ask someone external to submit the form as a more realistic check than testing from your own office or home network exclusively.

Once the form is sending reliably, treat it the same as any other mail source on your domain when reviewing SPF, DKIM and DMARC — it needs to be included in your SPF record's list of legitimate senders, the same as any mailbox or third-party service sending mail on your domain's behalf.