A contact form whose messages genuinely arrive

A designer finishes a caterer's site. She tests the contact form herself, the message arrives in her inbox, and she hands over.

Three months later the caterer calls, upset. Somebody mentioned they had "messaged through the website weeks ago" and heard nothing. She checks. Nobody has received anything since the week it launched.

The form never showed an error. It said "Thank you, your message has been sent" to every single person who used it. Some of them were people who wanted to spend money.

Nobody can say how many enquiries were lost, because there is no record of them. That is the worst part: not the failure, but that the failure and success looked identical, and nothing anywhere said otherwise.

This is the most important lesson in this module. A form that silently stops working is worse than no form at all, because a business with no form knows it has no form.

Words in this lesson

Why WordPress email fails

By default, WordPress asks the web server to send mail. Web servers are not mail servers, and the mail they produce usually has none of the things that prove it is genuine.

So receiving systems do one of three things, and only one of them is visible:

All three look the same to the person submitting. The form's job is to hand the message to the server; once it has, it reports success. Whether anything arrived is a separate question the form never asks.

This gets worse over time. Hosting providers change, mail providers tighten their rules, and a form that worked in January can fail in March with nothing changing on the site at all. Which is exactly what happened to the caterer.

The two things that fix it

1. Save every submission in the database

Most good form plugins can store submissions as entries, visible in the dashboard, separately from email.

Turn this on. It is the single most valuable setting in this lesson.

With entries saved, email becomes a convenience rather than the only copy. If mail breaks, the enquiries are still there, still readable, still recoverable. The caterer would have lost nothing — she would simply have had a list waiting in her dashboard, and somebody would have noticed within days rather than months.

Two cautions:

• Tell the client that messages are stored on the site, and show them where. Storing people's names and phone numbers is something the business is responsible for.
• Entries accumulate. Part of the monthly maintenance you will charge for in Module 7 is clearing old ones.

2. Send email through a proper service

Instead of letting the web server send mail, configure WordPress to send through an authenticated service — this is what SMTP means in practice. A plugin handles the connection; the service handles being trusted.

The options, honestly:

Whichever you choose, the From address should be an address on the business's own domain, not the visitor's address. Sending mail that claims to come from the visitor is one of the most reliable ways to have it rejected. Put the visitor's address in the reply-to field instead, so the owner can still just press Reply.

Test it properly

"I submitted the form and it said thank you" is not a test. That message appears whether or not anything arrived.

A real test:

1. Submit the form as a visitor would, from a different device
2. Confirm the email arrives in the business's real inbox — the one they actually read
3. Check the spam folder if it does not, because that is a different failure with a different fix
4. Confirm the entry was saved in the dashboard
5. Press Reply on the email and confirm it goes to the visitor, not to the site
6. Do all of this after the domain is pointed and the site is on its final address, because mail behaviour changes with the domain

Step 5 is the one everybody skips, and a business owner who cannot simply hit Reply will stop using the form within a fortnight.

Spam, without breaking the form

Leave a form unprotected and it will receive automated rubbish. The protection you choose matters, because the wrong one costs you real enquiries.

A honeypot is a hidden field that bots fill in and humans never see. It stops a great deal of spam, costs the visitor nothing, and cannot be failed by a real person.

A visible challenge — clicking boxes, identifying pictures — stops more, and also stops some genuine customers. On a phone, on a poor connection, a challenge that fails to load is an enquiry lost, and neither you nor the client will ever know.

Start with a honeypot. Add something stronger only if real spam becomes a genuine problem, and understand that you are trading enquiries for tidiness when you do.

Also: keep the form short. Name, phone or email, and message. Every extra field loses people, and a business that asks for a budget range before it has said hello loses the ones who were still deciding.

The check that keeps it working

Because this fails silently and can break without anyone touching the site, it needs checking on a schedule rather than when someone complains.

Once a month, submit the form yourself and confirm it arrives. Thirty seconds. Put it on the same list as updates and backups in Module 7 — it belongs in the maintenance you are being paid for, and it is the single most valuable item on that list.

When you hand over in Module 8, show the client the entries screen too. Two people knowing where the messages live is considerably safer than one.

Common mistakes

The short version

• A form that fails looks exactly like one that works. That is the whole problem.
• WordPress sends mail through the web server by default, and that mail is often rejected or filed as spam.
• Save every submission as an entry in the database. Email then becomes a convenience, not the only copy.
• Send through an authenticated service, with a From address on the business's own domain and the visitor's address in reply-to.
• Test properly: real inbox, spam folder, entry saved, Reply works, and after the domain is pointed.
• Start with a honeypot. Visible challenges cost real enquiries on poor connections.
• Keep the form short. Name, contact, message.
• Submit it yourself once a month. It is the most valuable thirty seconds in your maintenance routine.

Try it yourself

Build a working contact form on your practice site, then prove it works — and prove you would know if it stopped.

1. Install a form plugin. Build a three-field form: name, phone or email, message.
2. Turn on saving entries to the database. Find the screen where they appear and open it.
3. Submit the form from a different device. Confirm both the email and the entry.
4. Press Reply on the notification. Where does it go? If it goes anywhere except the visitor, fix the reply-to setting.
5. Now break it deliberately: change the notification address to something invalid and submit again. Note that the form still says the message was sent. That is the lesson, seen with your own eyes. Then confirm the entry is still there — which is why entries matter.

Finally, write the two sentences you will say to the client at handover about their contact form. One sentence telling them where messages are stored besides email, and one telling them what you will be doing monthly and why.

If you can say that second sentence without it sounding like an upsell, you have understood this lesson. It is not an upsell. It is the difference between a form that works and a form that used to.

You'll know you've got it when you can explain to a business owner why "it says message sent" proves nothing — and when you would notice a broken form within a month rather than within a quarter.