The form says thank you and the lead never reaches your inbox

What happens between the submit button and your mailbox

Most website forms do not send email through your mail provider. They hand the message to whatever mail software is installed on the web server, which sends it directly from the hosting company's IP address, using whatever From address the form was configured with years ago. Neither of those things has any relationship to your Google Workspace or Microsoft 365 account.

The From address is usually the first fault. A great many forms are set to send as the visitor, so the message arrives claiming to come from someone@gmail.com. A web server in a hosting rack has no authority to send mail for gmail.com, and every major receiver now checks. The message gets junked or rejected. The variant that looks safer, sending as info@yourdomain.com, fails the same check for the same reason unless your domain explicitly authorizes that server.

The second fault is reputation. On shared hosting your outbound mail leaves from an IP address shared with hundreds of unrelated sites, some of which are sending things you would not want to be associated with. You inherit that reputation. Nothing you write in the email changes it.

• ●Sending as the visitor's address is the single most common cause of junked form notifications
• ●A hosting server sending as your domain fails authentication unless your DNS says otherwise
• ●Shared hosting IP reputation is not yours to control and not yours to repair
• ●Rejections often produce no bounce you will ever see, because the bounce goes back to the server, not to you
• ●Filtering decisions are made by the recipient's provider, so the same message can reach one colleague and not another

SPF, DKIM and DMARC in the words your host will use

Three DNS records decide whether a receiving provider believes your mail is really yours. SPF lists which servers are allowed to send for your domain. DKIM attaches a cryptographic signature that proves the message was not altered and came from an authorized sender. DMARC ties the two together, tells receivers what to do when a message fails, and can send you reports about who is sending as you.

Google's published email sender guidelines require every sender to have at least SPF or DKIM in place, and impose the fuller set, including DMARC, on bulk senders above their volume threshold. Yahoo's sender requirements are aligned with them. Microsoft documents the same three records for custom domains on Microsoft 365.

This is where honesty matters more than urgency. A business sending a handful of form notifications a day is nowhere near bulk sender territory, and no one needs to panic about unsubscribe headers or spam complaint rates. The authentication baseline still applies, because it is the check that is failing. But if someone is selling you a deliverability program on the strength of rules written for senders with tens of thousands of daily messages, that is not your situation.

• ●SPF: which servers may send for your domain
• ●DKIM: a signature proving the message is authentic and unmodified
• ●DMARC: the policy for failures, plus reporting on who sends as you
• ●Alignment matters as much as the records themselves, so the visible From domain has to match what passes
• ●Adding a record is not enough if the form still sends from an address the record does not cover

Three changes that resolve most cases

First, stop letting the web server send mail on its own. Route form notifications through authenticated SMTP on a domain you control, either your existing Workspace or Microsoft 365 mailbox or a dedicated transactional email service. Now the message comes from an infrastructure your DNS already authorizes, and you get logs showing whether it was accepted.

Second, fix the addresses. The From address should be one at your own domain that you can authenticate. The customer's address belongs in Reply-To, which is what your reply button actually uses, so hitting reply still writes to the customer. This one change costs nothing and resolves a surprising share of cases on its own.

Third, and most important, stop treating email as the record. Every submission should be written to a database or pushed into your CRM the moment it happens, with the email acting only as a notification that something arrived. When a message is delayed or junked, the lead still exists somewhere you can look. Without that, a delivery failure is indistinguishable from nobody having contacted you at all, which is exactly why these outages run for months undetected.

• ●Authenticated SMTP or a transactional provider instead of the server's own mail software
• ●From: an address at your domain. Reply-To: the customer
• ●Every submission stored server-side, with a timestamp, before the email is attempted
• ●An alert when the send fails, so silence stops meaning success
• ●A second recipient at a different provider, so one filter cannot hide everything

When the problem is not deliverability, and when to leave it alone

Before rebuilding anything, rule out the simpler explanations. Notifications going to a shared inbox nobody watches. An old forwarding rule pointing at a former employee. A colleague who once marked a notification as spam, training the filter for the whole account. A security or spam plugin on the site silently discarding submissions it judges to be bot traffic, including real ones. Messages that do arrive but sit in a promotions tab. And leads that were never emails to begin with, because they came through Google Business Profile messages or a marketplace inbox that only notifies inside its own app.

There is also a version of this work that makes things worse. Tightening a DMARC policy to reject before you have inventoried everything that sends as your domain will take down your invoicing software, your scheduler, your newsletter, and your appointment reminders in one move, and the failures will be silent by design. Start in monitoring mode, read the reports for a few weeks, and enforce only once you know the full list. If your form has always worked and you receive a modest number of leads a month, verify authentication and leave the rest alone. There is no prize for a hardened mail configuration at a business that does not send mail.

How to confirm it is actually fixed

Test from outside your own network and your own devices. Submit the live form from a phone on cellular data, sending to addresses at more than one provider, at minimum a Gmail address and a Microsoft-hosted one, plus any address your team actually uses. Then open the received message and view its original headers. You are looking for the authentication results line to show passes rather than failures or neutrals. Screenshots of an inbox tell you nothing about the message that did not arrive.

Then confirm the second half: that a record of the submission exists outside email. Open the database table or the CRM and check that the test lead is there with the right timestamp and fields. If it is only in your inbox, the failure mode you just fixed can return the next time a provider adjusts its filters, and you will find out the same way you did last time.

Keep this on a schedule. Domains change hands, DNS gets edited during a hosting move, a plugin update rewrites a From address, and mail providers keep raising the bar. A monthly test that takes two minutes is the difference between finding out yourself and finding out from a customer who says they filled out the form last week.

• ●Test from cellular data, not from the office network
• ●Send to at least two different mail providers and view the raw headers
• ●Confirm the submission exists in the database or CRM, not only in email
• ●Turn on DMARC reporting and read it before enforcing anything
• ●Re-test after any hosting migration, DNS edit, or form plugin update

Frequently asked questions