Why your contact form goes to spam

Contact form emails spam often because the message fails authentication checks — SPF, DKIM or DMARC — or because a shared server's IP reputation is already poor. The form submits fine; the mail just never reaches the inbox. Fix the authentication first, then test content and sender reputation.

Key Takeaways

• Contact form emails spam most often when SPF, DKIM or DMARC checks fail, not because your copy contains a trigger word.
• Shared hosting means you inherit the sending IP's reputation; one compromised neighbour can sink your deliverability.
• Read the raw headers of a test message first — the pass or fail result tells you exactly what to fix.
• Adding DMARC before SPF and DKIM are working can reject legitimate enquiries outright.
• Switching to an SMTP relay or transactional API with an authenticated domain fixes most form spam permanently.
• A silent form is a revenue leak: you may not notice missing enquiries until a lead asks why nobody replied.

What actually happens when your contact form sends an email?

Your web server builds a message and hands it to a receiving mail server, which runs SPF, DKIM and DMARC checks before deciding placement. The receiving server asks two questions: does the sending IP match the domain's published SPF record, and does the message carry a valid DKIM signature. A fail on either, or a misaligned From header, adds spam weight — often enough to tip the decision.

The form plugin itself is rarely the problem. WordPress plugins such as Contact Form 7 or WPForms, a Laravel app using its mail driver, or a custom PHP script all converge on the same underlying mechanism: they call a mail transport, which may be the server's local sendmail, an SMTP relay, or an API. The transport, not the plugin, determines the sending IP and the authentication headers that reach the receiving server.

Why do shared-hosting forms land in spam more often?

Shared hosting places hundreds of tenants on one IP address, so your form mail inherits the reputation of every other site on that box. If one tenant sends bulk mail or gets compromised, the shared IP accumulates spam complaints and blocks. Gmail, Microsoft and other providers then treat all mail from that IP with suspicion, regardless of your own domain's history.

Switching from shared hosting to a VPS does not automatically fix this — a fresh VPS IP has no sending reputation at all, which is its own problem. What actually helps is sending through a relay with an established, monitored reputation and authenticating your own domain. For sites that have outgrown shared infrastructure, our team can help you assess the move; the trade-offs are covered in our shared hosting versus VPS comparison.

What do SPF, DKIM and DMARC actually check?

SPF (Sender Policy Framework) lists which servers may send mail for your domain in a DNS TXT record; a receiving server checks the sending IP against that list. DKIM (DomainKeys Identified Mail) adds a cryptographic signature, published via DNS, that proves the message body and selected headers were not altered. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties them together by requiring alignment between the visible From domain and the authenticated domain.

These three records live in your domain's DNS, not in the form plugin. You can inspect them with dig TXT example.com for SPF, dig TXT selector._domainkey.example.com for DKIM, and dig TXT _dmarc.example.com for DMARC. If the records are absent or the relay's IP is not included, the receiving server sees a failure it has to score — and spam is the default when the score is unclear.

How do I find which check is failing?

Send a test submission to a Gmail address, open the message, choose "Show original", and read the authentication results. The headers contain lines such as spf=pass, dkim=pass and dmarc=pass; a softfail, neutral, temperror or fail names the layer you need to repair. Do not change content until you know which check fails.

1. Send a test from the live form to a Gmail and a Microsoft 365 address; check both spam folders.
2. Open "Show original" in Gmail and find the Authentication-Results header block.
3. Read the SPF result. A softfail or neutral means your sending IP is not in the SPF record — add the relay's include or IP.
4. Read the DKIM result. A temperror usually means the selector is missing or the DNS TXT value is malformed.
5. Read the DMARC result. A fail means SPF or DKIM alignment broke — typically the From domain differs from the bounce or signing domain.
6. Run dig TXT example.com | grep spf and dig TXT default._domainkey.example.com to confirm the published values match the relay's instructions.
7. If all three pass and mail still lands in spam, test the content: send a plain-text message with no links, no attachments and no tracked URLs.

What configuration actually keeps form mail out of spam?

Send form mail through an SMTP relay or transactional API that authenticates your domain, and publish SPF, DKIM and DMARC in DNS. Set the envelope sender and From header to an address on your own domain — never the visitor's address — and include both plain-text and HTML parts. A stable, authenticated identity does more for deliverability than any content tweak.

Before you edit DNS, copy the current TXT records, keep the TTL low for the first test, and understand that a wrong SPF or DMARC value can reject legitimate mail until propagation completes. The change is a DNS edit, so it propagates globally within minutes to hours, not instantly. Test with a tool that reports DMARC alignment after each change.

For WordPress sites, the fix is usually a mail-sending plugin configured with SMTP credentials from your mail provider, rather than the default PHP mail() function. For custom web applications, configure the framework's mail driver to use the relay's host, port and TLS settings. Our WordPress development team regularly replaces silent PHP mail with authenticated SMTP for client forms.

What breaks when a form is "just fixed" without testing?

The most common failure after a quick fix is a DMARC reject introduced by enthusiasm: an operator publishes p=reject before SPF and DKIM pass, and legitimate enquiries are bounced with no notice. Another is configuring the From address as the visitor's email, which makes SPF alignment impossible and can trigger spoofing rules. A third is forgetting the bounce address, so failed deliveries go to a mailbox nobody reads.

In practice, we see forms that have been "working for years" silently delivering to spam after a hosting migration. The DNS records stayed with the old provider or the new IP was never added to SPF. The form still returns a success message, so nobody suspects a problem until a lead mentions they never got a reply. Regular test submissions to an external mailbox catch this before it costs an enquiry.

What does it cost in time and attention, not just money?

SPF, DKIM and DMARC are DNS records — there is no licence fee to publish them. The real cost is engineer time: diagnosing headers, updating DNS, configuring a relay, and testing across providers. Sending APIs and relays generally charge per message beyond a free tier, and the rate varies by vendor, so confirm current figures with the provider's own calculator before committing.

The larger cost is silent. A business form that lands in spam means missed sales enquiries, booking requests or support tickets, and you rarely measure what you never received. That is the strongest argument for spending a couple of hours on authentication: the ongoing operational overhead is nearly zero, while the cost of a broken form compounds every week. If you would rather not carry this yourself, our website maintenance service includes form deliverability checks as part of routine care.

Which sending method should you choose?

The right transport depends on volume, who operates the server, and how much visibility you need. PHP mail() needs no setup but gives you no authentication control and fails on shared hosts. An SMTP relay through your existing mail provider is the simplest genuine fix for low-volume business forms. A transactional API adds dashboards, webhooks and bounce tracking when volume grows.

The simpler option usually wins. If a contact form sends forty enquiries a month, an SMTP relay through your existing email provider is plenty — a dedicated IP is over-engineering that costs you time and attention. If the form is central to a booking or lead flow and you need bounce visibility, a transactional API earns its keep. The decision is really about who has to operate the sending path afterwards.

What security mistakes put form mail at risk?

Store SMTP credentials outside the codebase and rotate them if the site was ever compromised; a leaked credential turns your form into a spam cannon. Use an app password or a limited-permission account at your mail provider rather than the mailbox owner's main password. And never publish the private DKIM key — only the public selector record belongs in DNS.

A compromised form is a sender-reputation emergency. Attackers abuse it to send phishing or bulk mail from your authenticated domain, which burns the exact reputation you spent time building. If you ever see a sudden spike in bounce messages or a provider block, check the form's mail logs and the server's outbound queue before touching DNS. Our team can help with securing the sending path during an incident response.

A realistic example: an enquiry form that went quiet

A clinic's WordPress site used Contact Form 7 with PHP mail() on shared hosting. Bookings arrived for years, then went quiet after a hosting move. The form still showed "message sent". The raw headers of a test showed spf=neutral and dkim=temperror — the new server's IP was not in the SPF record, and the DKIM selector pointed at the old DNS host.

The fix took an afternoon: point the form at an SMTP relay, publish the relay's SPF include and DKIM selector, add a DMARC record with p=none for monitoring, then send test mail to Gmail and Microsoft addresses until all three checks passed. Only after that did we tighten DMARC. The lesson is the order: authenticate first, monitor, then enforce.

In short: contact form emails spam because the receiving server cannot authenticate the sender or mistrusts the sending IP. Read the raw headers, fix SPF and DKIM first, monitor with DMARC before enforcing, and switch the form to an authenticated relay. Then test with a real external mailbox once a month and the problem stops being a guess.

People also search for

• Does shared hosting affect email deliverability?
• How much does a custom web form cost to build?
• Should I use an off-the-shelf form plugin or custom code?
• Do mobile app forms have the same spam problem?
• How do I test if my website email is being marked as spam?
• What do SPF, DKIM and DMARC records look like?
• Who can monitor my website forms for deliverability issues?

If your enquiry form has gone quiet and you would rather not chase mail headers yourself, talk to our team. We can audit your DNS, switch the form to an authenticated relay, and add a monthly test submission so you learn about a deliverability problem before your leads do.