Over three years ago my company changed to a new domain name. Until recently, we paid to keep the old domain active while people updated their records. When the renewal came up the partners decided to not renew the old one.

So just recently, a number of regular contacts have had issues emailing some of my coworkers. They have sent some bounced email messages to us, and it shows:

The email address displays correctly (e.g., rock.shale@slaterock.com)

But in the data dump below, it shows the email is still being sent through the obsolete server (e.g., srg.com). Our IT folks did a thorough check to see if the problem could be on our end, but they can't find anything.

We have advised they delete the person's contact and make a new one, and then delete the 'autocomplete' prompt that comes up when starting to type Rock Shale's contact info. (Sorry for the Flintstones-themed examples.) One of our clients says she tried that, but when Emailing my coworker and copying me (someone she didn't have in her contacts), it came through to me and not to him again. Maybe she missed a step... but is there any other trick here? I'm not sure how the new email address would trigger the old domain.

Unfortunately, we can't control what someone outside our company is doing, but I'd like to be able to give a clearer direction. It's only a few instances from a few people. One client can email our president, but not another of the senior people - it may be because they created a new contact for the president after the domain name change?

Thanks for any ideas.

Ann

You are already dealing with the most probable cause. Delete Outlook Auto-Complete records and add the new address as a Contact.

Redirecting
NK2Edit: Edit AutoComplete files (.NK2) of Microsoft Outlook

Are the old and new domains hosted by the same company? I'm thinking problems with the MX records. But that should affect any mail going thru the provider.

From way out in left field: Have a client, who is still sending to the old domain, do a MX Lookup on both the old and new domains.
https://mxtoolbox.com/

Thanks, Hornblower, for the feedback and suggestions.

I honestly have no idea as that was handled by someone else, but I just sent the question to our IT consultant, along with the results I got when I used the MX lookup on our current domain. It says:

SMTP Reverse DNS Mismatch Reverse DNS does not contain the hostname Information More Info
Status Warning SMTP Banner Check Reverse DNS does not match SMTP Banner

Hopefully, if that is an issue, or THE issue, he can look into it for us.

Cheers,

Ann

>> along with the results I got when I used the MX lookup

More useful to your IT people would be the MX Lookup results from one of the clients who says their mail to you is not being delivered to the correct domain.

I see. I will suggest that in the morning if they haven't gotten any further.

With one person, we tried his emailing to one of the set-up aliases for our coworker. For example, our standard emails are first initial, middle initial, and last name, though there is a workable one with the first name only before the @. This did get the email through from the outside person to the inside person, though when inside person replied, naturally it came from his main email, and then outside person couldn't just hit reply and get through. The inside person would have to remember to customize the Reply-To every time, unless there is a way to fiddle with the Outlook Rules to do that for him? I haven't sussed a way to make that happen.

With another sender, their IT is now in touch with our IT, so maybe we'll reach a solution. It's been a head-scratcher! Why just these few people have the issue, I don't know.

Before we go off into aliases. It would be very helpful if we had a cleaner test case.

Do you by any chance have two people at the same outside company (i.e. Alice@External and Bob@External) where one sending you mail gets thru but the other fails?

Another piece of info that would be helpful is the Internet Headers from a message that bounced. (The original message, not the Non-Deliverable reply).

Have Alice@External open one of the messages she sent to you that bounced and then File -> Properties. Have her copy everything in the "Internet headers:" box at the bottom of the Properties dialog and send it to you. (Using an alias I guess).

Look thru the headers and verify that it was indeed sent to the new domain, and see if you can spot the first occurrence of the old domain name (if any).

Yes, that should be happening between our IT and their IT. As I understand it, it’s not everyone in the other company. Their IT person was going to be asked to send an email. My guess is it will go through as he or she won’t have had our Chris stored in the contacts.

It may clarify to their IT person that the problem is not with us. But in case it doesn’t, I was hoping to offer a workaround.

Good idea. We’ve only seen the data dump that comes after the undeliverable message. Will suggest this in the morning.

Also, all of these people seem to have no trouble emailing me. I did have an email with the old domain, but they would have had no direct business with me back then. It seems linked to those who have old contact info in their system, though “Alice” says her IT helped her clear the old contact and her auto-complete info. I’m assuming, though, it lingers, because the alias email does work and doesn’t redirect. Maybe her IT person wrote the whole thing off as our problem and didn’t bother to check.

When Alice@External is composing a new mail, after she types part of a name and selectes a recipient (the "To" field is populated and the name is underlined), have her double-click on the name in the "To" field. This should show a popup with the full email address under the name.

Finally an update on this situation. And maybe an understanding of why it's happening precisely with two different firms in particular.

One of the client/partner companies finally had their IT person look a little deeper. It turns out that they had our engineer in their internal system, and with the wrong domain. Once that was removed, everything seems to be working.

Also a bit more discussion yielded that these companies had added our guy to their Teams group essentially with his own separate log-in as if he were internal. I recall this causing some issues with Teams at one point, as our guy has to log out as himself and in as his entity for them. I didn't have enough info to put it together, but that's probably exactly where the bad info is stored. If they set up the Teams stuff in 2020 while we were figuring out how to operate under COVID, we didn't change domains until 2021. The only odd thing is that this was something that never came to the surface until we finally decided not to renew the old domain.

We're seeing if the other company can get their IT person to really get in there and look for our guy's info.

At least, finally, something.

Thanks for all your help and suggestions, Hornblower. The main struggle was getting someone at the other companies to really take a look and not just presume the issue was on our side.

Best regards,

Ann