nanoPost

The WordPress Email Authority

Divi contact form not sending email: the diagnostic chain

Last reviewed/updated:

The Divi Contact Form module submits via the WordPress AJAX endpoint at admin-ajax.php, validates required fields and the spam-protection toggles, and on success calls WordPress’s wp_mail() with the recipient from the Email tab, a subject derived from the form title, and the submitted field values rendered into the body. In the legacy Divi tree the handler lives at includes/builder/module/ContactForm.php; in Divi 5 the same responsibility moved into the visual builder’s component tree, but the behaviour is identical: validation runs, then wp_mail() is called. A request firing in the browser’s Network tab shows the action as et_pb_contact_form_submit; if that request reached the handler, the form is talking to Divi correctly.

Every failure mode for “the form is not sending” sits on one side of that wp_mail() call. Either the submission was rejected before wp_mail() ran (Divi’s own validation, a misconfigured Email tab, the spam-protection toggles, a JavaScript or AJAX error) or wp_mail() ran and the message was lost downstream (PHP mail() blocked at the host, SPF or DKIM failing to authenticate, the receiving server quarantining it). The diagnosis follows that fork.

Run the five checks below in order, from the cheapest to the most involved. Each rules in or rules out a category of failure. Skipping to “install an SMTP plugin” works when the answer is SMTP, and wastes a configuration cycle when it is not.

Check 1: Is WordPress sending email at all?

The cheapest check is the one with no Divi in the loop. Trigger a password reset for a test user account and watch for the message. If it arrives, wp_mail() is functional and the problem is either inside the Divi form or downstream of wp_mail(). If it does not arrive, WordPress itself cannot send email and the SMTP fix in Check 4 is the path; there is no point fiddling with the Divi form until the underlying mail pipeline works.

A logging plugin makes this much clearer. Install Check & Log Email or WP Mail Logging, trigger the password reset, and inspect the log. The two states that matter:

  • The log records the password-reset call and shows it succeeded. wp_mail() is working.
  • The log shows nothing, or records the call and shows it failed. wp_mail() is broken at this site.

For the full WordPress-side tree, the WordPress email troubleshooting guide walks every step in detail, and the WordPress send-test guide covers the three send-test methods that confirm or deny wp_mail() is working. That is where to continue if Check 1 fails.

Check 2: Is the Divi form actually calling wp_mail()?

If WordPress is sending mail, the next question is whether Divi is reaching wp_mail() at all. Build a minimal test form:

  • A new Contact Form module on a draft page.
  • One Email field and one Message field. Nothing else.
  • The Email tab recipient set to a Gmail address the operator can monitor.
  • “Use Basic Captcha” disabled.
  • “Use A Spam Protection Service” disabled (if previously enabled).

Divi’s Message Pattern field is blank by default. When it is blank, the email body lists each submitted field in the order the fields appear on the form. A custom Message Pattern uses %%field_id%% tokens to control structure; for example, Message from %%name%% (%%email%%): %%message%% produces a body in that shape when the form has fields with IDs name, email, and message. A blank arriving body usually means a token in a custom Message Pattern does not match any Field ID on the form.

Submit the minimal form from an incognito browser window with the email log open. The four observable states:

  1. The success message displays and mail arrives. wp_mail() is being called and the message is being delivered. The original form has a configuration problem; go to Check 3.
  2. The success message displays and mail does not arrive, but the log shows wp_mail() was called. The message left WordPress but was lost downstream. Go to Check 4 and then Check 5.
  3. The success message displays and the log shows nothing. Divi is not calling wp_mail(). The most common cause is a caching layer intercepting the AJAX response and serving a cached page; less often, a JavaScript error from a conflicting plugin; occasionally, an object-cache that returns a stale “success” payload. Deactivate non-essential plugins, clear page and object caches, and retest. The browser’s DevTools Network tab confirms whether the submission reached admin-ajax.php and what the server returned.
  4. The page reloads with no success message. Divi’s own validation rejected the submission. Re-check required fields, the Email tab recipient (Check 3), and the spam-protection toggles.

If the minimal form works and the original does not, the difference is configuration. Check 3 covers the fields that typically produce the symptom.

Check 3: The Email tab and the field IDs

Five Divi Contact Form fields produce the “form not sending” symptom more often than the rest. The recipient field and the spam-protection toggles account for the majority of real cases; the field IDs, Message Pattern, and Redirect URL account for the rest. Read in that order if time is short.

Email (recipient). Comma-separated addresses are accepted. Whitespace before or after a comma silently breaks parsing in some Divi builds; remove it. Quoted display-name addresses ("Site Owner" <[email protected]>) are accepted by wp_mail() but are inconsistently validated by Divi’s own field check. Use bare addresses without quotes or angle brackets.

Use Basic Captcha and Use A Spam Protection Service (Spam Protection group). Divi’s built-in Basic Captcha is a math question; the Spam Protection Service toggle wires in Google reCAPTCHA v3. Both block submissions that fail them with no error visible to the visitor, and Basic Captcha in particular is accessibility-hostile. For sites that need real bot protection, disable Basic Captcha and route the form through reCAPTCHA v3 with a conservative score threshold, Akismet, or Cloudflare Turnstile via a third-party Divi module.

Form Field IDs (per field, in the form’s Content tab). Each form field carries a Field ID. That ID is what Divi uses to map the submitted value into a %%field_id%% body token. IDs with spaces, capital letters, or non-ASCII characters break the mapping; the email arrives with empty fields where the values should be. Use lowercase alphanumerics and hyphens only.

Message Pattern (Email tab, Advanced). The Message Pattern is blank by default, which renders submitted fields sequentially. A custom Message Pattern with mismatched tokens, such as %%name%% where the Field ID is full_name, produces a “success” submission with a blank body. If the email is arriving but the body is empty, the Message Pattern is the field to check first.

Success Message and Redirect URL (Email tab). A populated Redirect URL overrides the default success message and sends the visitor straight to the redirect target. A site owner watching the form from the visitor’s perspective sometimes mistakes a working redirect for a failed form. Test from an incognito window to see the actual behaviour.

Check 4: Route email through SMTP

Divi itself has no SMTP settings panel; the Contact Form module hands its message to wp_mail(), and whatever WordPress does next is what controls delivery. Configuring “Divi SMTP” is therefore configuring wp_mail(). When wp_mail() is returning true and mail is still not arriving, the most common cause is the host’s outbound mail. WordPress’s wp_mail() defaults to PHP’s mail() function, which on most shared hosting hands the message to the local MTA without authentication. The receiving server sees mail from a domain that does not match the sending IP’s reverse DNS, has no DKIM signature, and may not be in the published SPF record. Gmail and Microsoft 365 quarantine or drop those messages aggressively.

The fix is routing wp_mail() through an authenticated SMTP relay. Three pairings cover the typical Divi site:

  • FluentSMTP with SMTP2GO. Free-tier comfortable. FluentSMTP is open-source, has email logging in the free version, and ships no upsell pressure. SMTP2GO’s free tier covers 1,000 messages per month with a 200/day cap and no time limit; a Divi contact form on a marketing site rarely exceeds it. The starter paid plan is $10/month for 10,000 messages.
  • WP Mail SMTP with Postmark. Easiest setup, strongest transactional delivery. WP Mail SMTP’s setup wizard walks the operator through provider selection, credential entry, and a test email. Postmark’s transactional-only IP pools keep contact-form mail out of the marketing reputation pools that other senders share. Postmark’s free tier is small (100 messages/month, testing only); the Basic plan is $15/month for 10,000 messages.
  • Post SMTP with Gmail or Google Workspace. For sites already inside the Google ecosystem. Post SMTP handles the OAuth flow and surfaces SMTP-level error responses inline when the connection fails, which shortens credential-debug cycles. See Gmail OAuth vs app passwords for which credential mode to pick.

A Divi marketing site is small-volume transactional traffic; the choice between these pairings is comfort, not capacity. Leaving wp_mail() on PHP mail() is a configuration error, not a wait-and-see condition; the next message is not going to find a different host.

Check 5: Deliverability

The form is calling wp_mail(), wp_mail() is returning true, SMTP is configured and authenticated, and the recipient still reports no mail. At this point the problem is downstream of WordPress. Three things to check.

Run an end-to-end test against Mail-Tester. Get a fresh test address from Mail-Tester, submit a real Divi form to it, and read the scored report. SPF, DKIM, and DMARC results appear individually, along with content scoring and any blacklist hits. A 9/10 or 10/10 score against Mail-Tester is not a guarantee that Gmail will deliver, since Gmail’s classifier is not visible to third-party testers, but a low Mail-Tester score points at a specific fixable problem. A score under 7 most often means DKIM is missing entirely or the SMTP provider’s sending domain is not present in the published SPF record; both are records to fix at the DNS host before submitting a second test.

Confirm SPF, DKIM, and DMARC are published for the sending domain. Every SMTP provider publishes the exact records to add; the relevant ones for a Divi site routed through a provider are an SPF include: for the provider’s sending range, a DKIM TXT record at the selector the provider specifies, and a DMARC TXT record at _dmarc.example.com at minimum at p=none with reporting on. The DNS for WordPress email guide covers the alignment trap that catches plugin-routed mail and the migration path from p=none to p=reject.

For corporate recipients, expect more aggressive quarantine. Microsoft 365 and Google Workspace defenders quarantine unfamiliar senders harder than personal mailboxes do. If the form’s recipient is a corporate inbox, ask their IT team to allowlist the sending domain after SPF, DKIM, and DMARC are in place. Quarantine is not a failure of the form; it is the receiving organisation’s policy. The send-side fix is making sure authentication passes; the receive-side fix is on the recipient’s IT.

Verdict

For a typical Divi marketing site that has not yet been touched, the default fix is FluentSMTP routed through SMTP2GO, with the sending domain authenticated for SPF and DKIM. That combination removes the most common cause of contact-form mail going missing, without committing to a paid plan and without a setup wizard that pushes upgrades.

The Divi Contact Form module is a thin layer on wp_mail(). Most “form not sending” reports resolve to one of three causes: a Divi configuration mistake in the Email tab or the Field IDs, wp_mail() failing because PHP mail() is blocked or unauthenticated at the host, or a deliverability problem downstream of authenticated sending. The five-check chain above rules each in or out in order. The harder problems (empty bodies from broken Field IDs, accessibility-blocking Basic Captcha math questions, corporate quarantine) are named so the reader does not chase the SMTP fix for a problem SMTP cannot solve.