Why your form converts and your business does not

A nonprofit had two contact forms on its website. Both worked. You filled one in, clicked send, and a green message said, "Thank you; we will be in touch."

For weeks, every submission got that message. And not one of those messages landed. No inbox, no spam folder, no error, no trace. The people who filled in that form believed they had reached someone. Nobody had.

The forms were not broken. That is the part worth sitting with. They were doing exactly what they were built to do, right up to the last step, and the last step was happening somewhere nobody could see.

Think about ordering in a busy restaurant. The server listens, writes it down, says got it, and walks away. You relax. You have ordered.

What happened is that someone heard you. Whether that ticket ever reached the kitchen is a separate matter, and you can't see it from your table.

A form's thank-you message is the server writing it down. It confirms you were heard. It says nothing about the kitchen.

Kitchens have a bell for exactly this reason. It rings when a plate is up, and it rings in the kitchen, where the person who ordered cannot hear it. Every confirmation you have ever seen on a website is a bell that rings on your side of the wall.

Those are two different events, separated by every system between your website and the person who is supposed to reply. Email routing. Spam policy. A CRM, which is any system that keeps your customers and inquiries in one place. A forwarding rule somebody set up in 2019 and forgot. The success message is written before any of that happens, and it says the same thing whether the rest of the chain worked or silently failed.

Nobody designed it to lie. It answers the question it was asked: Did the submission reach the server? Then the page moves on.

Skip this part if you already know it. If you don't, everything after it will make more sense, and you can tell your web person exactly where to look instead of asking why the form is broken.

Filling in a form looks like one action. It is four. They happen on four different machines, owned by up to four different companies, and only the first one has anything to do with your website.

One. The browser hands the form to your web server. A web server is a computer somewhere that holds your pages and answers when a visitor asks for one. Yours lives at your hosting company. When the visitor clicks send, their browser passes the typed answers to that computer. This is the customer speaking their order out loud.

Two. Your web server writes a message and hands it to a mail server. A mail server is a different machine whose only job is carrying email. Your web server does not deliver email any more than a waiter cooks. It writes the order down and passes it along.

Three. Your visitor is told it worked. Notice where we are. We are at step two. The green thank-you message is your web server confirming it received the order. That is the waiter saying, "Got it and walking away," and it is the last thing the visitor will ever hear.

Four. The mail provider at the other end decides whether to accept the message. Google, Microsoft, your office mail host whoever runs the inbox that is supposed to receive it. They have no obligation to accept it. They inspect it first, and if they do not like what they see, they can file it in a spam folder or refuse it at the door.

Those four steps make up the entire article. The customer is thanked at step three. Only step four can fail.

The From line, also called the From header. Every email carries a line saying who it claims to be from. It is a claim, not a fact, the same way the return address on a package is whatever the sender wrote there. Nothing stops a machine from writing somebody else's name on it.

Authentication, which in practice means SPF and DKIM. These two checks turn the claim into something testable.

• SPF is a public list a company publishes naming the machines allowed to send email using its name.
• DKIM is a signature stamped into the message itself.

Together, they are the table number on the ticket. Without one, the email has a plate and nowhere to send it.

DMARC. Every kitchen decides for itself what to do with a ticket whose table number doesn't check out, and it pins that decision up by the door so anyone walking past can read it. That is DMARC. Any company publishes one; anybody can read it, and the formal standard, RFC 7489, allows exactly three rules.

• None means "no specific action." The ticket goes through, and somebody further down the line can worry about it.
• Quarantine means treat it as suspicious. That is the plate set on the side counter, the one that never goes out.
• Reject means, in the standard's own words, that "rejection SHOULD occur during the SMTP transaction." SMTP is the language mail servers speak to each other, and a transaction is one short conversation between two of them. So a reject is the runner stopped in the doorway, mid-sentence, before the ticket is ever taken in.

Now read those three back and notice whose kitchen is being described. This is the only word on this page that names a decision you do not get to make.

A bounce. When a kitchen refuses a ticket, it hands it back to whoever carried it in. That is a bounce, the notice that comes back when a message is refused and somebody bothers to send one. Here is the part that matters to you: the runner who carried your ticket in is your website, not you. So the refusal is handed to a machine, which files it somewhere nobody has ever opened and goes back to work. No person is involved at any point in that, which is why a refused inquiry and a delivered one look exactly the same from where you are sitting.

A CRM. A drawer with your customers and inquiries in it, from a spreadsheet upward. Filing the ticket in the drawer is one more thing that can happen without the kitchen ever cooking. It is a fourth place a message gets recorded as received while nobody has read a word of it, and a record is not a reply.

None of this is proprietary. Every company's instruction is published where anyone can read it. Your web person can read all four of these back to you in under a minute:

Read live on September 10, 2026 by querying each domain's public `_dmarc` record. Your web person can reproduce every row with one command: `nslookup -type=TXT _dmarc.yahoo.com`. These policies change, so read them, do not quote this table back at anyone in a year.

That table is why "will my form emails get through" has no single answer. It depends on which company runs the inbox at the other end, and those four companies have made four different decisions.

And a `p=none` is not a promise of delivery. Google's own sender guidelines are blunt about the case where a message claims to be from Gmail and was not sent by Gmail: "Don't impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery." The same page says messages that are not authenticated "might be marked as spam or rejected with a 5.7.26 error." Since February 1, 2024, anyone sending more than 5,000 messages a day to Gmail accounts has had to authenticate with SPF, DKIM and DMARC and keep their spam complaint rate under 0.3 percent.

Note what a 5.7.26 is. It is not a lost letter. It is a numbered refusal, issued by a machine that read the message and declined it. Somebody said no, in writing, and the writing went to a server.

Here is the part that surprised me, and it is why this article exists in the form it does. Every major platform documents this failure in its own help center, in its own words, and not one of them tells the owner to go and check.

A plugin is a small piece of software bolted onto a website to add a feature, and Contact Form 7 is the most-installed plugin for adding forms anywhere on the web. Its author answers this question directly. Under the heading I see a response message "Thank you for your message. It has been sent." with green border, but I never receive a mail for that, he writes: "Showing the green border message means that the PHP function for sending the mail has certainly completed successfully. So if you can't receive the mail, it's highly possible that the mail has been kidnapped or killed after that."

Kidnapped or killed. From the person who wrote the software.

The same project publishes a named configuration error for exactly the fault described later in this article: Sender email address does not belong to the site domain. Its mail setup guide states the rule in one line: the From field "should be an email address that belongs to the same domain as the web site."

Wix says it too, in its own troubleshooting page: if the log says the email was sent, the message may still be filtered or blocked by the recipient's provider. Squarespace puts the remedy in its site launch checklist, which asks you to send test submissions to every form on your site and confirm they reach the places you chose.

So the knowledge is not hidden and nobody is hiding it. It is filed under troubleshooting, which is where you go after you suspect something. Nothing on any of these platforms tells a working owner, who suspects nothing, that the green message they have been trusting for two years was never evidence of anything.

Here is what makes this expensive. From where you sit, these feel the same:

Leads are arriving and they are not turning into business. People fill in the form, you reply, nothing closes. The lead is real and the fit is wrong.

Leads are not arriving at all. The form reports success and the message dies between the website and a human. There is no lead. There is a person who thinks they contacted you.

Search either one and you get confident answers. Ask why your website gets leads but no sales and you will be told your lead quality is poor, your messaging is unclear, your form asks too many questions, your form is only on the contact page, your traffic is unqualified. Those are real causes and the people writing about them are not wrong.

But every one of those answers assumes the message arrived. If your form is not delivering, you can rewrite your copy for six months and change nothing, because the problem was never on the page.

The cause was one line of configuration in each form.

Both forms sent their notification with the From address set to the site administrator's email, and that address was at gmail.com. So a message claiming to be from a gmail.com address was being sent from the organization's own web server, which is not a machine gmail.com authorizes to send its mail.

That is the fault Contact Form 7 has an official error page for, and it is worth being exact about what happens next, because the honest version is less dramatic than the version I first wrote and considerably more useful.

Google does not publish a blanket refuse instruction for gmail.com. Checked on September 10, 2026, gmail.com publishes `p=none`. What Google publishes instead is guidance, quoted in full earlier: do not impersonate Gmail From: headers, a quarantine enforcement policy is coming, and unauthenticated mail "might be marked as spam or rejected with a 5.7.26 error." Might. The receiving provider decides, message by message, and it does not have to explain itself.

So the message was not lost in transit. It was inspected and set aside, every single time, by systems working exactly as designed. It is the expo reading a ticket with no table number and putting it face down. Nothing was broken. Somebody read it and declined it.

And because that happened after the form had already thanked the visitor, nothing on the website ever showed a problem. There was no error to notice.

Had the administrator's address been at yahoo.com or aol.com instead, there would have been no might about it. Both of those domains publish `p=reject` today, and the standard says a reject SHOULD happen during the delivery attempt. Same misconfiguration, same silence for the owner, a harder wall.

The organization had no idea. The people filling in that form had no idea. The only evidence was an absence, and an absence does not announce itself.

Almost everybody who hits this problem searches for it as a software fault. They type contact form not sending email wordpress, or contact form 7 not sending, or squarespace contact form not sending email, or microsoft forms not sending email. Out of seventy five things people actually type around this, thirty one name a platform and four describe a business outcome.

That is worth knowing because it tells you where the good answers are, and where they stop. Those searches take you to plugin documentation, which is genuinely useful and will walk you through mail settings and SMTP and authentication records. What none of them will tell you is that this is a revenue problem with a date attached, or how long yours has been running.

You do not have a WordPress problem or a Squarespace problem. You have a delivery problem that your platform happens to be sitting in front of.

You do not need a consultant, a tool or a budget to find out which problem you have.

Submit your own form. Do it from your phone, on cell service rather than your office wifi, with an email address that is not connected to your business. Then watch what happens.

You are watching for three things, and they are the whole test:

Does it arrive. Not in a log, not in a dashboard. In the inbox of the person who is supposed to reply. Check their spam folder too, and check it with them rather than asking whether they looked.

Does it carry a source. When it arrives, can anyone tell where that person came from? A search, an ad, a referral, a business listing? If every inquiry looks identical, you cannot tell which of your marketing works, and you will keep paying for all of it.

Does anyone own the reply. Not a rota, not an assumption. A name. If the answer is that it goes to a shared mailbox and someone usually picks it up, that is the joint where leads go quiet, and it is a different article.

If a message fails the first test, stop. Nothing else matters until that is fixed.

If you run that test and the message arrives, carries a source, and has an owner with a name, then your forms are fine.

Your problem is demand, or fit, or follow-up speed, and this article cannot help you. Go and read one of the eight good ones about lead quality, because they are right and you are their reader.

That is worth saying plainly, because most articles about this are written by people who would like to sell you a fix. If your plumbing works, you do not need a plumber.

And I should tell you how I came to write this, because it does not flatter me. In September a marketing agency sent a quote request through my own contact form. The message arrived carrying a line that read "I am not a robot: Yes." That is a text box somebody types into. Nothing on my server ever looked at it, and the form forwarded the message anyway.

So I audited every form on my own website: thirty-five of them, across thirty-one pages, and not one had a working check behind it. I had been writing about other people's forms while mine went unexamined, and I only looked because a stranger's spam made me. The ten minute test above is one I had not run on my own site until this week. I have made this mistake on my own website, which is the only reason I can describe it accurately.

Most owners in this position are not staring at a dashboard. They are running a business, and the website is one of the quieter things they own.

So the way this actually shows up is not alarming. It is a slow month that felt like any other slow month. You get work from referrals, from repeat customers, from the van in the parking lot, and those keep coming, so nothing looks wrong. A form that delivers nothing produces the same silence as a form nobody filled in.

That is the whole difficulty. There is no bad number to notice, because the number that would have told you never got created. You cannot tell a good month from a lucky one, and a broken form is invisible inside that same gap.

The pattern underneath is not really about forms.

Every system in the chain reports on the part it can see. The form knows the server answered. The mail server knows it handed the message onward. The CRM knows a record was created. Each one honestly reports success for its own step, and no system is asked whether the person at the end got what they needed.

So the failure lands in the gaps between them, where every component says fine and the outcome is still nothing. Server, rail, line, expo. Each one honestly did its own step, and nobody owned the table. The only way to see it is to walk one order the whole way through yourself and watch a plate come out.

That is a ten minute job. Most businesses have never done it once.

Related: if your leads do arrive and then stall on their way to a human, that is the lead handoff nobody owns. If the wider question is where your funnel loses people, start with most funnels are a form and a hope.

Robert Dove, Dove Web Consulting, Kansas City. Written 2026-09-09. The nonprofit incident is anonymized with permission and is drawn from work performed in August 2026.