Defaults.Exposed › Fixes › Guides

Contact Form Emails Going to Spam — The Web-Server Sender Fix (2026)

Published 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

Contact-form and website emails land in spam because your web server sends them unauthenticated — no SPF authorisation, no DKIM signature. The reliable fix is routing that mail through authenticated SMTP, not whitelisting the server. 46.4% of the 261,086,232 domains graded in the Defaults.Exposed census (data as of 2026-06-29) publish no SPF record at all.

The fix order matters and most tutorials get it backwards. Run a free scan to see what your domain actually publishes; route the site’s mail through authenticated SMTP (your mailbox provider or a transactional email service) so it gets a real DKIM signature; fix the form’s From address; and only add the server’s IP to SPF as a last resort.

Why do emails from my website go to spam?

Because of who is really sending them. When a visitor submits your contact form, the email isn’t sent by your mail provider — the web server generates it itself, usually via PHP’s mail(). From the receiving side, that message:

• comes from an IP your SPF record doesn’t authorise (your SPF covers your mail provider, not your web host);
• carries no DKIM signature, so nothing cryptographically ties it to your domain;
• often leaves from a shared hosting IP whose reputation is set by hundreds of strangers’ sites.

Unauthenticated mail from a mixed-reputation IP is exactly what spam filters exist to catch — Gmail and Outlook see a random server claiming to be you. The wider baseline is grim: 46.4% of domains publish no SPF at all, and only 10.59% (27,640,987 of 261,086,232 graded domains, census as of 2026-06-29) enforce a DMARC policy.

Why does this hit WordPress sites in particular?

WordPress sends all of its email — form notifications, password resets, order confirmations — through one function, wp_mail(), which by default wraps PHP mail() on the web server. Every WordPress site that hasn’t been deliberately reconfigured is an unauthenticated sender out of the box. Form plugins (Contact Form 7, WPForms, Gravity Forms) all hand mail to the same function: it looks like a plugin problem but is a transport problem.

The fix is not a different form plugin but an SMTP plugin (WP Mail SMTP and its equivalents), which reroutes everything wp_mail() sends through a real, authenticated mail account — infrastructure your SPF already authorises, with a DKIM signature attached.

Which sending method should the site use?

For a few notifications a day, SMTP through the mailbox you already pay for is the shortest path; at real volume, a transactional service is built for it. Both give you DKIM — the IP-whitelisting shortcut never does.

How do I fix contact-form email deliverability?

1. Run the free scan at defaults.exposed before touching anything. It shows what SPF, DKIM and DMARC your domain actually publishes — whether you’re fixing the form’s transport, a missing record, or both. No SPF at all? Start with how to fix SPF.
2. Create a dedicated SMTP identity for the site — e.g. [email protected] in your mailbox provider, or a verified sending domain in a transactional service. Use an app password or API key you can revoke, not a person’s mailbox password.
3. Route the site’s mail through it. WordPress: install an SMTP plugin and point it at that account. Other stacks: configure the framework’s mailer instead of local mail().
4. Fix the From address (the anti-pattern below): From must be your own domain; the visitor goes in Reply-To.
5. If the sender is a transactional service, add its DKIM records (usually a pair of CNAMEs) so mail is signed with your domain — the DNS steps mirror the SPF setup walkthroughs.
6. Send a test submission and re-scan. Headers should show spf=pass and dkim=pass for your domain; then clear anything else the scan flags via fix SPF and fix DKIM.

Why is the form sending “from” the visitor’s email address?

The most common self-inflicted wound in form configuration, and many plugins used to do it by default: the notification arrives From: the visitor’s address, so you can hit reply. It feels convenient, and it’s forgery. Your server has no right to send mail as [email protected] — it fails SPF and DKIM for gmail.com, and Gmail’s DMARC policy tells receivers to junk or reject it. The fix costs nothing:

• From: an address at your own domain (the SMTP identity from step 2)
• Reply-To: the visitor’s address — reply still goes straight to them

Every mainstream form plugin supports this; it’s two fields in the notification settings.

Why not just add the server’s IP to my SPF record?

It’s the fix most forum threads reach for first, and it’s the fallback for a reason. Adding ip4:<server> (or an a mechanism for your web host) to SPF does make the raw check pass — but:

• On shared hosting it authorises strangers. The IP belongs to the box, not to you; every other site on that server can now send SPF-passing mail as your domain.
• It breaks silently. Hosts migrate servers and rotate IPs without telling you; your SPF keeps authorising an address you left months ago.
• It gives you no DKIM. SPF alone breaks under forwarding and can’t carry you toward DMARC enforcement the way a signature can.

Reserve this route for the genuinely constrained case: a dedicated server with a static IP you control and an application that can’t speak SMTP — and pair it with DKIM signing on the box if you can.

Does SPF even check the address my form puts in “From”?

No — and this trips up half the DIY diagnoses. Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header. Web servers often stamp their own hostname onto the Return-Path, so your SPF record was never consulted at all — the receiver checked SPF for srv0421.examplehost.com. Authenticated SMTP fixes this too: the Return-Path becomes your domain, so the SPF pass finally counts for you. It’s also why DKIM matters — DMARC alignment needs a pass tied to the domain in From, and a DKIM signature travels with the message.

Frequently asked questions

Will an SMTP plugin fix password-reset and WooCommerce emails too? Yes. On WordPress everything flows through wp_mail(), so rerouting it fixes form notifications, password resets and order emails in one move.

Do I still need SPF and DKIM records if I use an SMTP plugin? Yes — the plugin changes which infrastructure sends your mail; the records are what authorise it. If your domain is among the 46.4% of 261,086,232 graded domains with no SPF record (census, 2026-06-29), authenticated SMTP alone won’t save you. The new-domain email checklist covers the full record set.

My form emails pass SPF but still fail DMARC — why? Almost always the From-spoofing anti-pattern above, or SPF passing for the host’s Return-Path domain rather than yours. Fix From/Reply-To first; if it still fails, the missing piece is an aligned DKIM signature — see “DKIM signature not valid”. If SaaS tools beyond the website fail too, the SPF-failing-for-SaaS guide covers the fix order.

Is it worth all this for a low-traffic contact form? The form is usually where the money enters — a missed enquiry is a customer you never knew you lost. And the fix is free; the barrier is knowing the web server was the unauthenticated sender all along.

Send the owner the report

If you’re the developer or contractor fixing this: once the test submission passes, re-run the free scan and forward the graded report to the site’s owner — a dated, plain-language record that the domain authenticates properly, and the artefact they’ll need for the next cyber-insurance renewal or customer security questionnaire. If you’re the owner reading this because enquiries stopped arriving: send this page and your scan report to whoever runs your website — a one-afternoon job with a before-and-after they can show you.

Check your domain → · SPF failing for your SaaS tools? → · Fix SPF → · How we grade → · Aggregate data only. Data stored and processed in the EU.