← NotesField noteLead Capture7 min read

Why Contact Form Emails Go to Spam — What I Check First

Contact-form emails that land in spam usually fail at the same handful of email-authentication and sender-reputation checks. Here's what I look at first.

Email-delivery flow: a visitor submits the form, the website server sends from your own domain with Reply-To set to the visitor, SPF/DKIM/DMARC authentication passes, and the lead reaches the inbox and is stored in a database — versus the failure path where mail sent as the visitor is flagged as spam.

A business owner tells me they aren't getting leads. The website works. The form submits. The visitor sees the "thanks, we'll be in touch" message. But the email never arrives in the inbox — or it lands in a junk folder the owner stopped checking months ago. Most of the time, the form is fine. The deliverability is what's broken.

A broken contact form is dangerous because it looks like it works. The visitor gets a thank-you message, the owner assumes no one is reaching out, and the business quietly loses leads without seeing the failure.

What I check first: deliverability, not the form

Before I look at the form itself, I look at the email. If the form has been submitting cleanly for years and the owner only stopped getting leads recently, the form code probably didn't change — something on the email side did. If the form has never reliably delivered, the email setup was likely wrong from day one.

In either case, the first place I look is email authentication.

The three email records I check first

When a contact form sends an email, the receiving server (Gmail, Outlook, Apple Mail, etc.) checks whether the sending domain is authorised to send that message. Three records on the sending domain's DNS are the main signals.

SPF (Sender Policy Framework). A TXT record published on the sending domain (often the root domain) that lists which servers and services are allowed to send mail on its behalf. If your contact form sends through a service like SendGrid, Resend, Mailgun, or Postmark, that service needs to be included in your SPF record. Missing or misconfigured SPF is one of the most common reasons form emails get marked as suspicious.

DKIM (DomainKeys Identified Mail). A cryptographic signature attached to outgoing emails that proves the message came from a server authorised by your domain. DKIM is usually set up by adding one or two CNAME records that your email-sending service provides. Without DKIM, even legitimate emails look spoofable to receiving servers.

DMARC (Domain-based Message Authentication, Reporting and Conformance). A policy that tells receiving servers what to do when a message fails SPF or DKIM checks — and where to send reports back. Even a basic p=none DMARC record gives you reporting and shows that the domain has a policy in place. It isn't a deliverability fix by itself, but it's often the first safe step before moving to stricter policies like quarantine or reject.

When all three are correctly set up for the domain your form sends from, deliverability is meaningfully better. When one or more is missing or mis-set, even legitimate, expected emails can get flagged. Google's email sender guidelines explicitly recommend SPF, DKIM, and DMARC for every sending domain — and although the strict requirements that landed in 2024 target bulk senders, the broader direction is clear: major inbox providers increasingly expect properly authenticated mail from everyone.

Important caveat: SPF, DKIM, and DMARC don't always fix the problem. They're the first place I check because they're the most commonly broken — but if all three are correctly set and emails are still going to spam, the cause is somewhere else.

When it isn't the records

A short list of other things that quietly kill form-email deliverability:

From-address mismatch. The form says it's sending "from" the visitor's email address (so the owner can hit reply), but the email actually originates from a server that has no authority over the visitor's domain. Receiving servers spot this and flag it. The rule: the form should not send as the visitor. It should send from an address on your own domain — website@yourdomain.com or similar — with the visitor's email placed in the Reply-To header. That preserves the one-click reply without breaking sender authentication.

Shared hosting mail. Sending email through cheap shared hosting (the PHP mail() function on a budget host) almost always lands in spam — the IP address has bad reputation by association with every other site on the same server. Routing through a real transactional email service (Resend, Postmark, SendGrid, Mailgun) usually fixes this.

No reply-to header set. Without a reply-to header, the owner replies to the noreply address instead of the visitor, who never hears back. This isn't a deliverability issue but it kills the funnel just as cleanly.

Sender reputation. A new domain or a previously-spammy domain takes time to build reputation with the major email providers. Even with correct records, brand-new sending domains may land in spam for a few weeks while reputation builds.

Spammy form content. A submission that includes the word "Viagra" or a URL in every field will get flagged on the spam-content side, regardless of authentication. Most legitimate forms don't have this problem — but if you're running a public form with no spam guard, you'll see this in the noise.

No CAPTCHA or honeypot. A public form with no spam protection will collect bot submissions, and a flood of bot emails to the same inbox can degrade the owner's domain reputation over time. A simple honeypot field — invisible to humans, irresistible to bots — costs nothing to add and stops most automated submissions.

Poor email headers from the form-handler. Some plugins and form builders generate emails with malformed or missing headers. Receiving servers treat these as low-quality and route them to spam. The fix is usually to switch to a more reliable form handler or to a transactional email service.

The safer setup

For most small-business forms, the setup that consistently works:

  • Send through a real transactional email service (Resend, Postmark, SendGrid, Mailgun) — not raw PHP mail() on shared hosting.
  • Send from an address on the business domain (e.g. website@yourdomain.com), not as the visitor.
  • Put the visitor's email in the Reply-To header so a one-click reply still reaches them.
  • Authenticate the sending domain with SPF, DKIM, and DMARC.
  • Add a honeypot or CAPTCHA to keep bot submissions out of the noise (and out of the sender-reputation hit they cause over time).
  • Store every submission server-side — in a database, CRM, or notification log — so email is never the only copy of the lead.

That last bullet is the single most important one for a lead-capture system. Email is unreliable; the database is your audit log. If a legitimate submission ever gets filtered, you should be able to retrieve it from the backend instead of losing the lead. Never make email the only place the lead exists — it's worth its own piece, which is exactly why your website should store every lead in a database.

How to actually test

The fastest way to know if your form emails are getting flagged:

  1. Send a real test submission through the form to a personal Gmail address and a personal Outlook address. Check both inboxes and both spam folders.
  2. Check the email headers of whatever did arrive (Gmail: "Show original"). Look for dkim=pass, spf=pass, dmarc=pass. Anything that says fail or neutral is a lead.
  3. Run the sending domain through a tool like mail-tester.com — paste in their generated test address as the form's recipient, submit a form, then load their report. They'll tell you exactly which authentication checks failed.
  4. Ask the owner to check the spam folder for the last 30 days of real submissions. Sometimes that's where most of the missing "leads" already are.
  5. Confirm the lead is stored somewhere besides email — a backend table, a CRM record, a spreadsheet row, a notification log. If email is the only copy and email is unreliable, the lead-capture system has a single point of failure built into it.

What this means for a small business

A broken-deliverability contact form is one of the highest-cost, lowest-visibility failure modes in a small-business website. The site looks fine. The form looks fine. The leads simply don't arrive — or they arrive somewhere the owner doesn't look. By the time the owner notices the pattern, they've often missed dozens of real inquiries.

A working contact form means: emails are authenticated, routed through a reliable sender, monitored for failures, and set up so every legitimate submission has the best possible chance of reaching the inbox — with the reply-to set so a one-click reply reaches the customer, and the submission stored server-side so the lead isn't lost even if the email is filtered. Anything less than that is leaking the work the rest of the site is doing.

Sources: Google Email sender guidelines, Microsoft sender requirements, DMARC.org, mail-tester.com. Observations through May 2026.

Where to Start

If you suspect your form emails are leaking, start by testing the path from visitor → inbox → saved lead. Submit the form yourself, check the headers of whatever arrives, confirm SPF/DKIM/DMARC on the sending domain, and make sure the submission is stored somewhere besides email.

If you want a plain-English review, a free audit will check the sending setup, authentication records, form routing, spam protection, and whether your site has a backup path for every lead — automated structural checks plus the option to request a human review of the deliverability layer specifically. For the broader lead-capture picture, the contractor-focused Website & SEO for Canadian Contractors page covers what turns visitors into calls once the emails are reliably arriving.

Darrell Pardy

Darrell Pardy

Founder of Lightly Coded — an Alberta web systems studio for small businesses across Canada and North America.

Last updated June 1, 2026.

Request a free audit

Preferred way to reach you
Run a free auditCall