Solved

Continued Problems with People Blocking our Domain after a PTR record Change

Posted on 2011-09-27
28
1,279 Views
Last Modified: 2012-05-12
We changed a PTR record because reverse lookups were failing with a supplier we were trying to contact in China.  (Their mail server required our PTR records were what the HELO/EHLO message on the server was or else the mail was rejected).  Since we've done this we've had a lot of problems with getting emails rejected from other companies (now mostly in the states).

Our internal domain is "domain.lcl" while our email addresses all originate from a "domain-global.com" namespace.  The HELO/EHLO message and the PTR record of the external IP of our outbound mail traffic is set "emailserver.aimco.lcl".

I'm thinking that even though this PTR record was set to some random Comcast info prior to us changing it is there SPAM solutions out there?  For example I found that BigFish (a maker of a rather cheap looking SPAM filtering solution was blocking us as a SPAMer).  

How do others prevent changes to their PTR records from wrecking havok on their email flows?  I've also noticed that my SPF record for our domain isn't setup properly, and that's something I'm working on; but, how many people's email solutions are using SPF record lookups?  Seems redundant to the PTR record, in a way, but better because it doesn't get botched if you change IP addresses.

Any advice people have would be appreciated.
0
Comment
Question by:ChocolateRain
  • 8
  • 8
  • 7
  • +1
28 Comments
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36711953
Can you provide an actual domain name for proper troubleshooting?
0
 
LVL 27

Expert Comment

by:davorin
ID: 36711992
Sorry I would be rather short.

It is good that your SMTP header on your server has the same value that PTR record.
You can check that by entering your domain at www.mxtoolbox.com
0
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36712055
However, if it's not resolving for whatever reason, the fact that they match really doesn't help.

The fully qualified domain name of the machine must match the fqdn in the forward zone file and it's address record must match the fqdn in the inverse zone file and they must be resolvable.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36712224
To further complicate matters our inbound email is tied to MxLogic, an external 'cloud based' SPAM filtering solution.  With our outbound emails we are opting not to send from their servers and they are going out of our own IP's on our firewall.

"The fully qualified domain name of the machine must match the fqdn in the forward zone file and it's address record must match the fqdn in the inverse zone file and they must be resolvable."

@jesper:  Can you clarify that a little bit?  I assume you are meaning our external DNS as opposed to our internal DNS...?  There are multiple ways I can interpret what you are saying so if you could clarify what you mean it would be much appreciated.
0
 
LVL 28

Assisted Solution

by:Jan Springer
Jan Springer earned 166 total points
ID: 36712276
Yes, external.

example:  host.domain.com

.com must be a valid root level domain
domain must be a valid subdomain
host must be a valid host name of a machine and its fqdn (host.domain.com) must be configured as an A record in DNS (forward zone) and as a PTR in DNS (inverse zone).

And further, if the machine is called mail.domain.com, even though host.domain.com and 192.168.1.34 match, if your mail transport agent hostname is not the same as its DNS name, you have a mismatch.
0
 
LVL 27

Expert Comment

by:davorin
ID: 36712320
I just forgot to say that on www.mxtoolbox.com take SMTP test of your server. Among other tests it will check SMTP banner and RDNS records.

BTW:  BigFish is Microsoft's hosted exchange services - actually it is Microsoft...
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36713528
Let me give the full list of details here.  I notice that if I typically do this on the original post people TLDR and ask anyway.  =P

Internal domain is "domain.lcl", meaning the the email server's FQDN is "emailserver.domain.lcl" internally
Email domain namespace is "domain-global.com"
The external DNS for "domain-global.com" MX records are pointing to MxLogic's servers for inbound mail.
Outbound Email leaves our Firewall directly with one of our owned and static IPs.
The PTR record for our outbound email is set to "emailserver.domain.lcl"
The HELO/EHLO for the server that is both sending and receiving mail (SMTP) is "emailserver.domain.lcl".
The SPF file record is showing green (as all is well/good) by running the www.testexchangeconnectivity.com test on outbound mail.

By looking at this information, I have the question if the HELO and PTR and the namespace for the sent mail should all match as they are not currently.  Would that cause a problem?

0
 
LVL 27

Accepted Solution

by:
davorin earned 167 total points
ID: 36713629
I admit your question formulation is a little bit confusing.
Internet mail communication don't care about your internal domain names and don't know what to do with it. In external communication always use your external domain name.

From Ms KB 300171http://support.microsoft.com/kb/300171:

Make sure that your public DNS records that are hosted on your DNS server are correct. On your DNS server, examine the following:
You must have an MX record for your domain that points to a valid Host (A) record. For example, the MX record for source.com points to mail.source.com. mail.source.com is a valid e-mail server.
Make sure that the Host (A) record points to a valid IP Address. For example, make sure that mail.source.com points to 209.54.61.76. This is the correct public IP Address for your e-mail server.
For every SMTP server or Exchange Server computer that sends outgoing Internet e-mail, make sure that there is a valid PTR record for the Public IP address of that sending SMTP server or Exchange Server computer. This may be a firewall, a router, or another device that used to publish your domain information to an IP address that is visible by Internet hosts.

For example, your Exchange Server computer is behind a firewall with an internal IP of 10.10.10.1, and the firewall has an external IP of 4.3.2.1.

When the Exchange Server computer sends e-mail from source.com domain through the firewall, the receiving mail server sees that the 4.3.2.1 IP address is connecting for SMTP Communication. The receiving e-mail server performs a reverse DNS lookup against this IP address, not necessarily the MX record. The e-mail server must find a PTR for 4.3.2.1 pointing to a valid host record in the source.com domain.
0
 
LVL 27

Expert Comment

by:davorin
ID: 36713660
Some of receiving mail servers also checks if HELO record (SMTP banner) matches PTR (RDNS record).
So if you use only one mail server and one internet connection (IP address) for sending mails it is simple to configure both with the same external FQDN.
0
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36713717
Your email server, internal or not, needs to have the fully qualified domain name that is used in dns.

The problem seems to lie with your using an internal domain name on the server in question which conflicts with what it's telling external servers.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36816499
So now the external SMTP banner matches what the PTR record is for the IP of the sending address which also gel with what the domain is of the email address namespace.

Last problem I'm seeming to be having is that my SPF record is still showing some minor problems when I run the Outbound SMTP test on www.testexchangeconnectivity.com.

It's showing the following as a result of this wizard:
 Parsing the SPF record and evaluating mechanisms and modifiers.
  The SPF record was parsed and evaluated successfully.
   Test Steps
   Evaluating A Record lookup mechanism: "+a"
   Additional Details
  The DNS A Record lookup for IP address X.X.X.X found no match for domain DOMAIN-global.com.
 
 Evaluating PTR mechanism: "+ptr:DOMAIN.lcl"
   Additional Details
  The PTR mechanism didn't match.
 
 
 

0
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36816765
It's difficult to say where the problem resides without an actual external host+domain name.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36817174
aimco-global.com
173.8.219.83

This has already slipped out here and there anyway, so whatev.
0
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36817210
173.8.219.83                       =   agcv10k.aimco-global.com.
agcv10k.aimco-global.com.     =   216.182.94.129

This is what external networks see.  This is a mis-match.
0
Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

 
LVL 27

Expert Comment

by:davorin
ID: 36817341
Also for SPF records you must use your public domain name, IP adresses,... not local.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36817442
Ok I changed that.  That was an assumed record, not an explicit one.  It was responding back from the * record rather than any actual record for AGCV10k.

Thanks!  Hopefully this will help things along.
0
 
LVL 21

Assisted Solution

by:Papertrip
Papertrip earned 167 total points
ID: 36900491
[root@broken ~]# dig txt aimco-global.com +short
"v=spf1 a ptr:aimco.lcl ip4:173.8.219.80/20 a:aimco.lcl mx:aimco.lcl -all"

Open in new window

Should be:
"v=spf1 ip4:173.8.219.83 ~all"

Open in new window

or
"v=spf1 ip4:173.8.219.80/20 ~all"

Open in new window

0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36900509
how many people's email solutions are using SPF record lookups?  
A lot of them, especially the big guys.  I highly suggest implementing it properly, along with DKIM signing.
Seems redundant to the PTR record, in a way, but better because it doesn't get botched if you change IP addresses.
SPF says which IP's are allowed to sendmail for a specific domain.  I could setup 1.2.3.4 to have matching A and PTR records of mail.aimco-global.com, but unless 1.2.3.4 is in the SPF record for aimco-global.com, my mails would be rejected.  Checking A / PTR records is separate from SPF checks.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36912054
Now from http://iptools.com I see my PTR record for 173.8.219.83 showing up properly agcv10k.aimco-global.com which is the same as the outbound SMTP header.  But it fails to show that in the www.testexchangeconnectivity.com test for the same IP.  Why would that be the case?  Does that have anything to do with my Receive Connectors?  Why would it?  I can't change both of them to show as agcv10k.aimco-global.com.  I can change the "Client AGCV10k" connector but not the "Default AGCV10k" one.  Is that enough?

Below is the error message (blue exclamation mark) for the results on www.testexchangeconnectivity.com

 The SPF record was parsed and evaluated successfully.
   Test Steps
   Evaluating A Record lookup mechanism: "+a"
   Additional Details
  The DNS A Record lookup for IP address 173.8.219.83 found no match for domain aimco-global.com.
 
 Evaluating PTR mechanism: "+ptr:aimco.lcl"
   Additional Details
  The PTR mechanism didn't match.
 
 Evaluating IP address mechanism: "+ip4:173.8.219.80/20"
  The IP mechanism matched IP and indicated a neutral or positive status.
   Additional Details
  IP address 173.8.219.83 matched entry 173.8.219.80/20 and the result was Pass.
 
 
 
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36912076
Change your SPF record to how I explained above.
0
 
LVL 28

Expert Comment

by:Jan Springer
ID: 36912101
Change your SPF record as suggested above or:

"v=spf1 ip4:173.8.219.80/20 a:agcv10k.aimco-global.com mx:agcv10k.aimco-global.com -all"
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36912116
Jesper's suggestion is syntactically correct, however I'd like to comment on it.

Any mechanisms you use aside from ip4 require another lookup to be made, and is almost always unnecessary/redundant.  The best practice is just list the IP's or CIDR's with the ip4 mechanism.
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36912167
Also by specifying hardfail, any messages from your domain that are forwarded to another destination are going to fail SPF checks 100% of the time.  I gave a quick explanation of hardfail vs. softfail in a recent question at http://www.experts-exchange.com/Networking/Protocols/DNS/Q_27344632.html?cid=1131#a36718660 if you are interested.

Basically it all comes down to how you want your mails to be treated by receiving servers during SPF checks.
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36912227
Here's how most receiving servers do validation in regards to SPF+DKIM.  Not including ADSP in this example for simplicity sake.

If SPF passes, continue to DATA portion
If SPF fails, reject message.
If SPF is neutral or softfail, continue to DATA and check DKIM.  Reject if failed, deliver if passed.
0
 
LVL 1

Author Comment

by:ChocolateRain
ID: 36913546
By changing this:
[root@broken ~]# dig txt aimco-global.com +short
"v=spf1 a ptr:aimco.lcl ip4:173.8.219.80/20 a:aimco.lcl mx:aimco.lcl -all"

To This:
      "v=spf1 ip4:173.8.219.83 ~all"

OR this:

"v=spf1 ip4:173.8.219.80/20 ~all"

I got this (from www.testexchangeconnectivity.com:

Attempting to find the SPF record using a DNS TEXT record query.
       ExRCA wasn't able to find the SPF record.
                   Additional Details
       Text records were found, but ExRCA couldn't find any SPF records.
Records found:
 "spf1 ip4:173.8.219.80/20 ~all"
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36913559
Looks like you added a few extra things to your new SPF record ;)

[root@broken ~]# dig txt aimco-global.com +short
"[root@broken ~]# dig txt aimco-global.com +short   v=spf1 ip4:173.8.219.80/20 ~all"

Open in new window


Don't add my terminal prompt and dig command to your TXT record :p

Just make it "v=spf1 ip4:173.8.219.80/20 ~all"   quotes included.
0
 
LVL 21

Expert Comment

by:Papertrip
ID: 36913594
FYI the TTL on that record appears to be 7200 (2 hours).  I suggest lowering that, a lot, while testing.  Make the TTL 300 if you are able to change that value.
0
 
LVL 1

Author Closing Comment

by:ChocolateRain
ID: 36913907
You guys are awesome.  It worked.  Thanks for all the help.

I've got a clean bill of email server health from www.testexchangeconnetivity.com
0

Featured Post

Want to promote your upcoming event?

Attending an event? Speaking at a conference? Or exhibiting at a tradeshow? Easily inform your contacts by using a promotional banner in your email signature. This will ensure your organization’s most important contacts are in the know.

Join & Write a Comment

Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…
This process describes the steps required to Import and Export data from and to .pst files using Exchange 2010. We can use these steps to export data from a user to a .pst file, import data back to the same or a different user, or even import data t…
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now