WordPress Contact Form Not Sending Email

September 7, 2026

Updated for WordPress 7.1 and PHP 8.3 — 8 September 2026.

When a WordPress contact form is not sending email, the message has usually left your site and been thrown away somewhere else. That distinction is the whole job: WordPress hands mail to the server and considers itself finished, so a form that reports success tells you nothing about delivery. Establish whether the message was ever handed over, then whether anyone accepted it — those are two different failures with two different fixes.

Understand what WordPress actually does with mail

WordPress sends mail through wp_mail(), which by default hands the message to PHP’s mail() function and stops caring. The wp_mail() reference is clear that its return value reports whether the message was accepted for delivery — not whether it was delivered.

That is the entire problem in one sentence. Your form plugin shows a green tick because wp_mail() returned true. The receiving mail server then rejected the message, or filed it as spam, and nothing told anyone.

Server-sent mail gets rejected because it fails the checks that receiving servers apply: the sending IP has no reputation, there is no SPF record authorising your web server to send as your domain, and nothing is signed with DKIM. Mail sent this way is indistinguishable from spam, so it is treated as spam. This is also, incidentally, why WordPress recovery mode emails so often fail to arrive at the exact moment you need them.

Check whether the mail left at all

Install a mail logging plugin before changing any settings, so you stop guessing. A logger records every message wp_mail() attempts and whether it was accepted, which splits the problem cleanly in two:

No log entry at all — the form never called wp_mail(). This is a form configuration or JavaScript problem, not a delivery problem. Check the form’s own settings and its submission log.
Logged and accepted, but nothing arrives — the message left and was discarded downstream. This is a delivery and authentication problem, and the fix is authenticated SMTP.

Before you install anything, check the obvious: send a test to an address on a completely different provider from your own. A message to an address on the same domain can be delivered internally by the same server and appear to work while every external recipient never sees it.

Fix delivery with authenticated SMTP

Sending through a real mail service instead of the web server solves this properly, and it is the only fix that survives contact with modern spam filtering. Configure WordPress to send over authenticated SMTP using a dedicated transactional provider or your own mailbox, so the message comes from somewhere with a sending reputation and correct authentication.

You will need the host, port, encryption method, username and password from your mail provider. Two things worth getting right while you are there:

The From address must be on a domain you control, and ideally match the authenticated account. Setting the From address to the visitor’s own address is a common form default and it actively causes rejections, because your server is not authorised to send as their domain.
Put the visitor’s address in Reply-To instead. You keep one-click replies without forging the sender, which is what the field is for.

Store SMTP credentials as constants in wp-config.php rather than in a plugin’s settings screen where they sit in the database in plain text. Most SMTP plugins document the constant names they read; check your plugin’s own documentation rather than copying a snippet from a blog, because the names differ between plugins and a wrong constant fails silently.

Add SPF, DKIM and DMARC records

These three DNS records tell receiving servers your mail is legitimate, and without them even correctly configured SMTP can land in spam. Your mail provider publishes the exact values — use theirs rather than a generic example, because a wrong SPF record is worse than none.

SPF lists which servers may send mail for your domain. You get one SPF record per domain; if you already have one, merge the new sender into it rather than adding a second.
DKIM signs outgoing mail cryptographically so the receiver can verify it was not altered and genuinely came from you.
DMARC tells receivers what to do when SPF or DKIM fails, and can report failures back to you. Start with a monitoring-only policy and read the reports before tightening it — going straight to a reject policy will silently bin legitimate mail you had forgotten about.

DNS changes take time to propagate. Do not judge whether this worked five minutes after saving the records.

Rule out the form plugin itself

If nothing appears in a mail log, the failure is upstream of delivery and no SMTP configuration will help. Check the notification is actually enabled and has a recipient address — an empty or mistyped recipient field is a genuinely common cause and looks exactly like a delivery failure.

Also check whether the submission itself is being recorded. Most form plugins store entries in the database; if entries are being saved but no email is sent, the form is working and only the notification is broken. If no entry is saved either, the submission is failing before WordPress sees it — look at spam protection rejecting real people, or a JavaScript error stopping the request. Your browser’s console will tell you which.

Test it in a way that reflects reality

Test to at least two providers on different domains, because deliverability is not a single yes or no. A message can reach one provider’s inbox, another’s spam folder, and be rejected outright by a third. Testing only to your own address, on your own domain, tells you almost nothing about what your customers experience.

Once it works, keep it working: mail logging left enabled turns a silent failure into a visible one. A form that quietly stops sending is one of the few site faults that can run for months without anyone noticing — which is exactly why it belongs on the list of transactional things to re-check after every update, as covered in a safe WordPress update routine.

Frequently asked questions

Why do form emails go to spam instead of the inbox?

Because mail sent directly by a web server usually has no SPF authorisation, no DKIM signature and no sending reputation. Authenticated SMTP through a real mail provider, plus correct DNS records, is the fix.

The form says the message was sent. Does that mean it was delivered?

No. It means wp_mail() accepted the message for delivery. Everything that happens afterwards is invisible to WordPress unless you add mail logging.

Should the From address be the visitor’s email?

No, and this is a frequent cause of rejection. Your server is not authorised to send as their domain. Use an address on your own domain as From, and put theirs in Reply-To.

Do I need a paid transactional email service?

Not necessarily — authenticated SMTP through a mailbox you already own works for low volumes. A dedicated service becomes worthwhile when volume grows or when you need delivery logs and bounce handling.

Will fixing this also fix password reset emails?

Yes. Password resets, recovery mode links, new user notifications and order confirmations all go through wp_mail(). Fixing delivery once fixes all of them.