I get this one a lot: “Our contact form emails keep going to our own quarantine. Why is Microsoft flagging messages from… us?”
Here’s what happens when your website leads have died down….
You test your website contact form. You expect a tidy little lead notification. Instead: silence → quarantine → mild panic.
And the truth is painfully simple: your website is sending email as you, but it isn’t trusted to do so.
Those contact forms are quietly slipping into the void without you even realising it and it could be consting you money.
The plain-English version
Most website forms fire an email to you (your real mailbox) using your domain in the From address. If Microsoft 365 or Google Workspace sees an email “from” your domain but not sent from a server you’ve authorised, it smells spoofing.
Two checks matter here:
- SPF: a list of servers allowed to send mail for your domain.
- DKIM: a cryptographic signature proving the message is genuinely from you.
If your website’s server IP isn’t in SPF (or if the form system can’t sign DKIM properly) your own contact form starts looking like a phishing attempt.
Why this happens so often
SPF is usually easy: add the website’s IP to the record and you’re done.
DKIM is where it gets messy. Some CMS or form plugins simply don’t support it. Others support it but need custom selectors or DNS gymnastics. And if you use a proper mailer like Brevo/SendGrid/Postmark, the fix is clean but that’s extra setup some agencies don’t want for a “simple form”.
So people leave it. And Microsoft 365, being Microsoft 365, doesn’t.
Quick fix: tell Microsoft 365 to trust that IP
If you want a practical, stop-the-bleeding fix, you can explicitly trust the website server IP in Microsoft 365. This bypasses spam filtering for just that source — not ideal long-term, but very helpful when you need your forms working today.
Here’s the exact process I share with clients.
How to trust your website’s sending IP in Microsoft 365
- Go to Microsoft 365 Defender
https://security.microsoft.com - In the left menu:
Email & Collaboration → Policies & Rules → Threat Policies - Under Rules, select:
Mail Flow Rules - Click Create Rule.
- Name it something clear, like:
Bypass spam filtering for website contact form - Set conditions:
Apply this rule if… → The message… → Has sender IP address
Enter the IP address of the server that actually sends the form emails. - Under Do the following… choose:
Modify the message properties → Set the spam confidence level (SCL) to –1
(SCL –1 = “treat as trusted, skip spam filtering”.) - Save.
It applies immediately. Your contact form emails stop vanishing.
Inbox Test: one thing you can try today
Send a test from your website form. Check the message headers in 365.
If you see SPF: fail or DKIM: none, the platform is doing exactly what it’s meant to do. Blocking an untrusted sender.
Longer-term fix
This bypass rule works, but you still want:
- SPF updated with your website’s IP (or mailer’s SPF include).
- DKIM signed via your form mailer or transactional service.
- DMARC set to at least none so you can watch alignment.
It keeps your root domain clean and stops Microsoft from guessing.
Reality check
Most “contact form deliverability issues” aren’t real deliverability issues. They’re trust issues. You haven’t clearly told Microsoft or Google who is allowed to send as you.
Sort that, and 90% of the noise goes away.
Need more help?
If you want a quick reputation read or help untangling SPF/DKIM on a messy web stack, book a 30 minute call with Quinset‘s top email deliverability expert, Ben Fielding. I’ll point out the gaps and the fastest safe fix.
