• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 697
  • Last Modified:

Two Domain, One email gateway, MX record/Domain config question

I have two domains,  red.com and blue.com.  Both domain's email is sent to and from a single email gateway on my corporate network.  I have a DNS entry set up for this gateway mail.red.com.  Both domains have an MX record entry pointing to mail.red.com.   Red.com doesn't have any email delivery issues.  Reverse lookup on my email gateway IP address returns mail.red.com.   If you do a forward lookup for red.com and then reverse lookup on that IP you get a XXXX.red.com hostname.  So Red.com should pass all lookup test for email delivery.  If you do a forward lookup for blue.com and then reverse lookup on that IP you get a XXXX.red.com hostname.   This is the basis for my concern about the blue.com MX/Domain configuration.  

Domain - red.com
DNS Hosted with AT&T
mail.red.com = xxx.xxx.xxx.xxx (IP address for my email gateway on the perimeter of my corporate network)
MX = mail.red.com 10

Domain - blue.com
DNS Hosted with iPower
MX = mail.red.com 10

My question is...  because reverse lookup of our email gateway will only resolve as mail.red.com, will this cause issues for blue.com with mail systems that use reverse lookup as a tool to deter spam?

To resolve this issue, I was considering adding another IP to our email gateway and dedicate this IP to blue.com so the reverse lookup would work correctly.   I was curious if any experienced email admins thought this was the best way to handle or if I should leave it like it is.  
3 Solutions
Yes running the blue.com email out of another IP and setting up a new PTR (reverse lookup) for the new ip to be mail.blue.com would work for you. Otherwise for a little fee you can run your email to relay through a third party such as postini, etc.

Shareef Huddle
Reverse IP address name should match the server HELO or EHLO banner. You only need one reverse DNS to the FQDN of the mail server. The server name and hosted domain don't need to match.

If your mail server's hostname is mail.red.com, then your reverse DNS, MX record, HELO/EHLO, and SMTP greeting banner should all be mail.red.com as well. That server, however, could be providing service for blue.com, red.com, and any other domain without any problems.
E-mail servers checking for reverse DNS do recognize that it is normal to host many domains on a single IP address and it would be impossible to list all those domains in reverse DNS for the IP.

You should also publish an SPF record in the DNS for the domain names you use to send mail to identify the IP space you send from.
Normally the reverse lookup of your IP is compared to your MX record and not your domain name. So there need not arise any issues.

If you don't like the reference from red to blue and vice versa, just add another DNS-R entry for the SAME IP, calling it mail.blue.com and point your MX for blue.com there.

mail.blue.com -->
mail.red.com -->

MX for red.com --> mail.red.com
MX for blue.com --> mail.blue.com

In this case you need to handle, how your SMTP-service greets the target mail system in his HELO. It must distinguish it's HELO mail.xxx.com according to the senders IP.

It is not unusal (rather it is most common) to share an IP to many domains - just think of hosting providers relaying mails for thousands of domains with very few IPs.
Many people (my work included) run multiple domains out of a single IP address - this is not an issue, but you do have to setup your DNS correctly.  Take a look here for some answers: http://www.simpledns.com/kb.aspx?kbid=1052

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now