Why are my contact form emails going to spam?

The Junk folder is the visible half of the problem. The invisible half is that the email was your only copy of the lead.

An isometric diagram of a website form submission moving through validation, storage and notification stages.

Say you run a kitchen fitting firm in Bristol. Two fitters, a van each, and a website with a contact form nobody has touched since 2021. Quotes used to come through it. Lately they haven't, so you've put it down to a slow autumn.

Then a woman rings to ask why you ignored her message. You search the mailbox. There it is in Junk, eleven days old, sitting underneath four others.

Contact form emails going to spam almost always comes down to one thing: the form sends mail straight out of your web server, using a From address on your own domain that the server has no authority to use. Receiving mail servers look for that authority, find none, and file the message as junk. Publishing the right records fixes the Junk folder, but not the bigger problem, which is that the email was the only copy of the lead.

That second half is what most advice skips.

Why are my contact form emails going to spam?

Because the mail is unauthenticated, and the From address on it looks forged.

Most website forms hand the message to whatever mail function the platform ships with. On WordPress that's wp_mail(), which by default falls through to PHP's mail() and posts the message straight from your hosting server. That server has nothing to do with your email provider. It has never sent mail for your domain before. It just starts.

Three DNS records (the public settings that travel with your domain name) decide what a receiving server does next.

  • SPF (Sender Policy Framework), a published list of the servers allowed to send mail for your domain. Your web host is almost never on it.
  • DKIM (DomainKeys Identified Mail), a cryptographic signature proving the message really came from your domain and wasn't altered in transit.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance), the policy telling receivers what to do when the first two fail: nothing, quarantine, or reject outright.

Then there's the self-inflicted version, which is more common than the first. Whoever built the form set the From address to the visitor's own email so that hitting reply would work. Tidy.

It also means your web server is sending mail claiming to be sarah@gmail.com, which is a precise description of a spoofing attempt, and Gmail treats it as one. From belongs to your domain. Reply-To is where the visitor goes.

Do Gmail and Outlook sender rules apply to a small contact form?

Not the volume rules, no, and nearly every article on this subject implies they do.

Google publishes email sender guidelines with requirements that bite above 5,000 messages a day to Gmail: SPF and DKIM configured, DMARC published (a policy of p=none is enough), valid forward and reverse DNS, TLS in transit, spam complaints under 0.30 percent. Those landed in February 2024, and enforcement against non-compliant traffic ramped up from November 2025, with both temporary and permanent rejections.

Microsoft did the same for Outlook.com, Hotmail and Live addresses. Its requirements for high-volume senders use the same 5,000 a day threshold. From 5 May 2025, non-compliant mail from those domains started going to Junk, with outright rejection promised for a date Microsoft hasn't named.

Your form sends six messages on a busy day.

So why does any of it matter? The checks run on every message, not just the bulk ones. Those rules didn't invent SPF and DKIM. What changed is how much benefit of the doubt an unauthenticated message gets, and the answer now is very little. Which tells you what to ignore: you need three DNS records and one authenticated sender, not a deliverability consultant.

Why isn't my contact form sending emails at all?

Because your website confirms the submission, not the delivery. Those are different events, and only one of them is visible to the visitor.

Someone fills in the form. Your site accepts it, returns HTTP 200 (the code meaning the request was handled), and swaps the form for "Thanks, we'll be in touch." They put the phone down and wait for you. Nothing in that exchange required an email to arrive anywhere.

A diagram of a contact form submission travelling through validation, storage and notification, showing where a lead disappears when the email step fails silently.
A diagram of a contact form submission travelling through validation, storage and notification, showing where a lead disappears when the email step fails silently.

The ways it dies quietly are boring and numerous:

  • The SMTP handshake fails, SMTP being the protocol that carries mail between servers, and the plugin writes the error to a log file nobody has opened.
  • The notification address belongs to an office manager who left in March.
  • A mailbox rule somebody built in 2019 files anything containing "quote" into a folder under Archive.
  • reCAPTCHA v3, which scores visitors silently instead of showing them a challenge, rates a real person below your threshold and the submission is discarded before it's stored anywhere. Those scores are probabilistic, so a customer on a VPN or a privacy-hardened browser can read as a bot.
  • A plugin update resets the SMTP settings to defaults and the form reverts to PHP mail().

None of that appears in your analytics. Your form conversion rate looks healthy, because the form did convert. You just stop hearing from people, gradually, and you put it down to the market. It's the counting problem again, the same one behind how many calls your business is missing: you cannot act on a loss you have no record of.

How do I stop losing leads from my contact form?

Store the lead on your side before you try to send anything. The order is the fix.

  1. Validate the submission and write it to a database, on your infrastructure, before the page returns anything to the visitor.
  2. Only then show the success message. If the write fails, show a real error and a phone number, rather than a thank you the visitor will believe.
  3. Send the notification from an address on your domain, through an authenticated transactional service. Postmark, Amazon SES, Mailgun and SendGrid all do this properly. Set Reply-To to the visitor.
  4. Publish SPF, DKIM and DMARC for whichever service you picked. Start DMARC at p=none so you can read the reports for a few weeks without blocking your own mail.
  5. Push the same record to wherever your team actually looks: the CRM, a shared channel, a WhatsApp group. This is the point where a website form becomes a process worth automating rather than an inbox item.
  6. Alarm on silence. If nothing has come through in 72 hours, something is broken, and a scheduled job noticing that costs far less than a customer noticing it.

Do that and the email demotes itself to a notification. When one lands in Junk you lose an hour, not a job. That single reordering is worth more than every deliverability tweak above it, and it's the half the plugin guides leave out.

Speed is why it matters. The gap between a submission and your first reply decides whether you get the work, which is the whole argument behind lead response time settling who books the job. An eleven day old message in a Junk folder isn't a slow reply. It's a lost one.

What changes for website form email at the end of 2026

One date belongs in your calendar, and it applies to any site relaying form mail through a Microsoft 365 mailbox.

Microsoft has published an updated deprecation timeline for SMTP AUTH basic authentication: disabled by default for existing Exchange Online tenants at the end of December 2026. Tenants created after that won't have it available at all, with OAuth (token based sign-in, no password sitting in a settings box) as the supported method. A final removal date is due to be announced in the second half of 2027.

Plenty of small business sites authenticate to smtp.office365.com with a username and password typed into a plugin settings screen. That is basic authentication. An administrator will still be able to switch it back on for a while after the default flips, but the direction of travel is settled. For a website form the better answer isn't moving the mailbox relay to OAuth. It's ending the relay: use a transactional email API and take the mailbox out of the path.

Three months is plenty of notice. Go and find out what your form authenticates with before December decides for you.

When fixing your contact form isn't worth it

Two honest ones, and the first costs us work.

If your site produces four enquiries a month, the arithmetic doesn't support a rebuild. Say five percent fail silently. That's one lost lead every five months.

Paying anyone to re-plumb your intake is poorer value than spending the same money working out why only four people a month fill the form in at all. Fix the traffic and the offer first. We'd rather say so than quote for the wrong job.

The second: our recommended fix hands you an obligation you didn't have. While submissions evaporate into an inbox, they're someone else's storage problem. Once they sit in your database, you're holding personal data in a system you control, which means a retention period, a deletion route and a lawful basis under GDPR or UK GDPR. It isn't hard. It is real, ongoing and yours, and anyone selling you a lead capture system without raising it is doing you no favours.

What to do this week

Submit your own contact form, then go and find the record of that submission somewhere other than your email.

If you can't find one, that's the finding, and everything above is detail.

If you'd rather someone else took the form apart and told you what it's actually doing, that sort of audit is where most of our website development work starts. Two lines on the contact page is enough to begin.

Common questions

Still wondering

How do I check whether my domain has SPF, DKIM and DMARC set up?

Look up the TXT records on your domain. SPF sits on the root domain and starts with v=spf1. DMARC sits on _dmarc.yourdomain.com and starts with v=DMARC1. DKIM lives on a selector name your mail provider gives you. Any public DNS lookup tool will show all three in under a minute, and your email provider's admin console usually reports them too.

Should the contact form email come from the visitor's address?

No. Putting the visitor's address in the From header makes your web server look like it is forging mail for Gmail or Outlook, which is the fastest route to the Junk folder. Send from an address on your own domain that you have authenticated, and put the visitor's address in Reply-To instead. Hitting reply still works exactly as you wanted.

Is my form plugin's entries table enough to store leads safely?

It is far better than email alone, because the submission survives even when delivery fails. Two cautions. It lives in the same database as your site, so a hosting failure or a bad restore takes your leads with it. And nobody checks it without a prompt, so keep the notification and the alarm on silence running alongside it rather than treating the table as the whole answer.

Will an SMTP plugin fix the problem on its own?

It fixes the delivery half. Routing mail through an authenticated service instead of PHP mail is the right move, and it will get most messages out of Junk. It does nothing about a submission that is never stored, a notification address nobody reads, or a plugin update that resets your settings. Delivery and storage are separate problems and need separate fixes.