Why Your Gravity Forms Emails Are Not Sending

“`html

Why Your Gravity Forms Emails Are Not Sending — And How to Fix It

Gravity Forms emails not sending has gotten complicated with all the plugin updates and hosting environment changes flying around. A client’s contact form has been sitting silent for weeks. Inquiries are disappearing into the void. You’re scrambling to figure out where the breakdown is happening, and those generic troubleshooting guides aren’t helping because they cover Gmail, Outlook, and basic SMTP without touching the Gravity Forms-specific layer where the actual failure lives.

As someone who’s been managing WordPress sites for seven years, I learned everything there is to know about email delivery failures the hard way—hunting through server logs at 11 PM because someone’s form “just stopped working” after a plugin update. Today, I will share it all with you. The good news: Gravity Forms email delivery failures are almost always fixable once you know where to look. The bad news: the problem usually isn’t your form. It’s your SMTP setup, a plugin conflict, or something your hosting provider is blocking without telling you.

So, without further ado, let’s dive in.

Check Your SMTP Settings First

Your first instinct might be to panic and reinstall Gravity Forms. Don’t. Start with SMTP configuration instead.

Gravity Forms doesn’t send emails directly—it hands them off to WordPress, which then uses your server’s mail function or an SMTP service. If you’re relying on your hosting provider’s built-in mail function (the default), you’re already working with limited reliability. Most modern setups use an SMTP provider instead: SendGrid, Gmail, AWS SES, or Mailgun.

I usually see failures happen in one of three places in the SMTP configuration. First is authentication. You’ve entered your username and password, but they’re wrong. SendGrid users especially make this mistake—the username is often “apikey,” and the password is your actual API key, not your account password. I once spent 45 minutes thinking our SendGrid integration was broken when the issue was that someone had copy-pasted the API key with a trailing space at the end.

To test your SMTP connection in Gravity Forms: Go to Forms → Settings → Email, then scroll to the “Email” section. Enter your SMTP server address (smtp.gmail.com for Gmail, smtp.sendgrid.net for SendGrid), the port (usually 587 for TLS or 465 for SSL), your username, and password. Check the box for “Use SMTP.” Then send a test form submission and watch what happens.

Gmail is the second common failure point. Google’s security has tightened over the years. If you’re using a standard Gmail account with Gravity Forms, you need to generate an app password — at least if you want it to actually work. The app password is a 16-character code you create in your Google Account settings under Security. Use that code as your password in the SMTP settings, not your actual Gmail password. Standard authentication will fail silently, and you’ll never know why.

Third: port mismatches. TLS uses port 587. SSL uses port 465. Pick the wrong one and your connection will timeout without giving you useful error messages. SendGrid accepts both, but AWS SES is picky about which regions support which ports. If you’re in eu-west-1, port 465 might not work at all. Check your SMTP provider’s documentation for your specific region.

Probably should have opened with this section, honestly. The SMTP settings are correct about 30% of the time in sites I audit. The remaining 70% have wrong credentials, misconfigured ports, or authentication methods that don’t match their provider’s requirements.

Disable Conflicting Plugins and Check PHP Version

Once SMTP is confirmed working, the next culprit is usually a plugin conflict. Frustrated by form failures, developers often overlook how certain plugin types actively interfere with email delivery.

Caching plugins are the worst offenders. W3 Total Cache, WP Super Cache, and even Cloudflare can cache form processing in ways that prevent Gravity Forms from executing the email notification. Security plugins like Wordfence can block outbound SMTP connections if they’re configured too aggressively. Backup plugins sometimes lock database tables while backups run, preventing form submissions from being recorded properly — and when the form doesn’t save, the notification never fires.

To identify the conflict, enable WordPress Safe Mode. This disables all plugins except those you manually activate. Here’s how: Add this line to your wp-config.php file (right before the line that says “That’s all, stop editing”):

• define(‘WP_SAFE_MODE’, true);

Now test a form submission. If the email sends in Safe Mode, you’ve got a plugin conflict. Disable Safe Mode, then deactivate plugins one by one until you find the culprit. Usually it’s one of the plugin types I mentioned — caching, security, or backup.

PHP version compatibility is a less obvious issue. Gravity Forms 2.5+ requires PHP 7.2 as a minimum, but some hosting providers still run PHP 5.6 or 7.0 by default on shared hosting plans. If your server is running an older PHP version, Gravity Forms might run but email functionality can fail silently. You can check your PHP version in WordPress under Tools → Site Health (look for the “Server” section). Contact your hosting provider to upgrade to PHP 7.4 or higher. PHP 8.1+ is becoming standard now, and most SMTP providers expect it.

I once inherited a site where forms hadn’t sent emails in six months. The client had never mentioned it — they assumed contact requests just weren’t coming in. Turned out the server was running PHP 5.6, and an update to PHP 7.4 fixed everything. Don’t make my mistake.

Verify Form Notification Rules and Conditions

Here’s where things get subtle. Your SMTP is working. Your plugins aren’t conflicting. But emails still aren’t sending. The problem might be that your notification conditions are written in a way that prevents them from firing at all.

Conditional logic in Gravity Forms notifications is powerful but easy to misconfigure. Navigate to Forms → [Your Form] → Settings → Notifications. Look at the notification you’re trying to test. Below the email address field, you’ll see “Send notification if…” with dropdown options.

The most common mistake I see: someone sets a condition like “Email is not empty” when the field is optional. If someone submits the form without filling in the email field, the notification condition fails and the email never sends. The form submission still records, but the admin notification silently fails without alerting anyone.

Another example: “Post Title contains X.” If you’re using custom field variables (like {Field Name}), and that field is empty, the condition evaluates to false and the notification doesn’t fire.

To debug this, enable Gravity Forms logging. Go to Forms → Settings → Logging (in the top menu) and click “Enable Logging.” Then submit a test form. The log will show you exactly where the notification failed: condition not met, SMTP error, or form submission never recorded.

Check the logs at wp-content/logs/gravity_forms_debug.log (or wherever your WordPress logs directory is configured). You’ll see entries like “Notification ‘Admin Notification’ not sent” or “SMTP error: Authentication failed.” These logs are gold for diagnosing exactly what went wrong.

Check Server Firewall and Email Authentication

Your SMTP settings are correct. Your plugins aren’t conflicting. Your notifications are configured properly. But emails still aren’t sending. Now you’re probably dealing with a server-level firewall block.

Most hosting providers allow outbound email by default, but some restrict outbound connections on port 587 (SMTP-TLS) or 465 (SMTP-SSL). Your server might be blocking requests to remote SMTP servers for security reasons. Send a support ticket to your host asking: “Are outbound connections to SMTP port 587 and 465 allowed from our server?”

If they say no, ask them to whitelist your SMTP provider’s IP addresses or domain. SendGrid’s IP ranges are published. AWS SES provides regional endpoints. Gmail SMTP uses Google’s infrastructure, which is harder to whitelist. In those cases, you might need to switch SMTP providers entirely.

SPF, DKIM, and DMARC records are separate from the actual email delivery problem, but they affect deliverability once emails do send. If your emails are being delivered but landing in spam, your DNS records are probably missing. But if they’re not sending at all, DNS records aren’t the issue — your SMTP connection is failing before DNS records even come into play.

Test whether your server allows outbound SMTP by using WP-CLI on your server (if you have SSH access):

• wp mail-check –provider=sendgrid (or whatever your provider is)

If the connection times out, your host is blocking outbound SMTP. Contact them and push for whitelist access before trying anything else.

Use the Gravity Forms Debug Log to Confirm the Issue

By now, you’ve checked SMTP, disabled conflicting plugins, verified your notification conditions, and confirmed your server allows outbound email. If emails still aren’t sending, the debug log is your final tool before escalating to your hosting provider.

Enable WP_DEBUG in wp-config.php by changing this line:

• define(‘WP_DEBUG’, false);

To this:

• define(‘WP_DEBUG’, true);
  define(‘WP_DEBUG_LOG’, true);
  define(‘WP_DEBUG_DISPLAY’, false);

Now submit a test form and check wp-content/debug.log. You’ll see the complete error stack, including exactly which SMTP connection attempt failed and why.

Common error messages you might see: “SMTP connect() failed,” which means your SMTP server address or port is wrong. “SMTP Error: Could not authenticate,” which means your credentials are wrong. “Connection timed out,” which means your host is blocking outbound SMTP.

Once you have the error message, take a screenshot and contact your hosting support with the evidence. Most support teams will move much faster when you hand them a specific error rather than vaguely saying “emails aren’t working.”

The combination of SMTP testing, safe mode plugin checks, notification condition review, and debug logs will identify the actual source of the problem in nearly every case. Start at the top and work your way down. You’ll find it.

“`