SPF record problem

I have a person trying to send mail to us and it is getting bounced back to him. I checked my logs and it looks to me like he is failing on the sender ID. I have Exchange 2007 set to reject on all that dont pass. (This may or may not be the best idea, but we are sick of spoofed mail) Look in code area for what was sent back to him. Below that, I included what my Sender ID filter had to say about his message.
I told him that I thought the problem was that he does not have his SPF record setup correctly. His IT person came back and told me the problem is at my end and not his. I will accept that it is at my end, in that I am rejecting messages that fail, but he has a problem that is making them fail. If I do a text record check on mail.oklahomarespiratory.com, no SPF record shows up, but if I do a text record check on just the domain name oklahomarespiratory.com, I get the following SPF record. "v=spf1 mx -all"
My understanding of SPF is not as good as I would like it to be, so could someone help me with this. Is his record setup correctly?
Failed Recipient: joeBlo@voyagerhospicecare.com
Reason: Remote host said: 550 5.7.1 Sender ID (PRA) Not Permitted
-- The header and top 20 lines of the message follows --
Received: from wsip-70-164-64-78.ok.ok.cox.net [] by mail.uniformmarket.com with SMTP;
Mon, 13 Jul 2009 13:29:01 -0400
From: "Jeff Fannon" 
To: "'JoeBlo'" 
References: <1A9B1259E2DF8541923432089271442681A65CC5BE@vml.vhc.lan>
In-Reply-To: <1A9B1259E2DF8541923432089271442681A65CC5BE@vml.vhc.lan>
Subject: RE: test email from American Hospice, Inc.
Date: Mon, 13 Jul 2009 12:31:06 -0500
Message-ID: <002401ca03df$b46ca5d0$1d45f170$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcoD3necTVQjh3C4QT6RLuIbiWnOggAAPx1w
Content-Language: en-us
This is a multi-part message in MIME format.
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
My sender ID log
Timestamp       : 7/13/2009 12:31:08 PM
SessionId       : 08CBCC3530F0AC66
IPAddress       :
MessageId       :
P1FromAddress   : jeff@oklahomarespiratory.com
P2FromAddresses : {jeff@oklahomarespiratory.com}
Recipients      : {joeblo@voyagerhospicecare.com}
Agent           : Sender Id Agent
Event           : OnEndOfHeaders
Action          : RejectMessage
SmtpResponse    : 550 5.7.1 Sender ID (PRA) Not Permitted
Reason          : Fail_NotPermitted
ReasonData      : jeff@oklahomarespiratory.com
Diagnostics     :

Open in new window

Who is Participating?
jar3817Connect With a Mentor Commented:
This SPF record "v=spf1 mx -all" is perfectly legal.

It simply means the ONLY server allowed to send for this domain is the same as the MX record, which happens to resolve to and to hard-fail everything else.

According to the log you posted the sending IP address was, not, so your server rejected. It's not your problem but theirs. They should add their ipv4 space to their SPF record, or make sure all their mail comes from that ip address.
muzzi_inConnect With a Mentor Commented:
Hey his SPP has setup in wrong way as we are getting output just    "v=spf1 mx -all"

which is supposed to be contain their connecting IP addresses. which is not listed

here is example of Microsoft website SPF

        "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com inc
lude:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4: i
p4: ip4: ip4: ip4: ip4
: ~all"
You can ask that sender domain administrator to have look here by providing all the necessary stuff in the below links, just make sure from his end
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

VoyagerHealthCareAuthor Commented:
The following is what the tech on the other end said. Most of it does not prove his stance from what I can see. Does what he says hold water?

<<From their tech>>>
I looked at the information in the header Rick sent me and everything at our end is correct.  The only possible solutions are that we have been blacklisted at the recipients email server or american-hospice.net is behind a forwarding protocol that is hiding the true source of the email (us).
If email is successfully reaching email addresses that also do spf checking (aol.com as an example), then it isnt at our end.
Finally, nothing has been moved with regard to email.  mail.oklahomarespiratory.com is still aliased to mail.uniformmarket.com and the spf record is correct.

While AOL may check SPF, that doesn't mean that they reject on a fail condition, IMO.....
Chris DentConnect With a Mentor PowerShell DeveloperCommented:

You're dropping the message based on the rules they have set. The record is entirely legal, however, all that means is that you drop the message because they told you to.

Both IP addresses (the real SMTP server, and the one captured) are owned by the same ISP (Neucom, Inc). "forwarding protocols" cannot be anything to do with you if it's appearing from that source address. It must be the sender or the senders ISP.

I can't connect to an SMTP service on the source IP above, but that only means it doesn't accept inbound connections. There must be an SMTP service there or you couldn't have a conversation with it.

It shouldn't have an impact, but they clearly breach RFC 2181 by using a CNAME record as the target for an MX record.

http://www.ietf.org/rfc/rfc2181.txt (10.3)

We (well, you) should not have to support systems that refuse to obey simple rules.

In short, I consider this to be the senders problem. You cannot control the source of the TCP connection while you're so far away from it.

VoyagerHealthCareAuthor Commented:
My server shows the sending IP is but mail.oklahomarespiratory.com and mail.uniformmarket.com (The canonical name) ip address is is one of their name servers and its name is ns1.uniformmarket.com   How can this be?

Chris DentPowerShell DeveloperCommented:

I didn't notice that it was their name server, good catch. That rules out their ISP being responsible.

I would imagine that there's a NAT rule on their firewall, and that either they forgot to add outbound NAT for the mail server, or they have more than one mail server behind there and somehow the sending server differs.

VoyagerHealthCareAuthor Commented:
Thanks for everyones help. The guy is still saying that it is not his issue. What can you do, but laugh.......  From my side, it is plain as day.
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.

All Courses

From novice to tech pro — start learning today.