PTR RDNS Question/Error

Discussion in 'Windows Small Business Server' started by Richard K, Jun 21, 2009.

  1. Richard K

    Richard K Guest

    I am trying to set up a reverse dns pointer record for a domain and I think
    I have it done right but obviously it's not. Here is what I have from an
    NSLookup and the RDNS failure in the message header. What am I doing wrong


    -Richard K

    Static IP: (external IP address of the SBS 2003 R2 Prem server)

    From the receiving end I look at the .txt record and get...

    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\Documents and Settings\rkokoski>NSLOOKUP
    *** Can't find server name for address Non-existent domain
    *** Default servers are not available
    Default Server: UnKnown
    Server: UnKnown

    Non-authoritative answer: text =

    "v=spf1 mx ip4: ~all"
    But from the message header when the message arrives I get...

    Microsoft Mail Internet Headers Version 2.0
    Received: from ([] RDNS failed) by with Microsoft SMTPSVC(6.0.3790.3959);
    Sun, 21 Jun 2009 13:17:00 -0400
    Content-class: urn:content-classes:message
    MIME-Version: 1.0
    Richard K, Jun 21, 2009
    1. Advertisements

  2. Hi Richard:

    If you are trying to modify the *public* DNS records, you do that, or rather
    your ISP does that, at the ISP, not on your server.

    SBS does everything you need with the connect to the internet wizard.

    I looked at the public DNS for which appear to be fine.

    So what is it that you find is broken?

    Larry Struckmeyer
    Get your SBS Health Check

    Larry Struckmeyer [SBS MVP], Jun 21, 2009
    1. Advertisements

  3. Richard K

    Gregg Hill Guest

    Your MX record and mail server IP do not match your PTR record. Your PTR is
    for and not your actual mail server of


    OK. The IPs of all of your mail server(s) have reverse DNS (PTR) entries.
    RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It
    is strongly urged that you have them, as many mailservers will not accept
    mail from mailservers with no reverse DNS entry. Note that this information
    is cached, so if you changed it recently, it will not be reflected here (see
    the 'Reverse DNS Tool' for the current data). The reverse DNS entries are: [TTL=27853]

    Your MX record is for "" but your PTR is for
    "" and the IPs for those two domain names are different.

    Have your ISP set up a PTR for "" pointing to

    Also, fix your mail server greeting to reflect the FQDN of See below.

    WARNING: One or more of your mailservers is claiming to be a host other than
    what it really is (the SMTP greeting should be a 3-digit code, followed by a
    space or a dash, then the host name). If your mailserver sends out E-mail
    using this domain in its EHLO or HELO, your E-mail might get blocked by
    anti-spam software. This is also a technical violation of RFC821 4.3 (and
    RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should
    have an A record pointing back to the same server. Note that this one test
    may use a cached DNS record. claims to be host [but that
    host is at (may be cached), not]. <br />

    Gregg Hill

    Gregg Hill, Jun 21, 2009
  4. Okay, you seem to be mixing up your terminology for one. A PTR record is
    *NOT* a TXT record for one.

    Secondly, you can set up a PTR record for your IP on your box all day, but
    if the lookup server doesn't know to look at your box then it'll never get
    looked at. Why wouldn't a server look at your box? Probably because
    delegation for your public IP belongs to your ISP and not you. Two choices
    to resolve this: Call them and have *them* make a PTR record for you. Note
    that it just has to exist, it does NOT need to match your server's name. 2)
    Have them delegate your IP to you (it's a glue record that they still have
    to create) but once the delegation record is in place, further PTR requests
    for your IP will go to your server. NOT recommended BTW. Only increases
    traffic on your link. I recommend the first.

    Finally, the txt record you posted appears to be a valid SPF record. But,
    as stated above, SPF and PTR are *very* different things. You can make SPF
    records all day long and they won't resolve a failing RDNS issue. You need
    to have your ISP create a PTR record (*NOT* an SPF/TXT record.)


    Cliff Galiher, Jun 22, 2009
  5. Richard K

    Richard K Guest

    OK I may not have explained things in enough detail so let me add to my

    1. The DNS changes I am trying to make are at the public DNS (Total DNS for located at GoDaddy). I am not trying to make any DNS
    changes on the SBS itself.
    2. Since I control the DNS for via the Total DNS at
    GoDaddy I should be able to do it myself. Am I correct?
    2. After reading what's been posted I made another change to the DNS at
    GoDaddy and included the ptr. In GoDaddy's Total DNS settings you are
    actually creating a TXT record.
    3. I have updated the record to now read "v=spf1 mx ptr ~all". Will this work for me now?



    Richard K, Jun 22, 2009
  6. Hi Richard,

    There are two types of zones in DNS - Forward Lookup Zone, and Reverse
    Lookup Zone.

    The forward lookup zone is what you have control of. For example, if you
    have your website at a hosting company, such as GoDaddy, they will
    automatically create a 'www' record, so you can get to it using , and a blank domain record, so you can get to the
    website using without the 'www.' GoDaddy allows you
    to change this, if you want.

    If you decide to move the website to a different location, but decide to
    keep your domain name's host nameservers at GoDaddy, you can actually change
    the above two records, if you like. You can also add records, such as mail
    records, MX records, etc. Normally as part of the package, they give you
    mailboxes, etc, and create these records for you.

    As for the Reverse Lookup Zone, that depends on the ISP or the hosting
    company, depending on where the resource is located.

    From what I see, and what was already commented about by the other responses
    in the thread (Cliff, Larry, Gregg and Russ), a PTR is not a TXT record. A
    PTR is a pointer record that points an IP address to a hostname FQDN.

    Therefore, from what I found with nslookups, your domain
    name points to, and the 'www' record is an alias that points
    to, which of course is

    You can also create other types of records, such as TXT records. Keep in
    mind, the TXT record is simply a text record that you've chosen to use as an
    SPF record, as you've already created, for an SPF record for your domain,
    which looks like you did fine with it. But one thing I must say in your SPF
    record, you've identified the PTR in the record as, but the record when I looked it up, as I've
    already stated, is

    I then looked up your MX record. That happens to be, which actually is

    However, when I did a reverse lookup for, it pointed to, and not, which it should be.

    The IP address,, apparently belongs to your ISP, and not
    GoDaddy. This is all assuming of course, that your SBS is hosting your email
    for your company. Apparently at one time you must have spoke to your ISP to
    create a PTR for to point to, and not

    This will fail on receiving mail systems that check the SPF and look for a
    match. Since your SPF record is, and not, it will fail.

    My suggestion is, and what was already suggested by the others, is to speak
    to your ISP that owns the IP address, to change the PTR to, so it mathes your mail MX record in order to
    satisfy mail systems that check for reverse entries, or the RDNS value as
    one of the things that are checked for to eliminate spam on their end.

    Since GoDaddy doesn't own that IP address, you can't change it on their end.

    I hope that makes sense!


    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Please reply back to the newsgroup/forum to benefit from collaboration among
    responding engineers, as well as to help others benefit from your

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
    Microsoft Certified Trainer

    For urgent issues, you may want to contact Microsoft PSS directly. Please
    check for regional support phone numbers.
    Ace Fekay [Microsoft Certified Trainer], Jun 22, 2009
  7. Richard K

    Gregg Hill Guest


    Your SPF record is COMPLETELY screwed up now!

    Because you have only one MX record pointing to an A record with
    as the IP address, your SPF record could simply be:

    v=spf1 mx ~all

    or, if you want a hard-fail SPF:

    v=spf1 mx -all

    Do NOT use the PTR mechanism in your SPF. Because your single MX record and
    the corresponding IP address are interchangeable, there is no need to
    include both in the SPF record. As far as DNS lookups are concerned, it
    would be "faster" to have only the "ip4:" argument instead of the
    "mx" argument, ***BUT because it is easier to maintain*** if your change
    your mail server's IP later, I recommend either of my examples above with
    just the "mx" argument. In fact, I see no reason to have an SPF record if
    you are not going to make it a hard-fail SPF, but that is just my personal

    Fix your SPF now, then do as first suggested and have your ISP change your
    PTR to match your FQDN of at

    Gregg Hill

    Gregg Hill, Jun 22, 2009
  8. Richard K

    Gregg Hill Guest


    Just to make sure you understand, FQDN = Fully Qualified Domain Name,
    meaning a prefix.domainname.tld format. Your PTR only points to
    domainname.tld, so it does not match the **FQDN** of your mail server,

    For SPF syntax and testing, look at

    I vote for

    v=spf1 mx ~all

    or, if you want a hard-fail SPF:

    v=spf1 mx -all

    as your SPF record because if mail server IP addresses change later, you
    don't need to touch the SPF record. Just make sure the MX and its A record
    are in your public DNS.

    Gregg Hill

    Gregg Hill, Jun 22, 2009
  9. Richard K

    Joe Guest

    What Works For Me (tm):

    -My IP address has a PTR record at my ISP which resolves to a hostname
    which has a public DNS A record which resolves back to the IP address.

    -My mail server HELO/EHLO also exists as a public DNS A record.

    There appears to be no general requirement for the PTR hostname to be
    connected with either the HELO or any domain name used for sending mail.
    I send mail 'from' multiple domains, and while the PTR specification
    allows for multiple PTR records for one IP address, this does not seem
    to be common practice. I never send 'from' the domain on which my PTR is
    based, and I can't be bothered configuring my mail server to vary the
    HELO according to the sending domain. I'm not aware of any server that
    rejects my mail, and I regularly send to an AOL address. I have no SPF

    The default configuration of my own mail server (Exim) looks for the two
    points I mention above on incoming SMTP connections. I've never seen any
    reason to alter that, as the vast majority of bogus connections are
    rejected by those two rules, which is the bottom line to all this
    apparent fussiness.
    Joe, Jun 22, 2009
  10. Richard K

    Leythos Guest

    You are confused:

    Reverse DNS entries, these are what the ISP puts on their IP so that a
    public reverse DNS lookup of the IP shows something - this should match
    your domain name or your mail server.domain name....

    If your public Reverse DNS entry doesn't match your domain name, or if
    you don't at least have something in there, there is a good chance your
    email (sent from your server) will be detected/marked as spam.

    The ISP that provides your IP addresses controls your RDNS, you have no
    control over it, period.

    The TEXT record you are creating is not a PTR record, it's a SPF record
    and it's suppose to be TEXT, SPF are not accepted/used by all system, so
    they are only partly a solution.

    The Public DNS that you control is everything except your RDNS entry,
    that is controlled by your IP Provider.
    Leythos, Jun 22, 2009
  11. Eh. Others have all said it, but there were a lot of tangents as well. So
    if you didn't gleam what you needed from the other posts, let me just reply
    to your questions inline:


    Good. That covers any SPF/TXT records.
    NO. You can control A, CNAME, TXT records and such. PTR records are a
    different beast. Google "reverse lookup zone." THAT zone is still very
    likely controlled by your ISP.
    Again NO NO NO. A PTR is *never* a TXT record. An SPF record can be a TXT
    record, but not a PTR. You are creating SPF records, not PTR records.
    Since your posted failure is an RDNS/PTR issue, nothing you do in GoDaddy's
    system will address the core problem YOU are having.
    Nope. Now you've really messed up your SPF record and will likely have more
    problems. My suggestion? Delete the SPF/TXT record for now. Fix your PTR
    issues with the help of you ISP. Then, once you are no longer having
    rejections, you can create SPF records to help with spam.
    Cliff Galiher, Jun 22, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.