We have a client who previously used GoDaddy for Microsoft 365 along with its Advanced Email Security service, which is powered by Proofpoint Essentials. We defederated the tenant from GoDaddy more than six months ago, and mail flow worked normally until recently.
Now, one customer of the client—who also uses GoDaddy and Advanced Email Security—gets this bounce when sending mail: "550 5.7.1 Recipient address rejected: User email address is marked as invalid." The rejection references Proofpoint.
We can't find anything related to Proofpoint left in the client's environment: no MX records, connectors, mailbox rules, transport rules, enterprise applications, or other configuration. The problem only seems to affect senders who previously had or still have GoDaddy's Proofpoint service. Newly created mailboxes on our client's side can receive mail from other GoDaddy/Proofpoint users without trouble.
GoDaddy claims the Proofpoint account was deleted, but something clearly still appears to be routing or validating this domain through Proofpoint. Support has suggested resetting the Microsoft password, which doesn't make sense. Has anyone dealt with stale Proofpoint routing or recipient validation after leaving GoDaddy, and what specifically should we ask GoDaddy to purge or escalate?
3 Answers
Proofpoint can route mail based on a domain being configured in its system, even when the domain’s public MX records no longer point there. If GoDaddy really removed the service, they need to escalate this to Proofpoint and have the old domain, recipient directory, and routing configuration removed from the sender’s gateway. This is not something you should be able to fix in Microsoft 365.
This sounds like stale internal routing on the GoDaddy/Proofpoint side. Their system may still believe the domain is hosted in its Proofpoint environment, so mail from another Proofpoint customer gets sent through that internal route instead of following normal public mail delivery. Once it reaches the old tenant, the recipient is treated as invalid.
That fits the pattern. The issue only affects senders using Advanced Email Security, while ordinary senders and newly created addresses don’t have a problem.
Get the complete bounce, especially the reporting MTA, timestamps, recipient address, and any Proofpoint tracking ID. Then ask GoDaddy specifically for an escalation to the Proofpoint service team to purge stale recipient validation or routing for the domain on the sending tenant. Resetting the Microsoft password will not clear a Proofpoint domain configuration and is unrelated to this mail-flow failure.
I’ve seen similar behavior where a domain remained present in Proofpoint even though it was no longer actively using the service. The provider had to remove the stale configuration on its side.