Contact Form Not Delivering Enquiries? Test It End to End

If your contact form is not sending emails, you can find the break in about twenty minutes. Submit the form from a phone, using an email address on a different provider from your inbox, and time how long the notification takes to reach the mailbox your team actually reads. It will arrive, land in spam, or never show up. Below is the script that tells those three apart, the usual places an enquiry disappears, and a weekly check that catches a silent failure before a customer does.

This covers delivery only: whether the message gets from the form to a person. If the bigger problem is a live site that produces no enquiries at all, start with why nobody contacts you and how to fix it. Everything below reflects what was public on 6 November 2026.

A tracked click is not an enquiry

A form can look healthy in your reports while enquiries go missing. The visitor presses Submit, a thank-you message appears, an event fires. None of that proves a person received anything. Three things have to happen: the form handler accepts the submission, a record is stored where you can find it, and a notification reaches a named human.

Hypothetically, a site logs 40 form-submit events in a month and the owner finds 9 enquiry emails. The gap between 40 and 9 is the number to chase: spam, test clicks, or real people whose messages never arrived. Without a stored record per submission you can't tell which, so enquiry tracking in your analytics and reporting should count stored records, not just clicks.

I call every hop between Submit and a person reading the message the enquiry path: browser, form handler, spam filter, mail sender, DNS authentication, receiving mailbox and any automation afterwards. A break at any hop looks the same from outside: silence.

Contact form not sending emails? Run this end-to-end test

Run it after any change to the site, host, DNS or email provider, and at least quarterly. Label every test ("LEAD-PATH TEST" plus the date) so nobody mistakes it for a real lead.

In Gmail on the web, open the message, choose More beside Reply, then Show original. The Authentication-Results field is where the receiving server records its SPF, DKIM and DMARC verdicts, as defined in RFC 8601.

Why a contact form stops sending emails: where enquiries vanish

When a notification disappears, the cause is one of six things. Check them in this order.

1. Missing or broken email authentication. Three DNS-based checks tell a receiving server your mail is genuine. SPF lists which servers may send for your domain (RFC 7208). DKIM signs each message cryptographically (RFC 6376). DMARC lets the domain owner say what to do when a message fails (RFC 9989, which replaced RFC 7489).

Gmail's guidelines say that since 1 February 2024 every sender to Gmail accounts needs SPF or DKIM, and senders above 5,000 messages a day need all three. Unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error". Yahoo sets the same minimum. A form sends a handful of emails a day, so the 5,000 tier doesn't apply to you but the all-sender rules do. I found no provider statement on what happens to one non-compliant message, so fix authentication rather than bet on leniency.

One trap: SPF allows at most 10 DNS-lookup terms per check, and going over returns a permanent error. A newsletter tool, a CRM and a helpdesk in one record can quietly break it.

2. A From address that pretends to be the visitor. Some forms put the visitor's address in the From field, so the notification claims to come from a Gmail address while leaving your server. Google's guidelines say not to impersonate Gmail From headers, and a From domain that doesn't align with the SPF or DKIM domain fails DMARC alignment. Send from an address on your own domain and put the visitor in Reply-To. The setting's name differs by form tool, so check yours.

3. Shared-host sending limits. In cPanel's documentation, once a domain hits its hourly limit the server accepts the extra messages, then queues and retries them under a percentage setting, and a domain with too many failed or deferred messages is temporarily blocked from sending. Other hosts differ, so ask yours for the limit and the mail log.

4. Your own notification gets filtered. A subject like "New message from website" is easy for filters and tired humans to ignore. Put the visitor's name and the service they asked about in it.

5. Captcha or validation failure. Cloudflare's Turnstile documentation says a token is valid for 300 seconds and can be validated once; a late or repeated submission fails with timeout-or-duplicate. Step 8 of the test catches this.

6. Stored but not sent, nothing stored, or one mailbox. Some tools only email. The plugin page for Flamingo, the companion to Contact Form 7, says Contact Form 7 doesn't store submitted messages itself, so a failed email means a lost lead. One recipient adds another risk: a full inbox, a forwarding rule, or a colleague who has left.

Watch: How SPF, DKIM and DMARC protect your email

A 49-second explainer of what the three records do, from the Google Workspace channel. The definitions here come from the RFCs; I haven't checked every claim in the video.

Watch on YouTube: How SPF, DKIM and DMARC protect your email

Spam control without blocking real people

Spam control fails two ways. Too little, and bots flood the inbox until your team stops reading notifications or marks them as spam; Google's guidelines ask senders to keep the spam rate in Postmaster Tools below 0.3%. Too much, and genuine people are turned away without anyone knowing. Use several gentle layers:

• A hidden honeypot field that humans never see and simple bots fill in.
• A bot challenge checked on the server. Turnstile's documentation says you must call its Siteverify API; the widget alone doesn't protect the form.
• Rate limits per IP address, set well above human speed.
• A held state, not a bin. Store suspicious submissions as "held" and review them weekly.
• No blunt keyword blocks. Blocking "marketing" also blocks the supplier you want to hear from.

Then test the filters with awkward but real input: a name in Devanagari script, an address like name+test@example.com, a long message with a link, and a phone number with a country code. All four should be accepted; if one is held, you've found a false positive before a customer did.

Key figures behind these checks

• 5,000 messages a day: the point above which Gmail requires SPF, DKIM and DMARC together; below it, SPF or DKIM is required of all senders, both from 1 February 2024. Source: Google email sender guidelines.
• Below 0.3%: the spam rate Google asks senders to stay under, as reported in Postmaster Tools (guidelines page read 6 November 2026). Source: Google email sender guidelines.
• 10 DNS-lookup terms: the most an SPF check may evaluate before returning a permanent error (RFC 7208, April 2014). Source: RFC 7208, section 4.6.4.
• 300 seconds: how long a Turnstile token stays valid; it can be validated once (documentation read 6 November 2026). Source: Cloudflare Turnstile server-side validation.

Not sure where your enquiries stop? We can trace the path from form to inbox, CRM and WhatsApp with you and test every hop.

Backup path: store, notify and alert

A reliable enquiry path keeps three independent things: a stored record, an authenticated notification, and an alert that fires when the two disagree. Email is a message, not a guarantee of delivery.

1. Store every submission first, before any email is attempted, in your CMS database or CRM, with a timestamp and a "notified at" field.
2. Notify more than one place. Send an authenticated email to a shared mailbox plus one other person, and add a second channel such as a WhatsApp alert through a WhatsApp funnel setup. See also WhatsApp vs contact forms for Indian businesses.
3. Alert on disagreement. A scheduled job can flag stored submissions older than ten minutes with an empty "notified at" field. Ten minutes is my suggestion; match it to your volume.
4. Keep a lead log with submitted, stored and notified times and who received it, so you know which hop to open first.

A green run is not a delivered lead

An automation after the form reports success when its steps executed, not when a lead arrived. One operator wrote on X on 23 October 2026 about 23 days of successful runs with no new leads, the third time that year. That is one post I couldn't verify independently, and it says nothing about how often this happens. I use it only to show the pattern.

Picture it, hypothetically: a form-to-CRM workflow ends with a green tick because every step got a response, while the CRM call quietly creates nothing. Or the trigger stops receiving data, so no runs happen, which reads as "no errors". Monitor the result, not only the job status:

• Count new lead records per day and per week, and watch the last-created record's timestamp.
• Set a daily "no new leads" alert with a threshold based on your normal volume. One quiet bank holiday isn't an incident; five quiet weekdays might be.
• Force a failure to test the error handler, after reading your tool's own documentation on when it fires.

n8n documents this clearly. Its docs say an error workflow starts with an Error Trigger and only runs when an automatic workflow errors: "You can't test error workflows when running workflows manually." A Stop and Error node makes a workflow fail on purpose, so a real test means adding it to a non-production copy and letting the normal trigger fire. Other tools differ, so read yours first.

An error handler fires only on a failed run, so it can't tell you the trigger went quiet. That's why the outcome count isn't optional. If your automations touch customer data and you want them mapped, logged and monitored, that's the work behind our AI automation consultancy.

The weekly canary submission

A canary submission is a labelled test enquiry sent on a schedule, so a break shows up in your own check instead of a lost customer. Pick a fixed slot, say Monday 10:00 IST, and submit the live form from a test identity on another provider. Write "CANARY" and the date in the message so nobody replies. Log one line per hop; a pass looks like this (times illustrative):

Any missing row is an incident: open the log at the first hop that failed. If you automate the canary itself, alert yourself when the expected arrival doesn't happen, or the check can fail unnoticed.

Forms, DNS records and mail settings drift as plugins, hosts and providers change. We can audit the whole delivery chain and set up the weekly check for you.

Reference reading

• Google: Email sender guidelines
• IETF RFC 9989: DMARC specification
• n8n documentation: Error Trigger node
• Cloudflare: Turnstile server-side validation

Frequently Asked Questions

Why is my contact form not sending emails?

The break is usually at one of six points: the form handler fails, the message isn't authenticated, the host limits outgoing mail, a spam filter junks it, a captcha rejects the visitor, or the mailbox is full or unwatched. The end-to-end test shows which hop fails first.

Why do my contact form emails go to spam?

Common causes are failing SPF, DKIM or DMARC results, a From address that pretends to be the visitor, and vague repeated subject lines. Open the full headers of a spammed message and read the Authentication-Results line first.

How often should I test my contact form?

Test it after every change to the site, host, DNS or email provider, and send a labelled canary submission every week. Weekly is my recommendation, not a standard.

Should I store form submissions in a database as well as emailing them?

Yes. Email can fail without telling anyone, and some form tools keep no copy. A stored record lets you recover a lost lead and compare stored against notified counts. It's personal data, so limit access and set a retention period.

Does a green automation run mean the lead arrived?

No. A green run means the steps executed. Check that a new lead record exists, that the last-created timestamp is recent, and that a daily no-new-leads alert is in place.