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

Emails (through Exchange) to certain domains getting blocked as spam #5.5.0 smtp;554 Transaction Failed. Spam Message not queued.>

I have a client who goes through this every couple of weeks.  Certain domains will get email bounced back as spam.  Here's a copy of the bounce message:

From: System Administrator
Sent: Tuesday, June 24, 2008 11:04 AM
To: Brian
Subject: Undeliverable: Latest Requirements Doc
Your message did not reach some or all of the intended recipients.
      Subject:  Latest Requirements Doc
      Sent:     6/24/2008 11:04 AM
The following recipient(s) cannot be reached:
      lastname, firstname on 6/24/2008 11:04 AM
            There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator.
            <branch.domainname.com #5.5.0 smtp;554 Transaction Failed. Spam Message not queued.>

I had a problem in the past with my PTR record pointing to the ISP instead of the actual exchange server...but when I fixed it, I added a PTR to two places...just in case.  

Reverse MX A records (PTR) Your reverse (PTR) record:
xxx.xxx.xxx.xxx.in-addr.arpa ->  branch.domainname.com
xxx.xxx.xxx.xxx.in-addr.arpa ->  domainname.com

the DNS pointer to the exchange server goes to what I am calling branch.domainname.com (for security reasons...not using actual domain names or ip's)
but their email addresses are username@domainname.com

HERE'S MY QUESTION:

A. Is the PTR record supposed to point to the domain name or the DNS pointer that the email is coming from?
B. Could this be causing the above error code when emailing certain domains?

Thanks in advance...please skip the guesswork and only answer if you know!
0
authen-tech
Asked:
authen-tech
  • 4
  • 4
  • 4
3 Solutions
 
grbladesCommented:
You should only have a single PTR record for the IP address.
The PTR record will have to be assigned against the external IP address of the mail server and therefore will have to be done by the ISP who provides your service or through a web interface that they provide.
The reverse DNS should point to the same hostname that the mail server advertises in the HELO/EHLO command.
0
 
HallidaysCommented:
We have had the same problem only ours was to do with Reverse DNS Authentication checks and it was actually the .in-addr.arpa at the end of the PTR causing the problem, we had this removed and everthing was ok.

Your PTR should point to the server that the mail is sent from ie

server.internaldom.externaldom.com/co.uk etc

And yes - Not having it setup correct can cause your problems.

0
 
HallidaysCommented:
Put your mailserver IP (external) in the "IP INFORMATION" box on the left hand side

http://www.dnsstuff.com/

You should get

IP address:                    xxx.xxx.xxx.xxx
Reverse DNS:                    server.internaldom.externaldom.co.uk.
Reverse DNS authenticity:       [Verified]

0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
HallidaysCommented:
It is the authenticity that is the major here, if you are not verified some domain will not accept email - its a right pain.
0
 
authen-techAuthor Commented:
Ok, I contacted the ISP and asked them to remove the PTR to the main domain.com name.  That should leave only the internal.domain.com which is also the HELO and DNS pointer to the mail server.  

Hopefully that will fix it!  Thanks for your help and I will let you know and award points after it checks out.
0
 
authen-techAuthor Commented:
Same problem exists.  I had the ptr record that pointed to domain.com removed and I am still having the same problem.  Does that mean that I was advised to remove the wrong one or is it caused by something else?

To: Brian
Subject: Undeliverable: Latest Requirements Doc
Your message did not reach some or all of the intended recipients.
      Subject:  Latest Requirements Doc
      Sent:     6/24/2008 11:04 AM
The following recipient(s) cannot be reached:
      lastname, firstname on 6/24/2008 11:04 AM
            There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator.
            <branch.domainname.com #5.5.0 smtp;554 Transaction Failed. Spam Message not queued.>
0
 
grbladesCommented:
There are many reasony why a mail could be classed as spam.

In my profile there is a test@ email address listed. If you want to send a test email there and post here as soon as it is sent I will post the headers and let you know my spam filters findings.
0
 
grbladesCommented:
Your email was perfectly fine. DNS and reverse DNS was all correct and spamassassin didnt find any problems with the content.

You could implement SPF (http://www.openspf.org) and register yourself with DNSWL (http://www.dnswl.org) which will help.
0
 
HallidaysCommented:
Did you try what i posted above on DNS stuff to check if authentication is working?
0
 
grbladesCommented:
I did that when I saw the IP address of the server in the headers of the email. It did come back as verified.
0
 
authen-techAuthor Commented:
Yes I did do that and it even came back as verified when it was wrong... ??

I am going to contact the domain that is blocking us (the main one that we test against) and see if they can shine any light on the subject.  I appreciate all your help guys.  Thanks for checking on that grblades.  I will let you know if I find anything...
0
 
authen-techAuthor Commented:
Ok, the PTR records are now correct and that was a biggie.  I found that the domain in question WAS spamming and was on a black list found at trustedsource.org as well as another one.  I appreciate all the help as I am confident my setup is correct and not causing any issues.  Thanks again!
0
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: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

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