Announcement

Collapse
No announcement yet.

rDNS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • rDNS

    Hi all

    I am aware of how rDNS works, I think:

    A Record - mail.example.com points to 1.2.3.4
    MX record - mail.example.com
    rDNS Record: 1.2.3.4 points to mail.example.com

    How should I do this if a company is using an external mail filter though?

    Example.com's public IP = 1.2.3.4
    External Mail Filtering Service IP = 5.6.7.8

    A Record - mail.example.com points to 5.6.7.8
    MX Record - mail.example.com
    rDNS Record - ???

    Using my ISP's DNS Control Panel it physically cannot set the rDNS value to 1.2.3.4 becuase the A record is pointing to 5.6.7.8. They (ISP Support) are saying its not possible to have an rDNS record in this case, which I call BS becuase there must be loads of companies doing this and having perfectly RFC compliant DNS records.

    What do you all think?

    Rgds

    H

  • #2
    Re: rDNS

    Would setting a backup MX record up (and appropriate A Record) and setting the rDNS to that work?

    Like:

    MX

    Pref 5 mail.example.com
    Pref 10 mail2.example.com

    A Records
    mail.example.com 5.6.7.8
    mail2.example.com 1.2.3.4

    rDNS
    1.2.3.4 mail2.example.com

    Comment


    • #3
      Re: rDNS

      If the A record points to 5.6.7.8 then that's what the PTR record should point to. So unless I'm missing something, everything is as it should be and you shouldn't do anything.

      Comment


      • #4
        Re: rDNS

        Wait, doesnt the rDNS record have to resolve to a hostname on the (sending) mail server's domain??

        Comment


        • #5
          Re: rDNS

          No, it has to resolve to the A record that the MX record is pointing to. You said that the email is filtered at an external server, and that the MX record points to mail.example.com and that mail.example.com points to 5.6.7.8, so in the 5.6.7.8 reverse DNS zone you need to have a record for mail.example.com.

          Why would you create a PTR record in 1.2.3.4 for mail.example.com when the MX and A records points to 5.6.7.8?

          Does email go out from 5.6.7.8?

          Comment


          • #6
            Re: rDNS

            No, mail is sent directly from 1.2.3.4

            So in fact, I need to contact the company who hosts this external spam filter server, and get them to add a reverse record in on their ISP...

            Thank you, makes sense now.

            Comment


            • #7
              Re: rDNS

              Well now that doesn't seem good to me. Incoming mail goes to 5.6.7.8 because the MX record points to mail.example.com, which points to 5.6.7.8 but outgoing mail comes from 1.2.3.4 which does not resolve to mail.example.com so you might have problems sending email to domains that do rDNS or SPF look ups to validate the sender.

              Comment


              • #8
                Re: rDNS

                Originally posted by joeqwerty View Post
                Well now that doesn't seem good to me. Incoming mail goes to 5.6.7.8 because the MX record points to mail.example.com, which points to 5.6.7.8 but outgoing mail comes from 1.2.3.4 which does not resolve to mail.example.com so you might have problems sending email to domains that do rDNS or SPF look ups to validate the sender.
                I'm so confused!

                But yes, what you said is exactly what I am having issues with now. Some clients have started doing proper rDNS lookups (not just the type where it accepts any reverse resolution).

                But, there must be other companies that use hosted antispam/virus solutions, that have proper RFC compliant DNS records.

                If it was all in house I'd have no problem but it's not I have a few clients using external mail services like this, and I want to get "proper" records in place before it starts affecting them too.

                Comment


                • #9
                  Re: rDNS

                  Maybe you could talk to the people at the filtering service and see what they suggest. I'm sure they've dealt with this seeing as they host incoming email for other customers. could it be that they offer an outbound relay service and you need to configure your Exchange server to use them as a smart host?

                  Comment


                  • #10
                    Re: rDNS

                    I have already, they arent sure either, haha.

                    They arent a real hosting company. They basically shelled out for a spam appliance and licensed it to allow mail relaying for other domains, and are offering it as a value-add service to a handful of companies that they have dealings with.

                    I know McAfee to a hosted solution, maybe I'll see if I can get one of their tech's to tell me

                    Comment


                    • #11
                      Re: rDNS

                      Well then they probably have other customers having problems sending outboubd email.

                      When you send an email it's going to come from: someserver.yourdomain.com at ip address 1.2.3.4 but the receiving server will do a rDNS and SPF lookup and see that server.yourdomain.com is not listed as the MX, has no rDSN or SPF record and block the email. This won't happen for every email because not everyone checks but it's definitely not the way you want things to be.

                      If the email filtering company can't offer you any insight or asistance my recommendation would be to stop using them. Find another company or do it yourself.

                      Comment


                      • #12
                        Re: rDNS

                        As far as I know 3 of their maybe 8 customers using the spam filter are now managed by me, and only now are we starting to see problems with rDNS on a couple random email domains that have started checking.

                        Sad thing is, its offered at a very cheap rate, and people are reluctant to pay more for a service they have taken for granted as cheap.

                        So my job is to now try and find out how this is done (I'm certain there is a way) even if it means spending my own time doing it.

                        Thank you, for all the input.

                        Comment


                        • #13
                          Re: rDNS

                          WELL

                          Here is what McAfee Knowledge base says!

                          Code:
                          Problem 1
                          Receiving bounces because of reverse DNS failure.
                          Problem 2
                          Why do some receiving mail servers bounce messages based on a reverse DNS lookup and how can this be stopped?
                          Solution
                          Most Reverse DNS lookups simply look to see if the IP of the sending server has a PTR record which assigns a name to the IP. All Secure Messaging Service servers have PTR records, so reverse DNS lookups should not cause any delivery problems.
                          
                          Additional Information:
                          No receiving mail server should compare any part of an email to the MX records for the sending domain.  MX records are used to designate a location for inbound mail delivery.  They do not mandate that the server which receives inbound mail is the same server which sends outbound mail for the same domain.
                          
                          McAfee does not publish MX records for its data center servers which handle outbound mail flow because no inbound mail is processed by them.  In addition, it would not be feasible for MX records to be published for the outbound servers due to the fact that Secure Messaging Service handles outbound mail for many different domains, not just a single domain.
                          
                          If a receiving mail server only accepts inbound mail from servers that have MX records, they will not be able to accept mail from a significant number of senders because of the increasing prominence of third-party mail processing services.  Enforcing this type of requirement should be carefully considered by the postmaster of the receiving domain.
                          I think they are bascially saying that having a PTR record (of any domain) is enough, and that if incoming mail servers are that stringent that incoming mail MUST resolve to the same server/domain as their MX then they should reconsider their policies...

                          Huh.

                          Comment


                          • #14
                            Re: rDNS

                            OK, this makes sense to me and clears up my misunderstanding of rDNS lookups.

                            The receiving server will check to see if the hostname of the server that's connecting to it has a rDNS entry and may also check to see if the server is authorized via the SPF record to send email for that domain. Neither check is required and some email servers may perform none, one, or both of these checks.

                            It seems to me that what you need to do is to make sure your servers public FQDN (A record) is something other than mail.example.com (since that would create problems for inbound email since mail.example.com is at 5.6.7.. Then create a rDNS record for this FQDN in the 1.2.3.in-addr.arpa reverse zone and also create an SPF record for your domains. That way you have all of the bases covered.

                            Comment


                            • #15
                              Re: rDNS

                              I will try this and ask them to test troublesome email domains over the course of the start of next week, see how it goes!

                              Thank you joe

                              Comment

                              Working...
                              X