Why Is My Contact Form Not Sending Emails?

A customer tells you they filled out your form last week. You never saw it. Now you are wondering how many others did the same thing. Website form submissions not showing up is one of the most expensive website faults there is, because nothing errors out and nobody complains until a job is already lost. The good news is that contact form submissions not received almost always trace back to one of six causes, and they have a reliable order of likelihood. Work them top to bottom and stop when you find yours.

Website form submissions not showing up: the six causes, ranked

This ranking comes from actually chasing these down on client sites, not from a generic list. The first two account for most of what we find.

1. It is in spam, or a rule is filing it somewhere you never look

Start here even though it feels too obvious. Automated mail from a website looks a lot like bulk mail to a filter: same sender every time, same subject line, often a link in the body. Once one message gets marked as junk by anyone in your organization, the rest tend to follow.

The check: in Gmail, search in:anywhere plus part of your form's subject line, because a plain inbox search skips spam and trash. In Outlook, search Junk Email and Deleted Items separately. Then open your filters. Gmail keeps them under Settings, Filters and Blocked Addresses. Outlook keeps them under Rules. We have found forwarding rules set up years earlier by a former office manager, quietly diverting every inquiry to a mailbox nobody owns anymore.

The fix: mark the message Not Spam, then add the sending address to your contacts and create a rule that never sends it to junk. Two minutes.

2. Your domain has no SPF or DKIM, so the mail is being dropped without a bounce

This is the one that catches people out, because it fails silently and permanently. Your website sends mail claiming to be from your domain. Gmail and Outlook check whether your domain has published a record authorizing that server to send on its behalf. If there is no SPF record, no DKIM signature, and a DMARC policy that says reject or quarantine, the receiving server can throw the message away without telling anybody. Not even a bounce.

The check: go to MXToolbox, enter yourdomain.com and run the SPF Record Lookup. A missing record or a record that does not include your host is your answer. Then run a DMARC Lookup on the same domain. If DMARC says p=reject and SPF does not cover your web server, your form mail is being destroyed on arrival. Ten minutes including the reading.

The fix: stop sending through the web server. Route the form's mail through an authenticated mailbox with an SMTP plugin, or through a sending service like Postmark, Mailgun, SendGrid, or Amazon SES that gives you a DKIM key to publish. Then add the correct SPF include for whichever one you picked. DNS edits are the point where a lot of owners should hand it to somebody, because a bad SPF record breaks all of your email, not just the form.

3. An update broke the handler

Forms that worked for years stop on the day something updated. A form plugin changes how it hooks into mail. A security plugin starts blocking the submission endpoint. The host bumps PHP a version and a function the form relied on goes away. Nothing about the page looks different, which is why nobody notices.

The check: find the date of the last submission you know you received, then compare it against your update history. In WordPress that is under Tools, Site Health, or in the plugin update log your host keeps. If the two dates line up, you have your suspect. Five minutes.

The fix: roll the offending plugin back one version and test. If the form comes back, you know exactly what broke it and can then update deliberately with a test right after. This is also the argument for a staging site: updates get applied there first, the form gets submitted there first, and production never finds out the hard way.

4. Your host blocks outbound mail

Plenty of shared hosts block outbound SMTP on port 25, and some block 587 too, because spammers abused it for years. If your form plugin is configured to send directly, the connection is refused and the message never leaves the building. The plugin often reports success anyway, because handing the message to a queue counts as success from its point of view.

The check: search your host's documentation for "SMTP port" or "outbound mail", or open a ticket and ask two direct questions. Do you block outbound SMTP, and on which ports? Which relay do you want me to use instead? Fifteen minutes, most of which is waiting.

The fix: use the relay they name, or move to a sending service over an API instead of SMTP, which sidesteps port blocking entirely.

5. A honeypot or spam rule is eating real people

Anti-spam measures have false positives, and the false positives skew toward exactly the customers you want. A honeypot field catches anything that fills in a hidden input, which some password managers and accessibility tools do. A time-based rule rejects anything submitted in under a few seconds, which catches people who paste a prepared message. reCAPTCHA v3 scores users and quietly rejects the low scorers, and older browsers, VPN users, and privacy-focused setups score low.

The check: open your form plugin's spam folder or blocked-entry log and actually read the last fifty entries. Not the count, the entries. If there is a real name and a real question in there, you have found your problem. Five minutes.

The fix: loosen the rule rather than remove it. Turn off the time threshold before you turn off the honeypot, and if you use reCAPTCHA v3, set the score threshold so borderline submissions get flagged for review instead of rejected outright.

6. The notification goes to somebody who left

The address in the form settings was correct when the site launched. Then that person left, the mailbox got closed or converted to a shared alias nobody monitors, and the form kept doing exactly what it was told. Sometimes the address is fine and there is simply a typo in it, one that has been there since day one.

The check: open the notification settings and read the address character by character. Then send a test message to that exact address from your phone and see if it arrives anywhere. Two minutes.

The fix: point notifications at a shared mailbox that at least two people watch, not a personal one. Staff turnover should never be able to take your inquiries offline.

The ten-minute self-test anyone can run

Do this from your phone on cellular data, not from the office computer on the office network. You want the visitor's conditions, not yours.

1. 1Open your website on your phone and fill in the contact form like a real customer. Put the current date and time in the message body so you can find it later.
2. 2Note the exact minute you hit submit. Write it down.
3. 3Screenshot whatever the page says next. If there is no confirmation message at all, that is a separate problem worth fixing.
4. 4Wait five minutes, then search all mail for the timestamp you typed, spam and trash included.
5. 5If nothing arrived, log into your form plugin and check whether the entry is stored there. If the entry exists but the email did not arrive, it is a delivery problem, causes 1, 2 and 4. If there is no entry at all, it is a handler or spam-rule problem, causes 3 and 5.
6. 6Check the notification address in the settings against the mailbox you just searched.
7. 7Repeat the whole test after every plugin update, or put it on the calendar monthly.

The real problem: email is a bad system of record

You can fix every one of the six causes above and still be exposed, because they all share the same root. If email is the only place your leads exist, then any delivery failure is a permanent, invisible data loss. There is no record to check against. You cannot audit what you never received, and you will not know to look until a customer tells you they tried.

Every serious form tool already solves this. Gravity Forms, WPForms, Formidable, Fluent Forms and Contact Form 7 with a database add-on all keep entries in the site's database whether or not the email goes out. Turn that on. It costs nothing and it means a bad SPF record becomes an annoyance instead of a lost month. If you use a hosted form service like Formspark or Basin, check that entries are retained in the dashboard rather than forwarded and forgotten.

We take the same approach with Venbit Analytics, the first-party analytics we built for our own clients. Every form submission and every phone tap is stored in a leads inbox outside the email path, so if the notification never lands, the lead is still sitting there. That is not a reason to switch tools if your form plugin already stores entries. It is a reason to make sure something, anything, is holding a copy that does not depend on a mail server being in a good mood.

When to bring in a professional

Installing an SMTP plugin is genuinely doable for most owners, and if that fixes it, you are done. Where it gets tricky is DNS. Setting up SPF, DKIM and DMARC correctly is fiddly, and a mistake there can affect all of your business email, not just the form. If you have tried SMTP and messages still do not land, or you are not comfortable editing DNS records, that is the point to hand it over.

On our maintenance plans, starting at $99 a month, we set forms up to send through authenticated email, keep entries stored independently of the email, and test them as part of routine care so a stray update never quietly takes your inquiries offline. We are based near Seattle and handle site edits within one business day.