WPForms or Gravity Forms Not Sending Email? Here's the Fix

A visitor fills out your quote form, sees the green "Thanks, we got it!" message, and then... nothing shows up in your inbox. No error, no bounce, just silence. This is one of the most common tickets we see for WPForms and Gravity Forms sites, and it almost never means the form is broken — it means the notification email never made it past your mail server.

Why this happens

WPForms and Gravity Forms don't send email themselves. When someone submits a form, the plugin hands the message to WordPress's wp_mail() function, which then tries to send it through PHP's built-in mail() command unless you've configured something else. On shared cPanel hosting, that built-in path is unauthenticated and unreliable — receiving mail servers increasingly reject or silently drop anything that arrives without SPF/DKIM authentication behind it. The submission saves fine in your WordPress database (that's why the "success" message shows), but the notification email dies quietly on the way out.

A second, less obvious cause: conditional notifications. Both plugins let you route emails based on field values ("if Department = Sales, send to sales@..."). One typo in that condition, or a field that got renamed after the form was built, and the notification simply never fires for anyone.

Step 1 — Confirm it's a delivery problem, not a form problem

Open WPForms → Entries (or Forms → Entries in Gravity Forms) and check whether the submission actually saved. If it's there, the form itself is working — this is purely an email delivery issue, so skip straight to Step 2.

If the entry isn't there either, the problem is client-side (JavaScript conflict, a plugin blocking AJAX) and the fixes below won't help — that's a different investigation.

Step 2 — Check the notification settings first

Before touching SMTP, rule out a misconfigured notification:

• In WPForms: Settings → Notifications on the form — confirm the "Send To Email Address" field is a real, current address and doesn't still reference a smart tag pointing at an empty field.
• In Gravity Forms: Form Settings → Notifications — open each notification and check the routing rules. A stray "AND" condition that can never be true will silently kill delivery.
• Make sure the notification itself is toggled Active — it's easy to disable one while testing and forget to re-enable it.

If settings look correct, move to the mail server side.

Step 3 — Test PHP mail is actually reaching your inbox

Install a lightweight plugin like Check Email or WP Mail Logging temporarily. Submit a test entry and see whether wp_mail() was called at all, and with what result. If the log shows the email was "sent" by WordPress but it never arrives, the problem is downstream — your server tried to hand it off and the receiving side (or an intermediate spam filter) dropped it.

You can also test from the command line if you have SSH or cPanel Terminal access:

echo "Test body" | mail -s "Test from server" you@yourdomain.com

Then check /var/log/exim_mainlog (on a VPS) or the Track Delivery tool in cPanel to see whether the message was accepted, deferred, or bounced.

Step 4 — Set up authenticated SMTP (the real fix)

This solves the problem for good in the vast majority of cases. Instead of routing through PHP's mail(), send form notifications through an authenticated SMTP connection — either your own cPanel mailbox or a transactional provider.

1. Install WP Mail SMTP (free, works with both WPForms and Gravity Forms since it hooks into wp_mail() globally).
2. Choose a mailer: your cPanel email account (Other SMTP, port 465/587), or a dedicated service like SendGrid, Mailgun, or Zoho Mail if you're sending a high volume of transactional mail.
3. Enter your SMTP host, port, and credentials — for cPanel mail this is usually mail.yourdomain.com on port 465 (SSL) with your full email address and mailbox password.
4. Send a test email from the plugin's built-in tester before trusting it with real form traffic.

Once SMTP is authenticated, your form notifications carry proper SPF/DKIM alignment and stop looking like spam to Gmail, Outlook, and corporate mail filters.

Step 5 — Check spam folders and cPanel-side filters

If SMTP is working but mail still isn't landing in the inbox, check:

• The recipient's spam/junk folder — form notifications are a classic spam-filter target because they're automated and often contain URLs.
• cPanel's own Spam Filters (Apache SpamAssassin) — if the notification address is a mailbox on the same server, an aggressive local spam score can quarantine it before it ever reaches the inbox.
• Whether the sending domain has SPF and DKIM records published at all — without them, most providers will flag or reject outright.

Prevention

Once SMTP is authenticated and your notification rules are simple, this stops being a recurring ticket. If you're still stuck after working through these steps, our support team can check your mail queue and SPF/DKIM setup directly — reach out through your Getwebup dashboard.