Sendig Mail to user@IP

60 pts.
Digital certificates
E-mail applications
Identity & Access Management
Incident response
Intrusion management
Linux Distributions
Microsoft Exchange
Network security
Network testing
Networking services
Performance management
Protocol analysis
Red Hat
Red Hat Enterprise Server
Security tokens
Single sign-on
We have two Mx Record (same ISP) pointing to the same mail server. The Mail Server is REDHAT Linux. I want to send a mail to user@ip address (first or second Mx Record). This is basically to test if first Mx record fails, will the second record be used. I would be sending this mail from the LAN to a valid user of the LAN but at user@IP address (as above). What risk would I be taking ? How do I do this. I think this rule would be an exception. How to do this ? Thanks in advance

Answer Wiki

Thanks. We'll let you know when a new response is added.

As best as I can tell, you can’t send mail to a user@ip address (I’ve tried it) — the mail daemon does not resolve the host that way. Now, you might consider pointing your SMTP to set the server referred to in your MX record to be your upstream host, but beyond that, I don’t think you can do it.

Good luck & let me know if you get it to work, please.

Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Dfng2002
    The majority of the time your Mx records are accurate, if you have any doubt ask your provider, as all your records are held with them. The can also do tests for you, but as far as sending mail by IP address I have never heard of it being done. Have your provider do the NSlookup on it.
    15 pointsBadges:
  • Petroleumman
    Hello, Correct me if I'm wrong, but is your intention of having two MX records in DNS a way to build redundancy? If so, your going about it in the wrong way. MX records really don't fail on there own, it would be DNS or more likely, the server which hosts DNS that would be the point of failure. So having two identical MX records residing on one DNS server gives zero advantage. If redundancy is what your after place copies of your DNS zone on multiple servers i.e. Primary and Secondary DNS servers. If DNS is hosted, check with your ISP to get the addresses of the primary and secondary DNS servers supporting your zone. The only time you would require two seperate MX records pointing to one server in DNS is if your mail server hosts multiple mail domains or you use alias's for your server. As for sending mail to user@IP_Address, this will not work. SMTP will only recognize mail in this format Good Luck!
    0 pointsBadges:
  • Bobkberg
    All the previous posters are correct, but I'd like to stress a couple of things... 1) The purpose of multiple MX records is to allow for failover in case of mail server failure or non-availability - typically, the hosting ISP will allow email to be stored on one of their servers until yours is back up. 2) It's typical also, for multiple name servers to have copies of your zone (as authorized) cached, and copied of key records (like MX) as requested - for the expiry period so that if the primary name server is down the information is available to keep conducting business. Frankly, I don't see how the scenario, as you described it, offers anything useful even viewed as a test scenario. If you feel unclear on the functioning of DNS, get and read the O'Reilly book on DNS and BIND by Cricket Liu and Paul Albitz. Bob
    1,070 pointsBadges:
  • Sonyfreek
    MX records are pointers to an IP Address capable of receiving email. As everyone else has said, testing with the IP Address would only prove that the server is listening on that address and provides no redundancy if your Mail server fails, DNS fails, or your link to the Internet goes down. You'd be just as well off to telnet to the IP:25 and give it SMTP commands as it would do the same thing. If you want to prevent losing emails in case of a problem with your server or connection, ask your ISP if they provide a cached mail server that will act as a failover in case your real server or link goes down. When your connection to the primary email server comes back up, the email will download from the ISP to your own server. A quick review of the RFC 822 and its successor RFC 2822 leads me to believe that it is supposed to be a valid Internet domain, not an IP Address. However, it's about as fun to read as legalese and my interpretation of a dot-atom and atext may not be correct (yes, it's defined within the RFC, but it's obscure...) I know it works with some servers and clients because I've seen people do it before, but it sounds like something a spammer would do and not a legit user. SF
    0 pointsBadges:
  • Jagdish
    Thanks a ton for all the replies which were really quite informative. I will have to redesign the test and check.
    60 pointsBadges:
  • Amisenin
    A simple view would be like this - When you send mail to then the sender mail server (not your client) would do a DNS lookup for's MX records. If you have linux try 'dig mx' and you will see how it works. If the mail server doesn't get a valid respose then it will return you the mail. If it gets a valid responce then it tries to contact the mail server mentioned with lower MX number first. If it cannot contact then it tries the next server mentioned in the MX records. So it doesn't make sense having 2 MX records pointing to the same machine. Actually the 2 records should be pointing to 2 seperate mail server. So if one is down mail will automatically be delievered to the nest. If you have a linux box try out the following command and see the interesting results. # dig mx
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: