450 4.7.1 <remote.ourhostname.com>: Helo command rejected: Host not found

Bradleeeey 46

Hi guys,

I have inherited a mail server from my predecessor. We seem to be getting this error from the mail que when emailing a few of our clients. 99% of the time we have no issue with any other emails. We also seem to have our emails go to spam to gmail inbox's in case this is related. From a little reading it seems that we do not have a reverse DNS record configured for the remote.ourhostname.com which can be causing our emails to be handled as spam or rejecting causing a missmatch.

After doing some nslookups in cmd i got the ip tied to remote.ourhostname.com (it says its a non authoritative answer). I then did an nslookup of the ip it gave and it returned ourhostname.com missing the remote part(no message about being non authoritative). Could this be the issue? What's the solution if so?

Or am i missing the mark here and its a problem with certain clients hostnames?

BTW on our send connectors the FQDN is remote.ourhostname.com.

Appreciate all responses to this as I'm new to it. Thanks

Joyce Shen - MSFT 16,646 Reputation points

2021-12-10T05:46:41.953+00:00
Hi @Bradleeeey

Any update here about your issue so far? Agree with Andy's suggestion above.

And here is an article introduces about Fix Exchange Error 450 4.7.1 – Step by Step Guide for your reference
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

When Exchange server not able to find out the sender of mail or not able to find out the hostname, in that case Exchange error 450 4.7.1 is generated that will display that server can not find out reverse hostname. In this server performs reverse look up, in order to find out the address from where email is sent.
Note: Reverse DNS lookup find Domain Name associated with IP address using DNS of internet.

Resolution Of Exchange error 450 4.7.1

When any IP address sends any spam links or data, then generally that IP address is blocked by the server. In order to resolve this issue, there is need of removing IP address from the server’s blacklist.

One can contact internet service provider in order to PTR record in their IP address.

Domain records of DNS must be properly setup and by checking the mail server configuration.

Must setup reverse DNS with Fully Qualified Domain Name (FQDN).User can contact ISP for creating FQDN that should always be end up with valid domain name.

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Bradleeeey 46 Reputation points

2021-12-13T11:38:49.42+00:00

Hi joyceshen-MSFT,

Thanks for the reply. Issue in on going. We have called our provider BT to add a new PTR for us however we are unsure what to add to the A record currently to resolve the issue. Is there a specific priority that it needs to be? Do i add the ip pointing to the hostname or is it done the other way around?

Thanks.
Bradleeeey 46 Reputation points

2021-12-13T11:41:10.403+00:00

Hi, thanks for the response and sorry for my delay in reply.

I contacted out network provider (BT in this case) and they have added a PTR on their end. Am i right in saying that i just need to add an A record as AndyDavid said and the issue should be resolved? do i need an A record for the IP pointing to the hostname or the other way around? sorry im new to this.

Thanks
Joyce Shen - MSFT 16,646 Reputation points

2021-12-17T06:33:47.183+00:00

Hi @Bradleeeey

I noticed that you said that you still have issues when sending emails to some customers. This may be related to the configuration to different domains. And considering the urgency of your problem, I would suggest you open a ticket to Microsoft to get further support, thanks for your understanding!

Global Customer service Phone number:
https://support.microsoft.com/en-us/topic/global-customer-service-phone-numbers-c0389ade-5640-e588-8b0e-28de8afeb3f2

If you have contract of paid support for on-premises Microsoft products and service, submit the ticket from this portal:
https://support.microsoft.com/en-us/gp/contactus81?audience=commercial

Accepted answer

Andy David - MVP 142.2K Reputation points MVP

2021-12-13T15:02:43.353+00:00

alot of orgs do a forward lookup of the sending FQDN in the banner and see if it has an A record. So you could create an CNAME for remote.ourhostname.com that points to the same IP as you receive mail.
Please sign in to rate this answer.

1 person found this answer helpful.
Bradleeeey 46 Reputation points

2021-12-13T15:15:16.927+00:00

so would we type ourhostname.com as the host in the CNAME record and remote.ourhostname.com as the alias? or would it be the other way around?

Bradleeeey 46 Reputation points

2021-12-13T15:28:10.807+00:00

Hi there,

We get an error when adding the CNAME record saying that remote.ourhostname.com is within ourhostname.com zone. It also gives the error that these records should only be used for targets outside of the zone. We only have remote.ourhostname.com in our A records.

Andy David - MVP 142.2K Reputation points MVP

2021-12-13T16:28:32.843+00:00

Ok, I thought you said that didnt exist. If it does and the PTR records are set, then you should be good. Just make its all resolvable on the internet

Bradleeeey 46 Reputation points

2021-12-13T16:33:15.643+00:00

Apologies i believe i may of gotten confused at that point. When we go to remote.ourhostname.com from a browser it goes to an OWA (outlook web app). We have this in our A records. We also have a PTR record to resolve remote.ourhostname.com to our IP.

This is how our setup has always been. However we still seem to have issues stated in post when sending emails to some customers and also seems to have an issue with the helo command in exchange.

Do you have any other suggestions as to what this could be? thanks

Andy David - MVP 142.2K Reputation points MVP

2021-12-13T16:59:06.907+00:00

if you have a PTR for remote.ourhostname.com that resolves to the sending server IP, then it should work
Sign in to comment

4 additional answers

Andy David - MVP 142.2K Reputation points MVP

2021-12-09T15:12:39.107+00:00

Correct, you need an A record and PTR record for the IP of the sending mail server. remote.ourhostname.com.
Please sign in to rate this answer.

2 people found this answer helpful.
Bradleeeey 46 Reputation points

2021-12-13T11:36:33.013+00:00

Hi, thanks for the response and sorry for my delay in reply.

I contacted out network provider (BT in this case) and they have added a PTR on their end. Am i right in saying that i just need to add an A record as AndyDavid said and the issue should be resolved? do i need an A record for the IP pointing to the hostname or the other way around? sorry im new to this.

Thanks
Sign in to comment
Andy David - MVP 142.2K Reputation points MVP

2021-12-13T13:00:24.7+00:00

You should have a PTR record for sure. The PTR record is the reverse IP that points to theFQDN of the sending server.
I assume you already have an A and MX pointing to this server if it receives mail as well.

Have you tested again?

You can look it up here:

https://mxtoolbox.com/
Please sign in to rate this answer.

1 person found this answer helpful.
Bradleeeey 46 Reputation points

2021-12-13T13:08:59.64+00:00

Hi AndyDavid,

So we have an A record as you know and we have MX records however im not sure what would need to be added there for it. They are currently set for just ourhostname.com and point to our spam filtering service which then points to our email server.

rourhostname.com points to 4 different servers for our spam service as per there guidelines for set up. (we use spamhero). Do we need to add 4 more entries there using remote.ourhostname.com to each of the mail servers?

I tried the MX toolbox. We have a DNS record for ourhostname.com but remote.ourhostname.com shoes as one not being found?

Thanks.
Sign in to comment
Andy David - MVP 142.2K Reputation points MVP

2021-12-13T13:31:25.657+00:00

In that case, Each of the 4 servers needs its own PTR record that resolves to the FQDN of the sending server, not to remote.ourhostname.com
Make sense?

The FQDN that is in the banner is not necessarily the name of the server, but you need the PTR IP to resolve to a FQDN. Each sending server should have a FQDN and IP that resolvable in external DNS.
Please sign in to rate this answer.

1 person found this answer helpful.
Bradleeeey 46 Reputation points

2021-12-13T14:24:09.343+00:00

Hi AndyDavid,

Our FQDN connector is currently set to remote.ourhostname.com.

The instructions on spamhero tell us to set all of our MX records to there four spam hero addresses without our own listed in there.

Im not sure that i follow what we need to do in regards to PTR records in that case...... do we need each spamhero hostname pointing to remote.ourhostname.com?

If not what should our FQDN be? would it just be ourhostname.com?

Do i need to remove other PTR's or will they not cause issue?

Thanks in advance!

Andy David - MVP 142.2K Reputation points MVP

2021-12-13T14:33:55.68+00:00

Does outbound mail go through spam hero?

Bradleeeey 46 Reputation points

2021-12-13T14:38:51.313+00:00

No only inbound. As far as i know also remote.ourhostname.com is only used for the FQDN.

Andy David - MVP 142.2K Reputation points MVP

2021-12-13T14:43:11.587+00:00

Then all you need is a PTR DNS record for each sending server. Each one is unique IP> FQDN of the sending server.

Bradleeeey 46 Reputation points

2021-12-13T14:48:00.567+00:00

I just spoke to spam hero and they said a PTR is in place for remote.ourhostname.com for each of there servers. He said there is not PTR set up with them for ourhostname.com however. Could that be the issue? or does it not matter because we dont send with them?

Bradleeeey 46 Reputation points

2021-12-13T14:50:58.367+00:00

i should add we email from user@ourhostname.com and not user@ㅤ .ourhostname.com
Sign in to comment
Bradleeeey 46 Reputation points

2021-12-22T11:51:35.967+00:00

Hi everyone,

As an update it seems the PTR record finally took.... when i do an nslookup on remote.ourhostname we get an ip and when that ip has an nslookup performed on it we get back remote.ourhostname.com.

Now the only issue we are having is that ourhostname.com cannot connect when running an SMTP check on mx toolbox and we have had customers unable to email us at all briefly yesterday?! they all seem to be able to email again now which is odd.... guess that was the record updating?

Do i need to be worried about ourhostname.com failing the mxtoolbox smtp check?

Thanks for previous help.... looks like im getting there.
Please sign in to rate this answer.

1 person found this answer helpful.
Joyce Shen - MSFT 16,646 Reputation points

2021-12-27T06:58:49.387+00:00

Hi @Bradleeeey

Thanks for feeding back the information above, since mxtoolbox is just an inspection tool, and your mailflow can work properly now, we can continue to observe for a while. If there is no other issue, we could ignore the failing result.

And you could take a look at which of the above replies is more helpful to you, then click "Accept Answer" and upvote it. Your action will make answer searching in the forum easier and be beneficial to other community members as well. Thanks for your understanding!

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Sign in to comment