Why your contact form emails are going to spam (and six fixes that actually work)

You built a contact form. It works. You tested it. Submissions arrive in your inbox.

Then, three weeks later, someone messages you on LinkedIn saying they filled in your form on Tuesday and never heard back. You search your inbox. Nothing. You search spam. There it is — their message, along with six others you didn't know existed, all quietly filtered into a folder you never check.

This is one of the most common contact form failures, and it has almost nothing to do with the form itself. It's an email deliverability problem. The good news: it's fixable. The bad news: the fixes are not always where people look first.

Here are the six fixes, in the order I'd try them.

Fix 1: stop sending from the visitor's email address

This is the single most common cause, and it's the one people are most reluctant to change because it feels intuitive. Here's what's happening.

Your form collects the visitor's name, email, and message. The notification email that lands in your inbox has a From header that looks like:

From: visitor@example.com
To: you@yourcompany.com

The idea is that you can click "Reply" and it goes straight back to the visitor. Convenient! Also, increasingly, filtered as spam.

Modern email infrastructure uses SPF, DKIM, and DMARC to verify that an email claiming to come from a domain actually came from a server authorized to send for that domain. Your form backend is not authorized to send from example.com — only Example's own mail servers are. So when the email arrives at your inbox, your provider sees:

• From: visitor@example.com
• Sent by: your form backend's mail server
• SPF check: fails (backend not authorized for example.com)
• DMARC policy: reject or quarantine

Result: the message lands in spam, or worse, gets bounced entirely.

The fix: configure your form backend to send notifications from your own verified domain, not from the visitor's address. Put the visitor's address in the Reply-To header instead. That way the email passes authentication, lands in the inbox, and clicking reply still goes to the visitor.

In FormTo this is the default. In older form backends it's often a setting you have to flip. Check yours.

Fix 2: set up SPF, DKIM, and DMARC for your own sending domain

If you're sending notifications from your own domain, you need to make sure your domain is allowed to send from wherever your form backend lives. This means DNS records:

• SPF — a TXT record that lists the servers allowed to send email as your domain
• DKIM — a public key the backend uses to sign outgoing messages
• DMARC — a policy record that tells receivers what to do when SPF/DKIM fail

Every serious form backend publishes the exact records you need to add. The instructions usually look like:

Type: TXT
Host: @
Value: "v=spf1 include:formto.dev ~all"

And another two or three records for DKIM and DMARC. Add them to your DNS provider (Cloudflare, Namecheap, Google Domains, whoever manages your domain), wait ~15 minutes for propagation, and your deliverability improves significantly.

Without these records, your form notifications are flying completely unauthenticated. Gmail and Outlook are getting stricter about unauthenticated mail every quarter. In 2024 they started outright rejecting some unauthenticated bulk senders. You do not want to be on the wrong side of this curve.

The fix: add the SPF, DKIM, and DMARC records your backend asks for. This is the highest-impact one-time fix on the list.

Fix 3: stop using @gmail.com as the destination for form notifications

This one feels unfair but it's real. Gmail personal inboxes apply aggressive spam filtering, especially to automated messages with patterns that look like marketing. Your form backend's notifications — even perfectly configured ones — can get filtered by Gmail's heuristics because they look like automated emails (because they are).

Solutions, in order of effort:

Easy: create a Gmail filter that never sends form notifications to spam. Go to Gmail settings → Filters → Create new filter. Match on your form backend's sending domain (e.g. from:(*@formto.dev)) or on a unique subject line pattern (subject:("New submission")). Set the filter to "Never send to spam." Done. Every future notification from that sender bypasses the filter.

Better: use a dedicated email address for form notifications that isn't Gmail. A transactional inbox on your own domain (using Google Workspace, Fastmail, Proton, whatever) has much more lenient filtering for messages sent to it.

Best: don't route form notifications to email at all. Pipe them into Slack, Discord, or Microsoft Teams via a webhook. Email is the 2008 solution. In 2026 you want form submissions to land in a chat channel your team actually watches.

The fix: add a Gmail filter that exempts your backend's domain, or (better) route notifications somewhere other than personal Gmail.

Fix 4: warm up your sending domain

If you just set up a new domain for form notifications and nothing is arriving in inboxes, the issue might be that your domain has no sending reputation yet. Email providers don't trust brand-new domains. They need to see consistent, legitimate traffic before they'll deliver messages normally.

This is less of an issue if you're using a form backend that sends from its own established domain (most do). It becomes an issue if you've configured the backend to use a custom sending domain you just bought.

The fix: send a few dozen messages from the new domain over a week or two — not all at once — before you rely on it for critical notifications. Include yourself as a recipient and mark the messages as "not spam" if they land in the spam folder. This teaches your inbox that the sender is legitimate, and it contributes to the domain's reputation at the provider level.

If you don't want to do this warm-up dance, use the backend's default sending domain, which is already warm.

Fix 5: clean up your notification subject lines

A surprisingly common culprit: your form notification subject is too marketing-y, too generic, or contains spam-trigger phrases. Subjects like:

• "🎉 NEW LEAD FROM YOUR WEBSITE!!!"
• "Free contact form submission"
• "URGENT: New form submission"
• "Act now: someone contacted you"

These look exactly like promotional spam to filters. Even if everything else is configured correctly, a subject line that screams "marketing email" is going to get flagged.

Compare that to:

• "New message from Jane Smith via contact form"
• "Contact form: question about pricing"
• "From Jane — contact.yoursite.com"

Descriptive, specific, reads like a real message. Much less likely to be filtered.

The fix: customize your notification subject line. Most backends let you use template variables like {{name}} or {{subject}} in the subject. Use them.

Fix 6: route important notifications outside of email entirely

This is the "give up on email" option, and at this point in 2026 it's the one I recommend most often.

Email is a great medium for long, thoughtful correspondence. It is a terrible medium for "something just happened that needs your attention in the next few minutes." The combination of spam filters, folder tabs, notification batching, read/unread confusion, and the simple fact that most people have 3,000 unread emails means important notifications routinely get lost.

Slack, Discord, Microsoft Teams, Telegram — any of these are better for real-time form notifications. They have explicit channels, pingable @here mentions, and a social contract that notifications in the channel will be read within the hour.

Set up your form backend's webhook to POST to a Slack/Discord incoming webhook URL. Paste in a simple template that formats the submission into a readable message:

{
  "text": "New message from {{name}} ({{email}}):\n> {{message}}"
}

Now every submission pings a channel in under a second. Nobody needs to check an inbox. Nobody gets spam-filtered. Replies happen fast.

I wrote about the end-to-end latency of this in the 280ms journey post and about why fast replies double your conversion in the response time teardown. The short version: if you move your contact form notifications from email to Slack, your reply rate will improve in a way you can measure in the first week.

The fix: route form notifications to a chat channel instead of email, and use email as a backup only.

A quick checklist

If you have a form right now that you suspect has a deliverability problem, run through this in order:

• The form notification email's From: header is your own verified domain, not the visitor's
• Reply-To is set to the visitor's email (so you can still reply with one click)
• SPF, DKIM, and DMARC records are configured for your sending domain
• You've tested delivery to Gmail, Outlook, and at least one other provider
• Your notification subject line is descriptive, not marketing-ish
• A Gmail filter exists to rescue any legitimate notifications from spam
• You've added a Slack/Discord webhook as a real-time backup
• You've sent a test submission this week to verify the whole loop

Eight items. Most of them are one-time configurations. None of them cost anything beyond the time it takes to set them up.

The thing I want to leave you with

Form submissions that end up in spam are one of the most expensive silent failures a small site can have, because you do not know they're happening. Every week you go without a submission, you assume "traffic is slow." Every month you go without a submission, you assume "the market is tough." Meanwhile, ten real humans tried to contact you, and their messages are sitting in a folder you haven't opened since 2022.

Audit this once. Fix it properly. Then sleep better.

---

FormTo ships with correct SPF/DKIM configuration for its own sending domain, sends notifications with a From header on our verified domain and the visitor's address in Reply-To, supports Slack/Discord/Teams webhooks on every plan including free, and lets you customize subject lines. None of which is uniquely clever — it's just the set of defaults that a 2026 form backend should actually have.

Related: how forms die silently covers six other silent failures that are not about email, and the response time teardown has the numbers on why real-time notifications matter more than you think.