Relaying denied. IP name possibly forged.(xx.xx.xx.xx)> for some users when sending emails.

A couple of users are having problems sending e-mail to recipients she sends to every day. The error is: on 11/26/2005 1:11 PM. You do not have permission to send to this recipient. For assistance, contact your system administrator. ... Relaying denied. IP name possibly forged.(xx.xx.xx.xx)>.,289625,sid43_gci1155538,00.html

According to this post and with it could be related to:

It sounds like the recipient's SMTP server is doing a reverse lookup on your domain and failing. You should double-check your public DNS record to make sure that the server's PTR (pointer) record has the servername mapped to the server's correct IP address.

This is our current Exchange setup:

1.) We run an active-passive cluster of Exchange 2003

2.) The MX records are being hosted in Postini (Google)

3.) We are running a load balancing solution for redundancy between 2 ISP providers. So A and PTR records for have an entry for each the providers in the public DNS.

For example:

ISP1 - -

ISP2 - -

We are now using provider one so if any emails are being send they headers of the email show the for

However if I run a DNS query for A/PTR resolution for the IP is the one that resolves.

So email is being send like external DNS resolution to replies on

Like I said a couple of users are getting this type of message: on 11/26/2005 1:11 PM. You do not have permission to send to this recipient. For assistance, contact your system administrator. ... Relaying denied. IP name possibly forged.(xx.xx.xx.xx)>.

Could this setup be the problem since we are sending at but the world resolves at

Also the FQDN for the cluster is mail.domain.local does the entry need to be changed to If we have to change it why should be make the change?

Thank you.
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Alan HardistyConnect With a Mentor Co-OwnerCommented:
If you read the section in my article posted in your other question ( that states:
"If you do send out mail from a different IP address to the advertised MX record IP Address, please check that the Reverse DNS entry for this IP Address is also configured properly and that it resolves correctly to the same IP address (we use to check this - but you will need a subscription!).  As an example, if you send mail out via IP and the Reverse DNS entry setup on this IP address by your ISP is, should also resolve in DNS back to the same IP Address."
Your configuration does not follow this setup as your rDNS pointer points to and resolves back to a different IP Address.
If you don't change this, or setup your DNS properly, you will continue to have problems.
So, either:
  1. Change your rDNS pointer on your sending IP address to something currently setup in DNS that points back to your sending IP address
  2. Add a DNS A record for your sending IP Address, add a CNAME record that points to your A record that you just setup and then change your sending IP rDNS record to match the CNAME you just created
  3. Change your MX records to point mail directly to your server using as the MX record and install some good anti-spam software such as Vamsoft ORF ( for $239 per server to cope with the spam you will get.
One of the above options should solve your problem - you just need to pick the best / easiest option for your company.
Rick HobbsRETIREDCommented:
Definitely.  That is the definition of relaying.  Receiving on one address and forwarding on another address.  Either get the sites you are having problems with to allow it or change your configuration.
What is your mailserver announcing itself as? mail.domain.local?

Make sure its announcing itself as i.e the domain of your emails so whatever is after @

You can verify this by going to:

Exchange System Manager - Server - Protocols - SMTP - Right click on Default SMTP Virtual Server and go to Properties. Choose the last tab Delivery and Advanced What is the FQDN set as?

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

llaravaAuthor Commented:
It was changed to be However what do you think about the PTR/DNS resolution of Is that a problem? If it is could you please explain or point me out to an article that explains  why?

Alan HardistyCo-OwnerCommented:
Your question is answered by my comments above.
Sorry did not realise Expert AlanHardisty was already assisting his answer is correct your DNS records must match as per his post.

Alan HardistyCo-OwnerCommented:
: )
llaravaAuthor Commented:

Thanks for such a detailed anwser. When you were answering my question I was replying to what Raheem05 posted. Your reply is what I was looking for.
llaravaAuthor Commented:

I will not be able to work on this today but I have a couple of question that I would to anwser before I go ahead and close the question.

Alan HardistyCo-OwnerCommented:
Ah - sorry - feel free to ask away.
All Courses

From novice to tech pro — start learning today.