By Mehdi HassanWhy are website form emails not delivered?
Website form emails aren't delivered because inbox providers can't verify that the message really came from your domain. A typical form sends a notification that says it's from your domain, or worse, from the visitor's address, through a server that isn't authorized to send for either. Gmail and Outlook treat that the same way they treat phishing.
Since 2024, Gmail and Yahoo have required authentication from bulk senders, and in practice unauthenticated mail from anyone is more likely to be filtered or rejected. Your form may only send a few messages a week, but it's judged by the same rules. The result is silent: the visitor sees "thanks, we'll be in touch", and the lead sits in spam or disappears.
Forms are one of the quiet pieces of hosting that founders don't think about until something breaks. Our guide to website hosting for startups maps the other pieces, and this guide fixes the email one.
What are the most common causes of form emails going to spam?
Most form email problems come from five causes, and many sites have more than one. Go through them in this order, because the first two are the most common and the quickest to fix.
Cause | What happens | Fix |
|---|---|---|
From address is the visitor's email | Your server claims to be gmail.com, so DMARC fails | Send from your domain, put the visitor in reply-to |
Mail sent by the host's default mail function | No authentication; shared IP reputation | Use a transactional email service |
No SPF or DKIM for the sending service | Inbox can't verify the sender | Add the service's DNS records |
No DMARC record | No policy, weaker trust, no reports | Publish a DMARC record, start in monitoring |
Spam submissions sent as notifications | Filters learn your notifications are junk | Block bots before they trigger emails |
Hosted builders like Framer and Webflow send notifications from their own systems, so authentication for those emails is the platform's job. Problems there usually come from spam rules on your side, or notifications going to an inbox nobody watches. Code-based sites, where your team chooses how mail is sent, are where most of these five causes show up.
How do SPF, DKIM and DMARC work together?
SPF, DKIM and DMARC are three DNS records that prove email from your domain is genuine. SPF lists which services may send mail for your domain. DKIM adds a cryptographic signature that inboxes check against a public key in your DNS. DMARC tells inboxes what to do when a message fails, and sends you reports.
- SPF (Sender Policy Framework): one TXT record on your domain listing your senders, for example your workspace email and your transactional service. You can only have one SPF record, so add services to it rather than creating a second one.
- DKIM (DomainKeys Identified Mail): each sending service gives you records, usually CNAMEs, to add. Once they're in place, the service signs your mail with your domain.
- DMARC: a TXT record at _dmarc.yourdomain.com. It checks that the visible From domain matches the domain passing SPF or DKIM, then applies your policy: none, quarantine or reject.
The alignment part of DMARC is why the visitor's address can't be the sender. If a message says it's from someone@gmail.com but was sent by your server, it fails Gmail's own DMARC policy. All three records live in DNS, so you need access to wherever your domain's DNS is managed; our domains, DNS and SSL setup guide shows how to find it.
What a sensible DMARC rollout looks like
Start with a monitoring policy (p=none) and a reporting address, so you receive reports showing which services send mail as your domain. Read them for a few weeks. You'll often find a forgotten newsletter tool or billing system sending without authentication.
Once every legitimate sender passes SPF or DKIM with alignment, move to p=quarantine, then p=reject. Jumping straight to reject can block your own invoices or product emails. Moving slowly costs nothing and protects your domain from spoofing once you're done.
How do you fix website form emails step by step?
You fix form emails by changing how they're sent, then authenticating the domain, then testing. Follow these steps in order. Most teams can do the whole thing in an afternoon with DNS access and access to the form code or settings.
Pick a transactional email service
Use a service built for app and form email, such as Postmark, Resend, Amazon SES or SendGrid, rather than the server's default mail function or a personal inbox password.
Verify your domain
Add the DKIM records the service provides, and add the service to your existing SPF record. Wait for the service to show the domain as verified.
Fix the sender fields
Send from an address on your domain, such as forms@yourcompany.com. Put the visitor's email in the reply-to field so replying still reaches them.
Publish DMARC
Add a DMARC record in monitoring mode with a reporting address, then tighten the policy once reports look clean.
Save submissions outside email
Send each submission to your CRM, a database or a sheet as well as email, so a filtered message never means a lost lead.
Block spam at the form
Add a honeypot field and a bot check such as Cloudflare Turnstile, so junk never triggers a notification.
Test with real inboxes
Submit the form to a Gmail and an Outlook address, check it lands in the inbox, and look at the message headers for SPF, DKIM and DMARC passes.
Should form submissions go to email at all?
Form submissions should go to email as a notification, but email shouldn't be the only place they live. Inboxes filter, people leave, and a shared address can stop being monitored. The source of truth for leads should be a system your team checks: a CRM, a database or at minimum a spreadsheet.
On a Next.js site, a form handler can write to the CMS or database, push to the CRM through its API and send the notification in one step. On Framer or Webflow, use the built-in integrations or a webhook to send submissions to your CRM. Either way, you get a record that doesn't depend on a spam filter, plus a way to report on lead volume.
Make sure the destinations are yours. If the agency set up the email service or the automation account under its own login, leads flow through someone else's account. That's one of the items on our website ownership checklist.
How do you stop form emails breaking again?
You stop form emails breaking again by testing them on a schedule and watching for changes that affect them. Most failures come back after something unrelated changes: a new email tool added to the domain, a DNS migration, a redesign that replaced the form handler, or a card expiring on the email service.
- Submit every important form yourself once a month and confirm it arrives in the inbox and the CRM.
- Keep DMARC reports flowing to an address someone reads, so new unauthenticated senders show up.
- Add form tests to any redesign or migration checklist, since a new site often has new forms.
- Set an uptime or synthetic check on the form endpoint if leads are a big share of your pipeline.
This is maintenance work that tends to fall through the cracks, because nobody owns it after launch. On our retainer, form checks are part of routine upkeep alongside the rest of the site. If leads have dropped and you're not sure why, our guide to whether your website problem is the platform or the copy helps you tell a delivery issue from a conversion one.
