Webflow form emails not arriving: find the stage that failed before changing anything

Three stages, three different fixes

When someone submits a Webflow form, three things must happen in order. The page has to accept the submission, Webflow has to store it, and Webflow has to send a notification that your mailbox accepts. A missing email can be a failure at any of the three, and the quickest way to tell which is to look at the stored submissions before you look at your inbox.

Publish the site, submit the form once on the live address with the word TEST in the message, then open the form submissions area in the site settings. Webflow's own advice is to test on the published site.

• Stored and emailed: nothing is wrong with the form; check the other mailbox or ask the customer to resend.
• Stored but not emailed: the problem is the notification settings or your mailbox.
• Not stored: the form is not submitting to Webflow at all.

If nothing is stored

A form that never reaches Webflow usually has a structural cause. Webflow lists the submit control first: the form needs a real submit button, not an ordinary button, and a required field cannot be hidden, because the visitor then cannot satisfy it. If a reCAPTCHA is switched on in site settings, the form also needs the matching reCAPTCHA element.

Two more causes sit outside the form itself. A custom form action sends submissions to another service, so Webflow neither stores them nor emails you; the destination must be set back to Webflow. And if the site's code was exported and is hosted somewhere else, Webflow does not process submissions at all.

• Check the button type and every required field on the published page.
• Open the form settings and confirm the send-to option says Webflow.
• Ask who hosts the live site if the address is not a Webflow-hosted one.

If it is stored but no email arrives

Here the cause is the notification or the mailbox. Check that the recipient field is not empty or misspelled; an empty field means no notification is sent. Webflow notes that clicking the unsubscribe link in a notification can leave that field blank, so it is worth looking even if you never edited it. On the free Starter plan, notifications are limited to five recipients and every recipient has to be a member of your Workspace.

Then think about the mailbox. Role-based addresses such as info@ or support@ are more likely to be filtered, so a name-based address is a quicker test. Webflow lists the sender addresses to allow at your mail provider (no-reply@webflow.com, no-reply@webforms.io and no-reply-forms@webflow.com). If none of that works, your provider may have rejected Webflow's mail before, and Webflow keeps a blocklist; only Webflow Support can lift it.

• Send the notification to a second address at a different provider as a test.
• Add the three sender addresses to the allow list and check the spam folder.
• Webflow's form submissions page gives the free Starter plan a lifetime limit of 50 submissions; the count is shown under General, Overview in site settings.

What does not fit, and how the paid repair is accepted

If the emails are accepted by your provider but land as spam because your own domain lacks authentication, that is a mail-domain job; the email authentication guide covers it. A form that is a third-party embed, or a flood of junk submissions, is also a different problem.

The fixed-scope repair of one form is priced at £145 as an untested proposal and paid only after you sign off. It is accepted when a labelled test from the published page appears in the stored submissions and arrives at the named address, with every field present and the old and new settings listed. Mailbox filtering at your provider stays outside what anyone but your provider can guarantee.