A contact form that shows a thank you message is not proof that anyone received the enquiry. A contact form not working is hard to spot, because the page usually looks fine: the visitor sees a success message while the email is blocked by the server, rejected by spam protection or filtered by the inbox. The checks we run on the sites we look after are simple. We send a real test to the real inbox after every change, keep a copy of each submission in the website database, send mail through an authenticated mail service rather than the web server, and confirm the spam protection accepts the site’s current domain. xCreative™ is a Melbourne creative agency in Chadstone that has built and maintained business websites since 2016, and the problems below are ones we found and fixed in October 2026.
Why a form can say sent when nothing was sent
Most website forms do two jobs. They accept the visitor’s details, then they hand an email to something that delivers it. The success message normally confirms only the first job. On WordPress the hand over goes through a function called wp_mail, and on a fresh server that function may have no working route out. Amazon’s documentation says that “By default, AWS blocks outbound traffic on port 25 on all Lightsail instances”, so a website moved to a new Lightsail server can lose its ability to send mail directly on the day it moves.
Even when the server can send, the receiving inbox decides whether to accept. Google’s email sender guidelines require every sender to personal Gmail accounts to set up SPF or DKIM for the sending domain, and to have valid reverse DNS for the sending IP address. A web server that sends as your business without those records looks like a stranger using your name. Many of those messages land in junk, and some never arrive at all.
Four ways we have seen enquiries go missing
The form settings expired. On a Melbourne builder’s website we look after, the form plugin kept its settings in a temporary store that lapsed after 24 hours and only refreshed when the page was rebuilt. With page caching switched on, the page would stop being rebuilt, and a day later every submission would return the error “No submit action enabled”. The plugin also saved nothing, so the only record of an enquiry was the notification email. We found this while preparing to turn caching on. The fix was a small piece of code that rebuilds the settings when they are missing and logs every submission in the website database, whether the email goes out or not.
Spam protection rejected the domain. Cloudflare Turnstile, the check many sites use instead of a puzzle CAPTCHA, only works on the hostnames listed against its key. Cloudflare’s error code list says code 110200 means the domain is not authorised, and that retrying will not help. When a site changes domain, or moves from www to the bare domain, the form can refuse every visitor until the new hostname is added in Cloudflare’s hostname management settings. A broken check box is worse than a little spam, because nobody can contact you.
The new server could not send. In October 2026 we moved most of the websites we manage to new servers. A new server is a clean machine. The mail route the old one used does not come with it, and on AWS the standard mail port stays closed until Amazon approves a request. Our fix is an SMTP connection to the business’s own mail service, which signs messages for the domain and uses a port AWS does not block.
An edit broke the form quietly. When we changed the button wording on our own contact form on 23 October 2026, the save step in one plugin rewrote the form template and the page showed two verification boxes. We restored the template from the backup taken before the edit. Since then we back up every form before changing it and check the live page straight after.
The checks we run after any change to a website
- Submit the form on the live site from a phone and from a desktop, using an email address outside your company, and confirm the message reaches the inbox rather than junk.
- In Gmail, open the message, choose Show original, and confirm SPF and DKIM both show PASS.
- Check the From address is on your own domain and the visitor’s address sits in Reply-To, so pressing reply still reaches the customer.
- Confirm the recipient is a mailbox someone reads every day. Staff leave and mailboxes change, but forms keep sending to the old address.
- Find the stored copy of the test submission in the website dashboard.
- If the site uses Turnstile or reCAPTCHA, load the form on every version of the domain the site answers on.
We run this list after launches and server moves, and again whenever the form plugin, the domain or the email host changes. It is part of our website maintenance work, and it is the first thing we test on a new WordPress website before it goes live.
Why every enquiry should also be stored on the website
Email is a way of delivering an enquiry, not a record of it. If a notification bounces, or someone deletes it by mistake, the enquiry is gone. A copy in the website database means a week of failed email loses nothing: the enquiries are waiting in the dashboard. Contact Form 7, one of the most common WordPress form plugins, does not store messages by itself, and its developer offers a separate plugin called Flamingo for that job. Some page builder forms store nothing and give no way to add storage, which is why we wrote our own log for the builder’s site above.
Stored enquiries hold customers’ contact details, so they need the same care as any customer data. On that site the log sits behind an administrator login and connects to the WordPress privacy tools, so one person’s enquiries can be exported or deleted when they ask.
What to ask whoever looks after your website
If you are not sure your form works, ask your developer or agency three plain questions. Where does an enquiry go after the visitor presses send? Is mail sent through an authenticated service with SPF and DKIM set up for your domain? Who tests the form after updates and server moves? Clear answers to all three are a good sign. The Australian Cyber Security Centre also recommends SPF, DKIM and DMARC together to stop criminals sending email in your business name, so the same setup protects your reputation as well as your enquiries.
If you are moving to a new provider, put form settings, the mail service login and the spam protection account on your handover checklist. The server work behind our October moves is covered in our PHP2Shell article. If you would like us to test your forms and email setup, or look after your site from here, see our website maintenance service or get in touch.
Frequently asked questions
Why does my contact form say sent but I get no email?
The form accepted the details, but the email was blocked or filtered after that. Common causes are a server that cannot send mail, missing SPF or DKIM records for your domain, a From address that uses the visitor’s email, or a recipient address nobody checks. Look in junk first, then ask your developer how mail leaves the site.
How often should I test my website contact form?
Test after every change that touches the site or your email: plugin updates, theme changes, server moves, domain changes and a new email host. Between changes, a monthly test from an outside address catches problems that appear on their own, such as an expired mail password.
Do I need SPF, DKIM and DMARC for a contact form?
Google requires SPF or DKIM from everyone sending to personal Gmail accounts, and the Australian Cyber Security Centre recommends SPF, DKIM and DMARC together. Most small businesses set these up once in their domain’s DNS, with help from their email provider, and the contact form benefits from the same records.
