An Elementor form saves the submission and shows a success message, but no email arrives. The saved record proves that the form accepted data; it does not prove that the Email action was present, used valid field IDs, or handed a message to WordPress.
Work from the published widget and its Actions After Submit list, then trace only the email it generates. This keeps an Elementor configuration problem separate from SMTP and final delivery.
What it means
Elementor runs the actions selected under Actions After Submitafter a valid form submission. Email and Email 2 are independent actions, each with its own recipient, sender, Reply-To, subject, body, and field shortcodes.
Other actions can succeed without email. A submission may be stored, a redirect may run, or a webhook may fire even when Email is missing or misconfigured. The published page revision also matters: the editor preview may not match the cached form visitors receive.
A realistic WordPress example
A lead form stores new entries, but Email was removed from Actions After Submit during a page revision. After it is restored, its recipient shortcode resolves to an empty value because the underlying field ID was renamed.
The editor selects the current field ID, sets an authenticated site address as From, and puts the validated visitor address in Reply-To. A submission from the public page now creates a WordPress mail event and reaches the monitored inbox.
Why it matters and when to use it
Elementor forms can trigger several business processes at once. Enabling every action or testing the wrong page revision may send CRM records, webhooks, or duplicate notifications without diagnosing the missing email.
The decisive question is whether the published form executed the intended Email action with resolved values. If no WordPress mail event follows, continue with the widget configuration and Elementor logs. If an event exists, use its SMTP response and provider trace.
This workflow is appropriate when an Elementor form’s notification is missing. A broader WordPress mail outage belongs to the common SMTP configuration.
A straightforward route for beginners
- Save the current page revision and record the form name, widget location, and Actions After Submit list.
- Confirm that Email—or Email 2, if intended—is enabled. Check the recipient, sender, Reply-To, subject, and message fields.
- Compare every shortcode with the current field IDs in the widget. The visible label is not necessarily the field ID.
- Publish only the required change, clear the relevant page cache, and open the public form in a fresh browser session.
- Send a harmless marked submission. Match the AJAX response and action execution to the WordPress mail record, provider response, and destination inbox.
The advanced route
Verify which page and template revision serves the public URL. Record the widget ID and submission timestamp, then inspect Elementor and PHP logs for an action that failed before Email could run. In a multi-action sequence, an earlier error may affect what follows.
Capture the values after shortcode resolution. Empty or stale IDs in Toand Reply-Toare more informative than the template visible in the editor. If WordPress receives the message, correlate the same event with the SMTP transaction and provider message ID.
Test Email and Email 2 separately. After the repair, confirm that redirects, storage, webhooks, and CRM actions still behave as intended; their success is neither proof nor a substitute for email delivery.
Risks, common mistakes, backup, and rollback
Editing the wrong revision, enabling unrelated actions, using raw visitor values in headers, or repeatedly exercising a live lead workflow can disclose data and trigger external automation. Use synthetic input and do not clear useful logs before the test.
Keep the prior page revision and form settings available for rollback. If the change breaks validation, layout, another action, or the published page, restore that revision. Preserve the working SMTP route unless the generated message has a documented transport failure.
How AIOWS helps:
AIOWS SMTP Manager
AIOWS SMTP Manager becomes relevant only after Elementor’s Email action has passed a message to WordPress. Its controlled test can establish that the configured SMTP server and sender work independently of the form widget.
Once the public form generates an email, the module’s diagnostic context helps relate the WordPress event to the provider response. That makes it easier to decide whether the remaining problem belongs to Elementor’s action and field mapping or to the mail route.
AIOWS cannot add an Elementor action, update a field ID, publish the correct page revision, or control a webhook or CRM action. It keeps the supported SMTP configuration and transport result visible while those application settings are corrected; inbox delivery still requires a recipient-side check.
Related AIOWS articles
- WordPress Not Sending Emails: Causes and Fixes
- WordPress Test Email Works but Contact Forms Do Not Send
- Contact Form 7 Not Sending Email: Causes and Fixes
Conclusion and recommended route
Start with the version of the form visitors actually use. Confirm the Email action and resolved field IDs, publish the narrow correction, and then follow one marked message through WordPress and the provider to the intended mailbox.
