Troubleshooting Webflow form submission notification emails not delivered (after DNS or provider changes) Troubleshooting Webflow form submission notification emails not delivered (after DNS or provider changes)

Troubleshooting Webflow form submission notification emails not delivered (after DNS or provider changes)

System Admin System Admin

Purpose 

Provide a reliable, step‑by‑step guide to restore email notifications for Webflow form submissions when entries appear in the Forms panel but notification emails don’t reach the inbox.

Applies to

  • Customer can see form entries in Webflow (Designer or Workspace > Forms), but notification emails are missing.
  • Recent DNS changes (e.g., moved to Cloudflare) or changes to mail security (SPF, DKIM, DMARC).
  • Recipients on Google Workspace or Microsoft 365 (common), or any SMTP provider with strict filtering.

Symptoms

  • Submissions visible in Webflow Forms; no matching email in inbox.
  • Sometimes works for personal email (e.g., Gmail) but not company mailbox.
  • Customer enforces DMARC p=quarantine or p=reject.
  • Sender shows as platform default (e.g., no-reply@[platform-domain]) or a custom sender domain.

Quick answer (TL;DR)

  1. Confirm Webflow is logging submissions and the notification recipient address is correct.
  2. Test a different recipient (e.g., a personal Gmail) to isolate if the issue is the recipient’s mail system.
  3. Check mail authentication and security:
    • If using a custom sender domain: ensure SPF and DKIM are published and aligned for the sender.
    • If using the platform’s default sender domain: do not spoof your own domain in From; ensure your mail system allows that sender/domain.
  4. With Cloudflare changes: confirm MX records and mail security rules are intact; disable Email Routing unless intentionally used.
  5. Check recipient mail system logs/quarantine and allowlist the sender domain or sending IPs. If still failing everywhere, escalate with timestamps and samples.

Information to collect (before deep troubleshooting)

  • Form page URL and form name (e.g., “contact_main”).
  • Affected recipient address(es) (e.g., support@company.com).
  • Site ID or site URL.
  • Timestamp(s) of 2–3 recent test submissions in UTC.
  • Whether the sender is platform default or a custom sender domain.
  • Email provider (Google Workspace, Microsoft 365, other).
  • Recent DNS changes (registrar move, Cloudflare on/off, DMARC policy changes).
  • Whether reCAPTCHA is enabled and passing.

5‑minute triage checklist

  • Verify in Webflow: Submissions appear under Forms > Form submissions.
  • Verify notification recipient(s): Project Settings > Forms > Form notification settings.
  • Send a fresh test submission; note the UTC timestamp.
  • Change the recipient temporarily to a neutral mailbox (e.g., a team Gmail) and re‑test.
  • Ask the customer to check Spam/Junk and any security quarantine (Google Admin Email Log Search, Microsoft Message Trace).

Detailed troubleshooting

  1. Confirm Webflow side is healthy
  • Forms panel shows entries for the timestamp you tested.
  • Correct site is published after the last form or settings change.
  • No custom code blocking submit events (test with browser console and without extensions).
  • reCAPTCHA, if enabled, passes (failed challenges can block notifications).
  1. Validate notification configuration
  • Project Settings > Forms: Confirm each form’s notification recipients are correct (no typos, distribution lists can receive external mail).
  • If using “Reply-To” or custom sender fields, confirm they are valid email addresses.
  1. Test alternate recipients to isolate scope
  • Set a temporary recipient to a personal Gmail or Outlook.com address and submit again.
  • If messages arrive at the personal inbox, the issue is likely the company mail security or DMARC alignment for the original recipient.
  1. DNS and email authentication checks (root cause of most delivery issues)
  • MX records: Confirm they still point to the intended mail provider (moving A/CNAME for the website should not change MX).
  • SPF:
    • If sending as a custom sender domain, SPF must include the platform’s sending service per vendor docs (e.g., include:<platform‑spf>).
    • If using the platform’s default sender domain as From, your SPF for your domain is not relevant to that message; instead, allowlist the platform sender domain in your mail system.
  • DKIM:
    • If sending as your domain, publish the platform’s DKIM keys and ensure they pass.
    • If using the platform’s default sender, DKIM typically aligns with the platform’s domain; again, allowlist that domain in your mail system.
  • DMARC:
    • With p=reject, messages must align on domain (From vs. SPF/DKIM). If you send as your domain without correct SPF/DKIM alignment, delivery will fail. Either:
      • Use the platform’s default sender domain (no alignment with your domain required), or
      • Configure custom sender domain with working SPF and DKIM so DMARC aligns.
  1. Cloudflare‑specific checks
  • Email Routing: Ensure it is disabled unless intentionally used; misrouting can silently drop or redirect messages.
  • Proxied (orange cloud) has no effect on MX, but verify no accidental changes to MX/TXT records.
  • If using Cloudflare email security add‑ons, review quarantine/logs and allowlist the platform’s sender domain or IPs.
  1. Google Workspace (Gmail) recipient checks
  • Admin console > Email Log Search: Look up the test timestamps and recipient. Note rejects, quarantines, or spam dispositions.
  • Add the platform’s sender domain or sending IP range to your allowlist/approved senders.
  • Check content compliance rules and attachment limits; long URLs or certain headers may trigger filters.
  1. Microsoft 365 recipient checks
  • Exchange Admin Center > Mail flow > Message trace: Search by recipient and timestamp.
  • Review anti‑spam policies and allowlist the platform sender domain or IP range.
  • Check transport rules that may redirect to quarantine.
  1. Platform suppression lists and rate limits
  • If prior bounces/complaints occurred, the recipient might be on a suppression list. Remove the address from suppression and re‑test.
  • Large volumes of rapid test submissions may trigger temporary rate limits; pause and retry after a few minutes.

Resolution paths

Path A: Delivers to alternate recipient but not to company mailbox

  • Root cause: Recipient mail system policy.
  • Fix: Allowlist platform sender domain/IPs, relax or adjust anti‑spam policy, confirm distribution lists accept external mail, and ensure DMARC/SPF/DKIM policies align with your chosen sender model. Re‑test and restore original recipient.

Path B: Does not deliver to any recipient (including personal Gmail)

  • Root cause: Platform sending or configuration.
  • Fix: Confirm notification recipients in Project Settings, re‑publish the site, verify form is mapped to correct notification settings, clear suppression for the recipient, and contact support with timestamps and site details for upstream trace.


 

Was this article helpful?

0 out of 0 found this helpful

Add comment

Please sign in to leave a comment.