How to Fix a Contact Form That Stopped Sending Email

The enquiries just stopped. The form still sits on your contact page, visitors still fill it in, the thank-you message still appears, and yet nothing reaches your inbox. Owners usually blame the form, reinstall the plugin, and lose another week. In most cases the form is doing its job exactly as before. What changed is the journey its messages take, because a form submission leaves your website dressed as email from your domain, and the receiving world has got much stricter about checking that claim.

First, find out what "stopped" actually means

Submit a test entry yourself, with a name you will recognise. Then look properly: check the spam folder of the destination inbox, not just the inbox itself. If the test is sitting in spam, your form sends fine and the problem is trust, which the checks below will pin down. If it is nowhere, try changing the destination temporarily to a personal Gmail or Outlook address and submit again. A test that arrives at Gmail but never at your domain mailbox tells you the sending side works and the receiving side is discarding it. A test that arrives nowhere at all means the mail is being refused or never sent. Five minutes of testing splits one vague problem into a specific one.

The usual cause: the form sends as you, from a server with no permission

Here is the part nobody sees. When a visitor submits your form, your website typically sends the notification from the web server itself, using an address on your domain, often your own. But your SPF record, the DNS list of servers allowed to send for your domain, usually names your email provider and nothing else. The web server is not on the list. Receiving servers compare the two, find a stranger claiming to be you, and quietly file the message in spam or drop it entirely. Run your domain through the SPF, DKIM and DMARC Checker and look at which senders your SPF record actually authorises.

The second cause: DMARC turned a quiet failure into a hard refusal

For years, mail that failed these checks was often delivered anyway, with a raised eyebrow. A DMARC record set to reject changes that. If your domain publishes a strict DMARC policy, and your website's form mail cannot prove itself, receivers are instructed to refuse it outright, and they obey. This is why forms so often break right after a business sets up email properly with Google or Microsoft, or tightens its records following good advice. The records are doing their job. The form is the one thing still sending the old, unproven way.

The third cause: something moved

Forms rarely break on a random Tuesday. Ask what changed just before the messages stopped. The site moved to a new host, the domain moved to a new registrar, email moved to a new provider, or a plugin updated and reset its settings. Any of these can strand the form: the new web server is not the one the old records allowed, or the form is still trying to send through a service the business no longer uses. Naming the change usually names the fix.

The fix: make the form send through a real mailbox

The lasting repair is to stop the form pretending. Configure your website to send its mail through your actual email service, logged in as a real mailbox on your domain, instead of the web server sending unauthenticated mail in your name. Most form plugins support this through an SMTP setting or a companion plugin, and your email provider publishes the server details to enter. Once the form sends as a genuine, signed-in mailbox, your SPF record covers it, DKIM can sign it, and DMARC passes, because the claim is finally true. If your form only needs to notify you, that mailbox can be a dedicated one on your domain, created purely for this job.

Prove it is fixed

Do not trust the thank-you message; it appears whether the mail survives or not. Submit a real test entry and watch it arrive in the inbox, not the spam folder. Send one from an outside address to your domain as well and judge how your domain's ordinary mail is treated using the Email Deliverability Test, which shows the SPF, DKIM and DMARC verdicts a receiver computes. Then submit one more form entry for luck, and check the spam folder a final time.

What to do first

Submit a test entry now and check the spam folder of the destination inbox, then run the authentication checker on your domain. Between those two results you will know whether your form mail is distrusted, refused, or never sent, and each answer has a known fix. Most owners find the whole mystery was one web server missing from an SPF record, and that is a ten-minute repair once you know it is the one to make.