Contact Form Not Sending Emails: Diagnosis Guide

The symptom

Visitors submit the contact form and you never receive the email — or you receive some, but they consistently arrive in the spam/junk folder. Often the form shows a success message on screen ("Thank you, your message has been sent") while nothing reaches the inbox, which is the tell-tale sign the problem is delivery, not the form. Sometimes it worked for months and stopped after a host migration, a plugin update, or a change of email provider. In WordPress with Contact Form 7 you may instead see the red banner: "There was an error trying to send your message. Please try again later."

What it usually means

In the majority of cases the site is handing mail to the server's local sendmail/PHP mail() function without authentication, and receiving providers no longer trust that. Since early 2024 Gmail and Yahoo enforce authentication for senders, so an email claiming to be from you@yourdomain.com but sent from an unrelated server IP fails SPF/DKIM and is rejected or junked. The other frequent cause is a mismatch in the "From" address — the form sends as the visitor's address or a no-reply that your domain does not authorise — which triggers DMARC alignment failures. Less often, the mailbox that should receive the message has a full quota, a forwarding rule, or an over-aggressive spam filter.

What we check first

We start by reproducing a real submission and capturing what actually happens, in order. First, enable an email log — WP Mail SMTP, Fluent SMTP or the debug log — and confirm whether the message is even being handed off, or failing at PHP level (look in the server mail log, typically /var/log/mail.log or the host's Mail panel, for lines like "550 5.7.1 SPF check failed" or "550-5.7.26 Unauthenticated email"). Next we send a test to https://www.mail-tester.com and read the score and the exact SPF/DKIM/DMARC verdicts. Then we verify the DNS records directly with dig TXT yourdomain.com and dig TXT default._domainkey.yourdomain.com, checking the SPF line (for example v=spf1 include:_spf.google.com ~all) actually includes the server or provider that sends your form mail. Finally we inspect the raw headers of a received test for the Authentication-Results line — it states pass/fail for spf, dkim and dmarc and points straight at the broken link.

What you can safely check yourself

Send yourself a test through the form and check the spam folder as well as the inbox — if it is in spam, the form works and the issue is deliverability. Confirm the recipient address in the form settings is spelled correctly and the mailbox is not full. Run your domain through mail-tester.com or MXToolbox's deliverability check and note whether SPF and DKIM say "pass". If you use WordPress, look under the form plugin's mail tab to see which "From" address it uses — it should be an address at your own domain, not the visitor's.

What NOT to touch

Do not edit your DNS zone at random — deleting or duplicating an SPF record (you are only allowed one SPF TXT record per domain) can break all email from the domain, not just the form. Avoid setting the SPF policy to a hard fail (-all) or DMARC to p=reject until you have confirmed every legitimate sender is authenticated, or you will bounce your own mail. Do not paste SMTP passwords into a plugin config on a site you are unsure is secure, and never disable authentication "to make it work". Leave server-level Postfix or Exim configuration alone unless you know the host allows it — many shared hosts override it anyway.

What a 30-minute diagnosis can determine

In half an hour we can normally pinpoint the exact failing link: whether mail leaves the server at all, whether it fails SPF, DKIM or DMARC, and whether the "From" address is misaligned. We identify the correct fix path — configuring authenticated SMTP (your mailbox provider, or a transactional service such as a dedicated SMTP relay), correcting the single SPF record, and publishing or repairing the DKIM key. You leave the diagnosis knowing the specific record to change or plugin to configure, with the exact values, rather than guessing. In many cases the fix itself also fits inside the session.

When it becomes a bigger job

It grows beyond a quick fix when the domain has a tangled DNS history — multiple conflicting SPF records, legacy DKIM keys, or a DMARC policy already set to reject that is bouncing real mail. Migrating the site to authenticated transactional sending, warming up a new sending domain, or untangling email across several services (marketing, invoicing, support and the form all sending as the same domain) is a project, not a patch. If the form mail is entangled with a wider deliverability reputation problem — the domain is on a blocklist, or a previous compromise sent spam — that needs a proper remediation plan.

Frequently asked questions