The form still looks fine. A visitor fills in their name, types a short note about the job they need done, and clicks Send. A friendly “Thank you, we’ll be in touch soon” appears on the screen. Everything about the experience says the message went through.
Then nothing happens. No email lands in your inbox. Nobody on your team knows the request exists. The visitor waits a day or two, hears nothing, and calls the next business on the list.
This is one of the quietest ways a local business loses leads, and it shows up most often right after a change nobody thought was related to the contact form: a move to a new web host, a switch of domain registrar, a DNS change, or a jump from one email provider to another. The website keeps working. The phone keeps ringing now and then. So it can take weeks before someone says, “Hey, when was the last time we got a form submission?”
If you have recently moved your website, or you are about to, this article explains what is going on behind that thank-you message, how to find out whether your form emails are actually arriving, and what a proper fix looks like.
Why the Form Says “Thank You” While the Email Goes Nowhere
A contact form does two separate jobs. First, it accepts what the visitor typed. Second, it tries to send that information to you as an email. The thank-you message only confirms the first job. It has no idea whether the second one worked.
WordPress is honest about this in its own documentation. The developer reference for wp_mail(), the function most WordPress forms rely on to send notifications, notes that a successful result does not automatically mean the email was received. It only means the website handed the message off without an error. What happens after that handoff depends on the server, your domain’s settings, and the mailbox provider on the other end.
A hosting change touches all three. Here is where things usually go wrong.
The new server is sending mail your domain never vouched for
When your form sends a notification, it usually sends it “from” an address on your own domain, something like [email protected]. Mailbox providers such as Gmail and Outlook do not take that at face value. They check whether the server that actually sent the message is allowed to send mail for your domain.
Three records in your domain’s settings answer that question:
- SPF (Sender Policy Framework) is a published list of the servers allowed to send email for your domain.
- DKIM (DomainKeys Identified Mail) is a digital signature added to each message that proves it came from an approved sender and was not altered along the way.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving providers what to do when a message fails those checks, and can send you reports about it.
Your old host’s server may have been listed in your SPF record years ago. Your new host’s server is not. The SPF standard exists precisely so receivers can treat mail from unlisted servers with suspicion, and that is what they do. The form email gets flagged as possible spoofing, sent to spam, or rejected outright.
The big mailbox providers have also gotten stricter. Google’s email sender guidelines state that, starting February 1, 2024, anyone sending to Gmail accounts must set up SPF or DKIM for their sending domain, with additional requirements, including DMARC, for high-volume senders. A form notification is a small, low-volume message, but it is still judged by the same basic rules. Mail that would have slipped through a few years ago now gets filtered.
The new host may not send mail the way the old one did
Many websites send form notifications using the web server’s built-in mail function. It is the default, and on some older hosting setups it worked well enough for years. Plenty of hosts now limit or disable that kind of server mail, or allow it without configuring anything that would make it trustworthy to Gmail or Outlook.
The more reliable approach is authenticated sending. The website logs in to a real mail service, either your business email provider or a transactional email service built for automated messages, and sends through it. That service is already set up to pass SPF and DKIM checks for your domain. When a site moves to a new host and nobody reconnects authenticated sending, the form quietly falls back to server mail, and deliverability falls with it.
Records that got dropped or changed during the move
Moving a website often means moving your DNS, the settings that tell the internet where your website and email live. If the new DNS zone was built by copying only the records needed for the website, the ones for email can get left behind. That includes MX records, which tell the world where to deliver mail for your domain, along with the SPF, DKIM, and DMARC records described above.
Sometimes the damage is bigger than the form. If the MX records disappear, your regular business email can stop arriving too. More often, the MX records survive but the authentication records do not, so everyday email from your laptop still works while the website’s notifications fail. That mismatch is exactly why the problem stays hidden. “Our email is fine” feels like proof that nothing is wrong.
One more detail trips people up. Some forms are set to send “from” the visitor’s own address, so you can hit Reply and answer them directly. That sounds convenient, but it means your website is claiming to send mail as a Gmail or Yahoo user, which those providers’ own records will never allow. The cleaner setup sends from an address on your domain and puts the visitor’s address in the reply-to field. You still reply with one click, and the message passes authentication checks.
How to Tell If It Is Happening to You
The good news is that this problem is easy to confirm once you go looking. The bad news is that you have to go looking, because nothing on the website will warn you.
Start with a real test. Open your website on your phone, ideally using mobile data instead of your office Wi-Fi, and fill out the contact form the way a customer would. Use an outside address you can check, such as a personal Gmail account, in the email field. Then watch the inbox where notifications are supposed to arrive.
If nothing shows up within a few minutes, check the spam or junk folder in that inbox. Check any filtering or quarantine area your email provider uses. If the message is sitting in spam, that tells you the email is being sent but not trusted, which points toward authentication. If it is nowhere at all, the website may not be sending mail successfully in the first place, or the message is being rejected before it reaches you.
Next, compare what your website received with what your inbox received. Many form tools can save each submission inside the website itself. If yours does, log in and look at the stored entries. If there are entries from the last few weeks that never showed up as emails, you have your answer, and you also have a list of people to call back today.
Finally, look at the calendar. If form leads dropped off around the same week you changed hosts, switched email providers, or had someone “clean up” your DNS, treat that as a strong clue. Leads rarely fall to zero overnight for no reason.
A Short Check to Run After Any Hosting or DNS Change
The best time to catch a broken form is the day of the move. If you are still planning a switch, our access checklist for changing website providers covers what to gather before the handoff, including your domain and DNS logins. Once the move is done, run through this list before anyone calls it finished:
- Submit every form on the site, including contact, quote request, booking, and newsletter signup, using an outside email address.
- Confirm each notification arrives in the correct inbox, outside the spam folder, within a few minutes.
- Reply to one of the test notifications and make sure the reply goes to the test address and lands somewhere real.
- Compare the DNS records on the new setup with the old ones, paying close attention to MX, SPF, DKIM, and DMARC entries.
- Make sure the SPF record includes whatever service the website now uses to send mail, and that there is only one SPF record for the domain.
- Check that the form is connected to authenticated sending through your email provider or a transactional email service, rather than relying on the server’s built-in mail.
- Confirm the form saves entries inside the website, so a delivery problem never means a lost lead.
- Send a regular email from your business address to an outside account, and one back, to confirm everyday email still flows both ways.
None of these steps take long. Together they cover the mail path that a hosting change is most likely to disturb. If your forms also run on plugins, it is worth pairing this with the routine in our article on why website forms break after plugin updates, since updates and migrations often happen around the same time and either one can be the culprit.
Fixing It So It Stays Fixed
Patching the immediate problem is usually straightforward. Making sure it does not come back takes a few deliberate choices.
Set up authenticated sending first. Connect the website to a proper mail service and send notifications through it. Then publish or update the DNS records that service requires, typically an SPF entry and a DKIM key, so receiving providers can verify that your website is allowed to send for your domain. Once those pass, add a DMARC record. Even a monitoring-only DMARC policy gives you reports showing which systems are sending mail as your domain and whether they pass. The DMARC.org overview explains why this matters for businesses with several systems sending mail, which describes nearly every business with a website, an email provider, and a booking or invoicing tool.
Use an address on your own domain as the sender, and put the visitor’s address in reply-to. This one setting removes a common reason form emails fail authentication, and it keeps replying just as easy as before.
Store every submission inside the website. Email is a notification, and it should never be the only place a lead lives. When entries are saved on the site, a delivery problem becomes an inconvenience you can recover from. You log in, see who reached out, and call them. Without stored entries, those people are simply gone.
Send notifications to more than one person, or to a shared inbox someone checks daily. A single recipient on vacation, or a single mailbox that fills up, is another quiet way leads slip away.
Then put form testing on the calendar. Test after every hosting change, DNS change, email provider switch, and major site update. Test once a month even when nothing has changed, because mailbox providers adjust their filtering over time and your setup can drift without anyone touching it.
Someone Has to Own the Form After Every Change
The pattern behind most lost-lead stories is simple. Each person involved in a move did their own part correctly. The new host moved the website. The email provider kept business email running. The person who updated DNS got the website loading on the new server. Nobody owned the space in between, where the contact form hands a message to a mail server and hopes for the best.
That gap needs an owner. Someone has to know how the form sends mail, which records support it, and how to test it. That same person has to actually run the test after every infrastructure change, and again on a regular schedule. For a busy owner running a plumbing company, a dental office, a law practice, or a church, that is one more technical chore on a list that is already too long.
This is the kind of work NorthMac handles every day. With a NorthMac managed website, we build your site and launch it in about 7 business days once we have what we need. After that, we take care of hosting, security, unlimited updates, and ongoing care for one monthly price. Contact and lead forms are set up, routed to where you will actually see them, and tested so they deliver. If a form goes down, that fix skips the line. Whoever runs your site, make it a habit to test every form after any hosting or DNS change.
Getting started is simple. The first month is $47, which covers the start of your build. From month two, the regular rate is $397 per month. It is month-to-month, you can cancel any time, and the $47 is a one-time start fee with no contract attached.
If you would rather stop wondering whether your contact form is working, start your managed website for $47 and see what’s included.
