Your contact form "works", but does the email arrive? (the Microsoft 365 junk trap)
Last reviewed: 21 July 2026
A contact form that shows "thanks, we'll be in touch" and still loses the enquiry is the most expensive bug on a website, because nobody sees it fail. The usual culprit: Microsoft 365 quietly files the form's email into Junk.
The silent failure
Your form submits. The visitor gets a success message. The server even sent the email. And it landed in the business's Junk Email folder in Microsoft 365 (or Google Workspace), where nobody looks. From the outside everything worked. In reality you just lost a lead, and you will lose the next hundred the same way until someone happens to check junk.
Why 365 in particular? Transactional mail, a message generated by a server, often "from" a visitor's address but actually sent by your website's host, trips exactly the signals spam filters are built to catch. Microsoft's filtering is aggressive by default and will not tell you it is quarantining you.
Test it end-to-end, including the junk folder
The only test that counts is a real submission you follow all the way to the inbox:
- Fill in the live form as a visitor would and submit it.
- Go to the destination mailbox and confirm the email landed in the Inbox, then check the Junk and Quarantine folders too. "It submitted fine" is not a test.
- Test from an outside address (not the same domain), because same-domain mail is often auto-trusted and hides the problem.
- Retest after any change to the form, the host, or the DNS.
If it is landing in Junk, do not just drag one message out, fix the trust signals below so it stops happening.
Get the mail trusted: SPF, DKIM, DMARC
Most form mail gets junked because it is not authenticated. Three DNS records tell Microsoft the mail is legitimately from your domain:
- SPF lists which servers are allowed to send as your domain. The address your form sends from (or through) must be included.
- DKIM cryptographically signs the mail so it cannot be forged and can be proven to come from you.
- DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails.
Get all three right and the mail arrives trusted. A common trap: the website sends through a different service than your normal email, so it passes your email's SPF but not the form's. Send through an authenticated path and include it in SPF. (Mail authentication is fiddly and provider guidance changes, so confirm SPF, DKIM and DMARC against Microsoft's current documentation.)
The reliability pattern we build into forms
Getting mail delivered is half the job. The other half is a form that resists spam without silently eating real enquiries:
- Honeypot field. A hidden field a human never sees or fills in. Bots fill it; you reject anything that does. No puzzle for real visitors.
- Per-IP rate limit. Cap how many times one address can submit in a short window, so a bot cannot hammer the form and get your domain blacklisted for the flood of mail it triggers.
- A spam check that fails open. If your spam-scoring or captcha service is down, let the message through rather than block a real customer. A form that blocks everyone when a third party hiccups is worse than a bit of spam.
- Branded error pages. When something does go wrong, show your own styled "something went wrong, here is another way to reach us" page, not a raw server error. You keep the lead by giving them another way through.
- Redirect to a real thank-you page. Send successful submissions to a dedicated thank-you page. It confirms success to the visitor, gives you a clean conversion to measure, and stops a page refresh from re-submitting the form.
If you would rather we built the form and the site so this never happens, that is exactly the kind of thing our Sydney web design work is set up to get right.
The short version: Microsoft 365 quietly junks contact-form email, so a form that "submits fine" can still lose every lead. Test end-to-end and check the Junk and Quarantine folders, from an outside address. Fix SPF, DKIM and DMARC so the mail is trusted. And build the form properly: honeypot, per-IP rate limit, a spam check that fails open, branded error pages, and a redirect to a thank-you page.
General guidance: mail authentication and filtering behaviour change over time; confirm SPF, DKIM and DMARC against your mail provider's current documentation.
Where this comes from
The primary sources behind the above, so you can check any of it yourself rather than take our word for it:
- Microsoft Support, the current documentation for Microsoft 365 mail filtering, junk handling and quarantine.
- Australian Cyber Security Centre, the national source of guidance on email and domain security for Australian businesses.
- Phishing, background on the forged-sender problem that SPF, DKIM and DMARC exist to solve.