NAT rule best practice for a mail server?

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L4 Transporter

NAT rule best practice for a mail server?

Hello folks,

 

We changed our public ips recently and we have a few recipeints that are blocking our new mail IP.  I am suspecting has something to do with either our TXT (SPF) record or the fact that we are using a destination NAT rule instead of bi-directional.

 

I've included a diagram and notes below, but trying to get some feedback on what the problem might be and if there is a general best practice based on experience.

 

In general: I am thinking that we should make our NAT rule bi-directional so that it's source IP when initating to internet from mail server is the assigned IP rather than the general NAT IP/Port to the firewall interface.  

 

Any comments or feedback?

 

mail3.jpg

 

mail2.jpg

 

mail.jpg

Using nslookup MX record return correctly as assigned IP: 96.68.102.139.

Also trying to get feedback from technet.

https://social.technet.microsoft.com/Forums/office/en-US/2e3def39-3f37-4883-a21a-182fc57dfa6f/exchan...

 


Accepted Solutions
Highlighted
L7 Applicator

Set up your SNAT and DNAT rules so that incoming and outgoing email would go out from same public IP.

Or set up SNAT as bi-directional.

 

Neither of those IPs you mentioned resolve to anything reasonable.

You have to ask your ISP to update reverse DNS record for the IP where emails are going out from.

Reverse DNS has to resolve to email domain.

 

C:\>ping -a 96.68.102.139

Pinging 96-68-102-139-static.hfc.comcastbusiness.net [96.68.102.139] with 32 bytes of data:

 

C:\>ping -a 96.68.102.140

Pinging 96-68-102-140-static.hfc.comcastbusiness.net [96.68.102.140] with 32 bytes of data:

 

 

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI

View solution in original post


All Replies
Highlighted
Cyber Elite

@OMatlock,

While I would generally run SMTP servers with a bi-directional, this is far from a requirement. It really looks like you got assigned a bad IP. Go through Office's IP Delist process and get your IP removed from the Anti-Spam list; I bet when it gets removed you'll find everything works fine. 

Highlighted
L7 Applicator

Many spam filters do reverse dns lookup and if IP does not resolve back to correct domain then they flag email as spam.

Ask ISP to update reverse dns information.

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Highlighted
L2 Linker

Bi-directional NAT would be simpler. Your HELO should match DNS in both directions, in additional be listed in your SPF record. It is also possible that your IP is blacklisted.

Highlighted
L4 Transporter

Thanks for the feedback.

Yea, in our Exchange server there is a message:

"Client host rejected: cannot find your reverse hostanme [96.68.102.140]"

 

The Client here is one of our customers that is rejected our email.  The IP shown above is the outbound source IP based on our general internet access IP and port address, not the mail assigned IP of .139.

 

Does it still sound like just an ISP/DNS update problem?

 

I am trying to determine if our firewall rule needs to change, TXT record, or other.

 

 

Highlighted
L7 Applicator

Set up your SNAT and DNAT rules so that incoming and outgoing email would go out from same public IP.

Or set up SNAT as bi-directional.

 

Neither of those IPs you mentioned resolve to anything reasonable.

You have to ask your ISP to update reverse DNS record for the IP where emails are going out from.

Reverse DNS has to resolve to email domain.

 

C:\>ping -a 96.68.102.139

Pinging 96-68-102-139-static.hfc.comcastbusiness.net [96.68.102.139] with 32 bytes of data:

 

C:\>ping -a 96.68.102.140

Pinging 96-68-102-140-static.hfc.comcastbusiness.net [96.68.102.140] with 32 bytes of data:

 

 

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI

View solution in original post

Highlighted
L4 Transporter

Thank you for that @Raido

I should have mentioned that I am using example IPs so not to disclose our real ones.

Sorry about that...

 

Thanks again, I will follow up with your suggestions.

Highlighted
L4 Transporter

@Raido

@khsieh

@BPry

 

Y'all were right.  Needed to create new PTR records with new ISP.  Once I did that, our TXT (SFP) is passing.

I also did change our Mail server NAT rule to bi-directional.

 

I learn so much for you all, thank you!!!

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!