When an Elementor Form Will Not Send

Separate the two failures before touching any settings: either the form errors when someone clicks submit, or it reports success and no email ever shows up. Those are different problems in different layers, and treating one as the other wastes time.

Where the failure actually is

If the browser shows a success message, the form did its job. Everything after that point is a WordPress mail delivery question.

Email deliverability is not an Elementor problem

A default WordPress install sends mail through PHP's built-in mail function, which most hosts either throttle, block outright, or deliver with no authentication behind it — so recipients' spam filters discard it. This applies to every form, contact page and password-reset email on the site, not just the form widget. If your Elementor form's success message appears but nothing lands, start with WordPress not sending emails and WordPress contact form not sending email rather than re-checking the form's settings a third time.

Fix delivery with SMTP

The reliable fix is routing outgoing mail through an authenticated SMTP connection instead of the server's default mail function, so the message carries proper sender authentication and lands in the inbox rather than the spam folder or nowhere at all. This is a site-wide setting, unconnected to Elementor, and it fixes every outgoing email at once rather than the contact form specifically. Once SMTP is in place, retest the same form again before assuming any remaining fault sits inside Elementor.

Worth knowing before you troubleshoot further: the form widget itself, along with its actions-after-submit list, is part of Elementor Pro rather than the free plugin, as Elementor free versus Pro covers. A site running the free version needs a separate forms solution entirely, and the diagnosis below assumes Pro is active.

Spam protection can silently block real people

Anti-spam settings — a challenge on the form, an aggressive honeypot, or a security plugin filtering POST requests — occasionally reject legitimate submissions along with the bot traffic. A visitor sees an error, or the page reloads with no confirmation, and you never hear about the lead at all. If a captcha step is involved, confirm it is configured correctly per how to add reCAPTCHA to a WordPress form — a misconfigured key rejects everyone, not just bots. If a security or firewall plugin was added or updated around the time submissions stopped, work through how to fix plugin conflicts in WordPress to isolate it.

The actions-after-submit list

Elementor's form widget, whether placed inside a simple layout or a multi-column flexbox container, runs a configurable list of actions once a submission passes validation — sending an email, redirecting the visitor, posting to a webhook, or adding the entry to a connected service, among others. Nothing happens automatically beyond what is in that list. If the email action was never added, was removed during a template edit, or has its recipient field pointing at an address that no longer exists, the form will report success every time while sending nothing. Open the form's actions list directly and confirm the email action is present, enabled, and pointed at a current address, rather than assuming it is there because it once was.

Store submissions as a safety net

Alongside the email action, a submissions-storage action keeps every entry inside WordPress regardless of whether the email itself is delivered. This does not fix a broken email action, but it means a delivery failure loses nothing — the lead is still sitting in the stored submissions list, recoverable once the email problem is found. Given how often mail delivery breaks silently on shared hosting, treating storage as optional is a real risk for any form collecting leads or support requests.

Testing with a real address, not your own domain

Sending a test submission to an address on the same domain as the site hides problems that show up the moment a different provider is on the receiving end — SPF and DKIM misalignment, in particular, is invisible when sender and recipient share infrastructure but rejected outright elsewhere. Test with an external address on a large provider, and check its spam folder as well as the inbox before concluding delivery works. If you have several forms across the site — including any quick-contact form embedded in a sticky header, which is easy to forget since it sits outside the main contact page — run this same test on each one after fixing SMTP once; a shared mail problem usually affects all of them, but a per-form actions list can still be missing the email action individually.

Common mistakes

• Debugging the form when the problem is mail delivery. A success message means the form worked; look at SMTP next.
• Testing only with an address on the site's own domain. It masks the exact failures that matter elsewhere.
• Assuming the email action is still configured. Template edits can silently remove it.
• Skipping stored submissions. Without them, a delivery failure means the lead is simply gone.
• Tightening spam protection without testing afterwards. A stricter setting can start rejecting real visitors.
• Blaming Elementor for a hosting-level mail restriction. Most shared hosts throttle or block default PHP mail regardless of what sent it.

Verify

Submit the form with a valid entry using an external email address, and confirm both the success message and the arriving email, checking spam. Then open the stored submissions list and confirm the same entry appears there. Finally, submit once more with a required field left blank to confirm the error message still displays correctly.