The silent leak
The most frustrating form bugs are not explosions—they are leaks. Mail sends. Relays accept. The CRM never lights up because the message is sitting in spam, quarantine, or a mailbox alias that forwards to nowhere useful.
The visitor assumes you are ignoring them. You assume they never wrote. Everyone loses.
Why form mail spams more than you expect
Contact forms often send from addresses the recipient does not recognize: wordpress@, noreply@, or the visitor’s own address forged as From: (a pattern some CF7 templates still use). Filters hate that.
Shared hosting IPs carry history. A new site on an old IP inherits someone else’s sins.
Missing or misaligned SPF, DKIM, and DMARC makes receivers guess—and guessing means “junk folder” more often than not.
The story I see repeat
A client moves to Microsoft 365. Marketing updates the website footer email. Nobody updates SPF include records or enables DKIM signing for the form’s sending path. Submissions “work.” Sales says leads are down. IT insists mail flow is fine.
The truth is in quarantine and junk, not in the SMTP plugin’s green dashboard.
What I do when spam is the suspect
- Send a test from the real form—not from my personal Gmail.
- Check inbox, spam, promotions, and admin quarantine (M365 and Google differ).
- Read headers on a message that landed wrong: SPF pass? DKIM pass? DMARC align?
- Fix authentication before tweaking copy or changing plugins.
For a structured rollout, I follow our SPF, DKIM, and DMARC together guide. Blog posts are for the “why”; that doc is for the “how.”
Culture fix, not just DNS
Someone on the team should skim the spam folder weekly on addresses that receive forms. Boring? Yes. Cheaper than unexplained revenue dips.
Form testing that stops at “SMTP sent” will not catch this class of failure. You need evidence in the recipient mailbox—the place the business actually lives.
I would rather explain authentication to a client once than explain a quarter of missed leads later.