thecomputerguy
Well-Known Member
- Reaction score
- 1,414
I recently went through a whole debacle with a new client that I shouldn't have taken per here: https://www.technibble.com/forums/threads/its-the-clients-they-just-kill-me.89505/
The short of it is I was approved to set the client up on O365 by the owner of the company but then the owners assistant came in and backtracked and forced me to set the new mailboxes up on Gsuite making me re-do the whole job.
The mailboxes were brand new and were to be setup empty. I setup the mailboxes on O365, changed DNS ... good to go. After the back track I unassigned the licenses at O365, deleted the user accounts at O365 then refunded the licenses at O365.
Then I created the boxes at Gsuite, changed DNS again, then deleted ALL records required by O365 including MX, Autodiscover, SRV, and text records. So now her DNS looks completely clean of O365, only contains the MX and TXT records for Gsuite.
The owner sent an email from her other domain (which exists on O365 NOT GSUITE) to an email address I created AT Gsuite and got an O365 bounce back even though MX points to Gsuite and the mailboxes don't exist at O365. Is this some sort of caching conflict at O365 or something?
TLDR: bob@contoso.com originally existed at O365, then when they backtracked I deleted bob@contoso.com at O365 then created bob@contoso.com at Gsuite and changed records from O365 to Gsuite.
She is able to send mail fine, I sent her a test message from my Google account and it was delivered fine. Why does the internet think it should be sending mail to O365 still?
This job was finalized and billed for 5 days ago on 3/17/2023 so you'd think any caching would be finalized by now?
The only DNS records outside of mail including A records, NS, and a WWW cname record all point to their hosting platform ... Wix.
It's almost like O365 is trying to deliver the message internally or something, completely disregarding MX because it used to be there.
The short of it is I was approved to set the client up on O365 by the owner of the company but then the owners assistant came in and backtracked and forced me to set the new mailboxes up on Gsuite making me re-do the whole job.
The mailboxes were brand new and were to be setup empty. I setup the mailboxes on O365, changed DNS ... good to go. After the back track I unassigned the licenses at O365, deleted the user accounts at O365 then refunded the licenses at O365.
Then I created the boxes at Gsuite, changed DNS again, then deleted ALL records required by O365 including MX, Autodiscover, SRV, and text records. So now her DNS looks completely clean of O365, only contains the MX and TXT records for Gsuite.
The owner sent an email from her other domain (which exists on O365 NOT GSUITE) to an email address I created AT Gsuite and got an O365 bounce back even though MX points to Gsuite and the mailboxes don't exist at O365. Is this some sort of caching conflict at O365 or something?
TLDR: bob@contoso.com originally existed at O365, then when they backtracked I deleted bob@contoso.com at O365 then created bob@contoso.com at Gsuite and changed records from O365 to Gsuite.
She is able to send mail fine, I sent her a test message from my Google account and it was delivered fine. Why does the internet think it should be sending mail to O365 still?
This job was finalized and billed for 5 days ago on 3/17/2023 so you'd think any caching would be finalized by now?
The only DNS records outside of mail including A records, NS, and a WWW cname record all point to their hosting platform ... Wix.
It's almost like O365 is trying to deliver the message internally or something, completely disregarding MX because it used to be there.
Last edited:
