Your WordPress Form Isn’t Broken:
The GoDaddy Microsoft 365 and Proofpoint Email Trap
This post contains an affiliate link. If you sign up through it I earn a commission at no extra cost to you, and it never changes what I recommend.
You build a site, wire up the contact form, send a test, and nothing arrives. So you check the form plugin. You install an SMTP plugin. You check the spam folder. You send another test to your own Gmail and it lands instantly, which makes no sense, because the client’s address is the one that matters and it’s the one getting nothing.
I lost about thirty hours to this, including more than one full day on the phone with support. The form was fine the entire time. The problem was a piece of infrastructure I didn’t know was in the path.
If your client is on Microsoft 365 bought through GoDaddy, there is a second spam filter sitting in front of Microsoft, and it is probably the thing eating your form notifications.
The Mail Path You Think You Have
Here’s the mail path almost every web designer has in their head when a form notification goes missing:
WordPress → Microsoft 365 → inbox
Here is the path on a GoDaddy Microsoft 365 account:
WordPress → your mail sender or SMTP relay → Proofpoint Advanced Email Security → Microsoft 365 → inbox
That third step is the one nobody accounts for. GoDaddy’s Microsoft 365 offering increasingly bundles an add-on called Advanced Email Security, which is powered by Proofpoint, and it filters inbound mail before Microsoft ever sees it.
The mailbox says Microsoft 365. The webmail looks like Microsoft. So every fix you search for is a Microsoft fix, and none of them can work, because the message is already gone one hop earlier.
GoDaddy is also in the middle of migrating this add-on from a previous provider called INKY over to Proofpoint. That’s worth knowing, because troubleshooting advice written even a year ago may describe a completely different security layer than the one currently holding your email.
Inbound Domain Spoofing Protection, and Why Your Form Trips It
The specific control is called inbound domain spoofing protection, and once you know it exists the whole thing makes sense.
Its job is to stop somebody outside your company sending mail that claims to be from inside it. That’s a real and common attack, and the protection is reasonable.
Now consider what a WordPress contact form does. It sends a notification from hello@theirdomain.com to hello@theirdomain.com. It originates on a web server, which is not the client’s office, not Microsoft, and not anywhere the filter recognizes. From the filter’s point of view that is indistinguishable from the attack it exists to prevent.
The filter is reading your form as somebody impersonating your client, using your client’s own address. Spam scoring never enters into it.
The Documentation Contradiction That Cost Me Days
Here’s the part that cost me the most time, and it’s the reason I’m writing this at all.
GoDaddy’s documentation describes that setting as quarantining mail from your own domain when it originates somewhere not approved by SPF. Read plainly, that says a correct SPF record exempts you. So you go and fix SPF.
Proofpoint’s own description of the same protection is broader. It says that when inbound domain spoofing protection is enabled, any message arriving from one of your own domains scores high enough to be quarantined.
Those two descriptions do not say the same thing, and my experience matched the second one. We had SPF authorizing the sending server, validated, and comfortably inside the ten DNS lookup limit. DKIM and DMARC were both in place. The mail was quarantined anyway.
If you read only GoDaddy’s version, you will spend days perfecting an SPF record that was already correct.
What Was Already Tried
For anyone about to suggest the obvious, here is what was already done:
- SPF, DKIM and DMARC all configured and authenticated, with the sending server’s IP explicitly authorized and the record validated.
- An external SMTP relay tested during troubleshooting, to rule out the web server sending mail directly. Same result.
- Messages released from quarantine, and marked as safe and as false positives.
- Domain-level allow-listing applied more than once.
- Inbound sender DNS checks adjusted by support.
- More than one full day on the phone with GoDaddy support, on separate occasions, without resolution.
- Throughout all of it, the identical notification delivered normally to external addresses on other providers.
The reason none of that worked is that most of it addresses the wrong control. Releasing a message from quarantine and marking it safe affects how that message is scored. Allow-listing operates on senders. The anti-spoof rule is a separate protection with its own configuration, and Proofpoint documents a specific inbound filter for permitting messages from your own domain, which is not the same thing as the allow list.
Support can reach that filter, and further down this page are the steps one of them used. Whether a customer can reach it themselves depends on the console they are given. That may be why the support calls went nowhere. If the console in front of the person helping you only shows the allow list, the allow list is what they will keep adjusting.
One more detail worth knowing: anti-spoofing policy changes can take up to an hour to apply. If you test immediately after a change, you can read a working fix as a failure and undo it.
The Workaround That Does Work
A second client of mine, on the same GoDaddy and Microsoft 365 arrangement, hit exactly this. Their GoDaddy helper fixed it, and the fix was not the allow list.
It was a filter policy, which is a separate control in the Proofpoint admin. That single fact explains why weeks of releasing messages and allow-listing the domain changed nothing on the first project. Those are different settings, and none of them override an anti-spoof quarantine.
Credit where it is due. One GoDaddy rep, Eva, knew immediately what this was and had it fixed in minutes, after two separate eight-hour days with other people got nowhere. The steps below are hers. The knowledge plainly exists inside GoDaddy. It just is not reaching the first person who picks up the phone, and that gap is what turns this into a thirty hour problem instead of a ten minute one.
These are the steps that were sent to that client. I have not run them myself, so treat them as the thing to ask your provider for as much as a recipe to follow, particularly if your console differs.
- In the Proofpoint Essentials admin, open Email in the left menu, then Filter Policies, then New Filter.
- Give the filter a name you will recognize later. Something like contact form.
- Continue. The scope populates itself with the company domain.
- Set the condition to IF Email Subject, then contains any of.
- Enter the exact subject line your form notification sends. If your form emails arrive titled New enquiry from the website, that string goes here.
- Set the action to ALLOW.
- Tick Override Previous Disposition. It is easy to miss and the filter will not hold without it.
- Save, and allow up to an hour before you judge whether it worked.
Override Previous Disposition is the important one. The anti-spoof rule has already decided to quarantine the message by the time this filter is evaluated. Without that box ticked, the filter has nothing to override and the quarantine stands.
Why This Fix Is Fragile, and What to Write Down
Matching on a subject line works, and it creates a quiet dependency that nobody will remember in six months. The filter only holds while the subject stays exactly the same.
Rename a form. Edit the notification template. Add the company name to the subject for tidiness. Any of those breaks the filter, and the emails start disappearing again with no error, no bounce, and no obvious connection to a form change made three weeks earlier.
So if you use this, document it somewhere the next person will find: that a Proofpoint filter policy exists, that it matches on this exact subject string, and that changing the subject silently breaks inbound form mail. A better version of this filter would match on something more stable than a subject line, and if your provider will build that instead, take it.
How to Diagnose This in Ten Minutes
The whole thing is diagnosable in about ten minutes if you know to look, and the test is embarrassingly simple.
Send the form notification to two addresses. One on the client’s domain, one on any outside provider.
If both fail, it’s your form or your sending setup, and that’s the normal problem with the normal fixes. If the external address receives it and the client’s own domain doesn’t, stop touching WordPress entirely. You have a receiving-side problem, and the answer is in the client’s mail security, not in your plugin.
That single split would have saved me most of thirty hours.
Delivered Does Not Mean Inboxed
There’s one more trap in here that made the problem harder to see than it needed to be.
When your sending service reports a message as delivered, that means the receiving infrastructure accepted it. It does not mean the message reached the inbox. It can be accepted and then quarantined, junked, or held, and your logs will still show a clean delivery.
So you sit there looking at a delivery log that says everything worked, while the client sits there with an empty inbox, and you both start to doubt each other. Delivered means accepted. Inboxed is a separate question you have to confirm from the receiving side.
What I Changed in My Process
What changed here was my process. The plugin was never the problem.
Before configuring a contact form on any build now, I map the mail path first: the website, then whatever genuinely sends the mail, then the recipient’s mail gateway, then the mailbox. Four steps, and the third is the one that gets skipped.
Then I authenticate the service doing the sending, confirm DMARC exists, and send those two test messages, internal and external, before I hand anything over. If there’s a security gateway in front of the client’s mail, I would rather find it on day one than on day four.
If the domain, hosting and website side of this is unfamiliar territory, my guide to website hosting for small business covers how those pieces relate, and Gmail dropping Send As for domain email covers a separate change coming to domain email in January 2027 that catches people the same way.
Why I Keep Hosting, Email and Domains Separate
This experience also changed how I think about where a small business should keep its email.
The trouble wasn’t that any one product was bad. It was that the domain, the hosting, the website and the mail security were tangled together in one account, bought as a bundle, with a filtering layer in the middle that nobody had deliberately chosen. When something broke, there was no clean place to stand and look at it.
For what it’s worth, I keep those things apart in my own setup. I host on Hostinger, my email comes from somewhere else, and my domains are managed separately. I still have one old domain sitting at GoDaddy and that’s the extent of it, which is a decision I made well before this project and feel considerably better about now.
If you’re already locked into GoDaddy’s Microsoft 365 ecosystem, none of this is an argument for tearing it out mid-project. But if you’re choosing email for a new build, and you get to choose it independently, choosing a provider whose actual business is email will save you a category of problem that’s very hard to see from the outside.
Frequently Asked Questions
Why do my WordPress form emails work for external addresses but not the client’s own domain?
Because the message is arriving from your web server claiming to be from the client’s domain, and their mail security treats that as a possible impersonation attempt. External recipients have no reason to care. The client’s own gateway does. If external works and internal fails, the problem is on the receiving side.
What is GoDaddy Advanced Email Security?
It’s an inbound email filtering add-on on GoDaddy’s Microsoft 365 plans, powered by Proofpoint. It sits in front of Microsoft 365 and filters mail before Microsoft sees it. GoDaddy has been migrating it from a previous provider called INKY, so older advice may describe different software.
Does fixing SPF solve same-domain quarantine on GoDaddy?
It didn’t for me. SPF authorized the sending server, the record validated and sat well inside the DNS lookup limit, DKIM and DMARC were both in place, and the mail was still quarantined. GoDaddy’s documentation implies SPF approval is enough. Proofpoint’s description of the same protection is broader. Fix SPF because it should be right anyway, and don’t expect it to be the answer on its own.
Does releasing from quarantine stop it happening again?
Not in my experience. Releasing a message and marking it safe affects the handling of that message. The anti-spoof protection is a separate control. Proofpoint documents a specific inbound filter for permitting mail from your own domain, which is a different setting from the allow list.
How do I tell whether this is my problem in ten minutes?
Send the form notification to the client’s own domain and to any outside address at the same time. Both failing means it’s your sending setup. Only the internal one failing means it’s their mail security, and you can stop debugging WordPress.
Does a delivered status in my SMTP logs mean the email arrived?
It means the receiving server accepted it. The message can still be quarantined or sent to junk after that, with your logs showing a successful delivery the whole time. Confirm from the receiving side before concluding the mail went through.
Written from a single build in September 2026. If you are in the middle of this right now, run the two-address test before you change anything else. My website design work is where my client work starts if you would rather not.