A prospect gets in touch, slightly annoyed, to say they filled in your contact form three times over the past month and nobody replied. You search your inbox for their name. Nothing. You search the CRM. Nothing there either. The obvious conclusion is that the form is broken, so someone spends an afternoon clicking through it and it works perfectly every time.
Usually the form was never the problem. It fired, your server accepted it, and a notification email left the building. That email then arrived at your mailbox provider, got scored as a forgery, and was filed in spam or dropped silently. No bounce, no error, no trace. When contact form emails go to spam this way, the cause is almost always one default setting that nobody chose on purpose.
Two failures that look identical from your side
Before touching any DNS records, work out which of these you have.
One is a submission that never happened. A JavaScript error on the button, an over-eager anti-spam plugin, a required field the visitor could not see on mobile, a form handler pointing at an endpoint that stopped existing after the last migration. Nothing was ever sent.
The other is a submission that worked and a notification that got filtered. The record exists somewhere in your host's logs or your plugin's entries; the email just never reached a human.
Telling them apart takes five minutes. Submit the form yourself from a phone on mobile data, using an address at a domain you don't own, then look at whatever your form tool stores server-side. If there's an entry and no email, you have a delivery problem, and everything below applies.
Your form is sending mail as somebody else
Here is what most form plugins and hand-rolled handlers do by default: they put the visitor's own email address in the From: field, so that hitting reply in your inbox goes straight back to them. Convenient. It also means your web server is sending a message that claims to come from someone@gmail.com.
Nothing about your hosting is authorised to send mail on Gmail's behalf. So SPF checks the sending server against the records published for gmail.com and finds it isn't listed. DKIM finds no signature from a gmail.com key. DMARC alignment fails, because the domain in the visible From: header matches nothing that authenticated.
That combination is the exact signature of a forged sender, which is what those checks were built to catch. Your form is not being unfairly treated. It's doing the thing that spoofing does.
Put an address on your own domain in From:, something like forms@yourcompany.com, and move the visitor's address to Reply-To:. The fix really is that small. Replying still works exactly as before, and the message now claims to come from a domain your server is genuinely allowed to send for, so the authentication checks have something to pass.
The baseline every sender has to meet now
Since 1 February 2024, Google has required every sender delivering to Gmail addresses to have either SPF or DKIM set up on their sending domain. Senders above 5,000 messages a day need SPF, DKIM and DMARC together, valid forward and reverse DNS, TLS in transit, and a spam rate under 0.30% in Postmaster Tools. The full list is in Google's own sender guidelines. Yahoo published matching requirements on the same timeline.
Your contact form sends maybe four messages a day, so the bulk thresholds are irrelevant to you. The baseline is not. Low volume buys no leniency, and it shouldn't: an unauthenticated domain sending a handful of messages a day is also a decent description of a phishing attempt.
So the practical requirement for a small business site is that the domain in your From: header has SPF published and DKIM signing in place, and that whatever actually transmits the message is covered by both.
The web server is usually the weak link
A lot of sites still send through the hosting stack's default mail function. That means a shared IP address whose reputation depends on every other tenant on the box, no DKIM signing, and no delivery log you can read. When something disappears, there is nothing to look at.
Route the mail through an authenticated sender instead. If you already pay for Google Workspace or Microsoft 365, send through it over authenticated SMTP. If you'd rather keep form traffic separate from staff mail, a transactional provider does the same job and gives you a per-message log with the delivery result attached.
Either way you get two things you didn't have: messages signed with a key published under your own domain, and a record showing whether each one was accepted, deferred or rejected. That second one turns "I think the form is broken" into a question with an answer.
Never let an inbox be the only copy
Even a well-configured setup loses the occasional message. A recipient's filter gets aggressive, a provider has a bad afternoon, someone archives a notification at 6pm on a Friday and forgets.
Write every submission to a database, a sheet or your CRM at the moment it arrives, then send the notification email as a convenience on top of that. The email becomes the alert rather than the record. When one goes missing, the cost is a slower reply instead of a lost enquiry, and you can go and count how many came in last month rather than estimating from memory.
This is the same discipline that keeps pipelines from failing quietly: store the event, then act on it, so a broken downstream step never deletes the evidence that something happened.
The check you can run tomorrow
- Submit your own form using an address at a domain you don't control, then check that mailbox's spam folder, not just the inbox.
- Open the message you received and view the raw headers. In Gmail that's the three-dot menu, then Show original. Read the SPF, DKIM and DMARC lines at the top. Three passes means delivery is healthy and your problem is elsewhere.
- Look at what sits in the
From:field. If it's the visitor's address, move it toReply-To:and put one of your own addresses there instead. - Confirm your domain publishes an SPF record and DKIM keys covering whatever service actually sends the mail, not just the one you send staff email from.
- Check where submissions are stored. If the honest answer is "in whoever's inbox", fix that before you fix anything else.
Most sites we look at fail on step three, and the change takes about ten minutes. It's worth doing before you spend anything on traffic, for the same reason that outbound only works when the plumbing is right: paying to send people to a form that quietly eats them is an expensive way to learn about email authentication.
If you'd rather have someone go through it properly, that check is part of how we build and maintain sites, and it takes an afternoon on most builds.
