Webflow form emails: why they go missing, and how to fix it.

Every designer who has shipped a Webflow site has had this moment: a client calls and says "we haven't received any form submissions in a week." You check the Webflow dashboard — submissions are there. You check the client's inbox — nothing. The problem is almost never Webflow losing data. It is the notification email being filtered by Outlook, Mail.ru, or strict corporate filters before the client ever sees it.

How Webflow sends form email

Webflow forms have three delivery options:

• Default email notification. Sends a templated message from Webflow's shared sender to the addresses you list in the site settings or in the form's Send Email to field.
• Form webhook. POSTs the submission payload to any URL. You receive it programmatically and handle email yourself.
• Third-party integration (Zapier, Make, n8n). Uses the webhook under the hood but wraps it in a no-code orchestration tool.

Option one is what most Webflow users leave turned on. The email header looks approximately like this:

From:         Webflow <mailer@webflow.com>
Reply-To:     submitter@gmail.com
Return-Path:  bounces+xxx@mailer.webflow.com
DKIM-Signature: d=mailer.webflow.com; s=wf202301; ...
Subject:      New form submission from Your Site

[ form field 1 ]
[ form field 2 ]
...

The From header shows "Webflow" rather than the client's brand. DKIM is signed by mailer.webflow.com. If the receiving mailbox has strict filters or treats unknown senders conservatively, the message often ends up in Junk.

Why some submissions never arrive

Three failure modes we see repeatedly when auditing Webflow sites:

1. Outlook / Office 365 false positives

Outlook's filtering is aggressive for senders it does not recognise. A new Webflow site sending to a corporate Office 365 mailbox will often see the first dozen notifications land in Junk, or worse, Quarantine (which requires admin release). Over time as someone marks "not junk", reputation improves, but many clients never think to check Junk at all.

2. Shared reputation dips

Webflow's shared sender pool is generally clean, but when another Webflow customer gets reported heavily, placement for other customers can drop briefly. These dips are short (hours, not days) but noticeable on low-volume sites where a single missed lead matters.

3. Strict DMARC on the recipient's domain

If the form recipient is something like hello@yourclient.com, and that domain hasp=reject on DMARC, and the From header is set to hello@yourclient.com — you are effectively spoofing the client's own domain from Webflow's infrastructure, without authorisation. Strict receivers reject outright. This is a common Webflow footgun: designers set the From header to the client's address thinking it looks nicer, and break DMARC alignment.

The custom-domain-email workaround

To make Webflow form notifications look like they come from the client's own domain with proper authentication, you need to bypass Webflow's default mailer.

Option A: Zapier + SendGrid / Postmark

1. In Webflow, set the form to submit to Zapier via the built-in Webflow integration (uses the webhook under the hood).
2. In Zapier, add a Send Email step using SendGrid, Postmark, or Mailgun. Authenticate that provider against the client's domain (SPF + DKIM + DMARC).
3. Set From to forms@yourclient.com and Reply-To to the submitter. Body is pulled from the form payload.
4. Disable Webflow's default notification to avoid duplicate emails.

Added benefits: Zapier archives every submission, so even if email fails, nothing is lost. You can also fan out to Slack, CRM, or a Google Sheet in the same Zap.

Option B: Webhook to your own endpoint

If the client has developer resources, a small serverless function (Vercel, Cloudflare Workers, AWS Lambda) can receive the Webflow webhook and call a transactional API directly. Advantage: near-zero latency, no Zapier task cost. Disadvantage: someone has to maintain it.

Seed-test your Webflow forms

The only way to know what is actually happening is to test. Here is a reliable procedure:

1. Collect the list of addresses the form notifies. Double-check Webflow Site Settings → Forms and every form block's own override.
2. Submit each form once with a seed-test address — for example, the composite address provided by our free inbox checker. You get a single recipient that forwards to 20+ real mailboxes (Gmail, Outlook, Yahoo, iCloud, Mail.ru, etc.).
3. Check where each mailbox placed the notification. Outlook is where Webflow defaults tend to lose.
4. Inspect headers in Gmail. Look at Authentication-Results. DKIM should be either d=mailer.webflow.com (default path) or d=yourclient.com (Zapier + SendGrid path).

Rule of thumb by volume

• Under 20 submissions/day — default Webflow mailer is usually fine. Run one test per quarter.
• 20 to 200 submissions/day — consider Zapier + SendGrid. Outlook placement becomes the bottleneck.
• 200+ submissions/day — always use a custom transactional provider under the client's own domain. Do not depend on shared infrastructure.

Frequently asked questions