WordPress Contact Form Not Sending Email? Start Here

Switching form plugins won’t fix a hosting server that can’t send mail. This covers the three failure types that cause WordPress contact form emails to disappear, how to identify which one you have, and the mail stack that eliminates the problem for good.

Date

Category

Cracked shield around an email, illustrating a WordPress contact form failing to deliver mail

Contact form submissions show up in your log but never reach your inbox. That’s a mail delivery failure, not a form plugin failure, and switching to a different plugin won’t fix it.

Think of it like dropping a letter in a mailbox. The moment it leaves your hand, you assume it’s on its way. But if the post office quietly tossed it, you’d never know. No bounce, no notice, just a reply that never comes. WordPress works the same way. It hands your form’s email off to the server and calls it done, with no idea whether the message actually went anywhere.

If WordPress is not sending emails, the cause almost always lives below the plugin level. WordPress sends email through PHP’s mail() function by default. That function hands the message to your hosting server and reports back “success” whether the server sent the email or silently dropped it. On a lot of shared hosting setups, it gets dropped. The form looks like it’s working. The emails don’t arrive. You have no way to know from inside WordPress.

Before you touch the form plugin, figure out which failure type you’re dealing with.

This is true no matter which form plugin you’re running. WPForms, Contact Form 7, Gravity Forms, Ninja Forms, Fluent Forms, it doesn’t matter. The form itself is rarely the problem. If the email isn’t showing up, the cause is almost always in how your server handles outgoing mail, not the plugin sitting on top of it.

Three Checks Before You Change Anything

1. Check the submission log. Open your form plugin’s entry or submission list. If the record is there, the form submitted correctly and the problem is downstream in mail delivery, not in the form itself. If there’s no record at all, you have a form-level issue: a misconfigured notification, a plugin conflict, or a field validation problem.

2. Check every spam folder. Check junk, spam, and Gmail’s Promotions tab for the address the form sends to. A large share of “broken” contact forms are actually delivering into spam. That’s a deliverability problem, not a sending problem. Different cause, different fix.

3. Run a mail health check. Mail Tester scores your outgoing mail setup against spam filters, SPF/DKIM configuration, and known blocklists. Paste the test address into a WordPress form or test email and check the results. It takes about 60 seconds and tells you more than an hour of plugin debugging. If your score is below 8/10, the report will show you exactly why.

SPF and DKIM: Why Your Email Gets Rejected Without a Bounce

The most common failure pattern: the form submits, the email leaves WordPress, and it gets quietly discarded by Gmail or Outlook before it reaches anyone’s inbox. No bounce. No error. Just silence.

This happens because of SPF mismatch. Most form plugins send notifications from an address like [email protected] or [email protected]. If your domain’s SPF record doesn’t authorize your hosting server to send email on its behalf, receiving mail servers reject the message as potential spoofing.

It’s especially common on sites that use Google Workspace or Microsoft 365 for real email. The SPF record covers Google’s servers, not your hosting server. When WordPress sends from a @yourdomain.com address through the hosting server, it fails authentication. Gmail drops it without telling you.

To fix it: check your domain’s DNS for an SPF record. If you’re on Google Workspace, it probably looks like v=spf1 include:_spf.google.com ~all. You need to add your hosting server’s sending IPs too. Better yet, stop routing WordPress mail through your hosting server entirely.

DKIM is a separate layer. It adds a cryptographic signature that receiving servers can verify. Check your DNS for a DKIM record. If it’s missing, any outgoing WordPress email is unsigned, which increases the chance of it being spam-filtered. Your hosting provider or transactional mail service can generate and publish one.

Shared Hosts That Block Outgoing PHP Mail

Some shared hosts disable or throttle outgoing PHP mail entirely to limit spam abuse from other tenants on the same server. mail() still returns a success status, so WordPress has no way to know the message was never queued. Sending limits, SMTP blocking on shared plans, and deliverability headaches are common on budget hosts. GoDaddy is a repeat offender here.

One client came to us after six weeks of missed contact form inquiries. Their shared host had silently changed its outbound mail policy after a spam incident involving another account on the same server. The form logged every submission correctly. Not one email had reached the business owner. They’d been telling prospects to expect a callback and had no idea the callback was never triggered. This is the kind of failure nobody catches until a lead complains, which is exactly why someone needs to be watching the site.

If your Mail Tester score is very low or your IP shows up on a blocklist, this is likely what’s happening. The fix isn’t a different plugin. It’s routing WordPress email through a transactional mail service that doesn’t depend on your host’s mail stack.

Mailgun, Postmark, and SendGrid are all solid options. They’re built for reliable, authenticated delivery and give you per-message logs showing exactly what happened to every outgoing email. “Install WP Mail SMTP and connect it to your Gmail” works in a pinch, but Gmail has a 500-email-per-day send limit and isn’t designed as a business mail relay.

WordPress Not Sending Emails After It Worked Fine Before

If the form was sending fine and then stopped, check what changed. Three things cause this pattern almost every time:

Hosting migration. The new server has different outgoing mail handling. The old SMTP configuration doesn’t carry over, and the new host may have a different (or stricter) mail policy. We see this on almost every site we migrate in.

DNS change. Adding Google Workspace or any other mail service to your domain requires editing your SPF record. If the update was done incorrectly, it can break the existing SPF coverage and immediately cause WordPress mail failures. Check whether the SPF record changed around the same time the forms stopped working.

Plugin or PHP update. Some updates quietly change the format of the “from” address. If the new format doesn’t match what the SPF record expects, or adds extra characters that fail authentication, mail stops getting through. Run Mail Tester after the update to catch this quickly.

The Stack We Use on Every Client Site

On every Privatenode-managed site we use Gravity Forms, Gravity SMTP, and Mailgun. That combination is deliberate.

Gravity Forms keeps a detailed submission log for every entry. When a client reports that a form isn’t sending, we can tell within 30 seconds whether the problem is at the form level or the mail delivery level. That distinction matters because they’re completely different fixes.

Gravity SMTP sits between Gravity Forms and Mailgun and logs delivery status per message right in the WordPress dashboard. No logging into a separate service to see what happened to a specific email.

Mailgun handles the actual sending. Every message is authenticated, logged by message ID, and traceable. If something doesn’t arrive, the Mailgun activity log shows whether it was delivered, bounced, or spam-filtered, usually within seconds of the failure.

We don’t use Contact Form 7 for clients who need reliable delivery. It has limited submission logging, which means when something goes wrong, you’re debugging blind. The plugins included with managed WordPress hosting cover what clients actually need, and Gravity Forms is part of that stack.

This approach is also why clients who switch from shared hosting to managed WordPress hosting usually find the email problem goes away. It’s not the hosting itself that fixes it. It’s that the mail stack is configured correctly from the start.

What to Change First

  1. Run Mail Tester before touching anything else. It’ll tell you which of these failure types you’re dealing with.
  2. Fix SPF and DKIM if they’re missing or misconfigured. This is often the entire fix.
  3. If your host is blocking PHP mail, switch to a transactional mail service via SMTP. Mailgun is a good default.
  4. Use a form plugin with a submission log. Without one, you won’t know a delivery failure happened until a lead mentions they never heard back.

If you’ve gone through all of this and the problem persists, it’s a hosting configuration issue. No form plugin swap will solve it. A contact form silently dropping submissions loses leads with no indication anything went wrong. We configure and manage this mail stack for every site we run and can get yours sorted if you’d rather not deal with it.

Common Questions

Why does my contact form say “sent” but I never get the email?

The form plugin only confirms the submission was handed to your server’s mail function. It has no visibility into what happens after that. If your server drops the message or a receiving mail server rejects it for failing SPF or DKIM checks, the form still reports success. Check the submission log first, then run Mail Tester to see where delivery is breaking down.

Why are my WordPress emails going to spam?

Usually missing or misconfigured SPF and DKIM records. Unauthenticated email from a shared hosting IP is exactly what spam filters are built to catch. Publishing correct SPF and DKIM records, or routing mail through a transactional service like Mailgun, fixes it in most cases.

Do I need an SMTP plugin for WordPress?

If your site sends anything important, yes. Default PHP mail gives you no authentication, no logging, and no way to confirm delivery. An SMTP plugin connected to a transactional mail service gives you all three.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *