I would not assume that the messages are coming from your own server. There is no reason why you should not get such an immediate response from a receiving server.
Main Topics
Browse All TopicsMy users are receiving the below error message when sending to a few specific outside recipients. This happens consistently with these recipients. The odd thing is that these messages appear to be generated by our Exchange server and happen immediately - in other words, our server is rejecting the message, not the target server. They are valid email addresses which the users have been successfully e-mailing for years, and can still be reached from users' outside webmail accounts (gmail etc). The messages never appear in the Exchange queue or the error logs.
I am running Exchange 2003 on a Windows Server 2003 box. There are no restrictions on user send rights aside from ones for message size and number of recipients, and all authenticated computers are authorized to relay. We use a Barracuda spam firewall, but obviously that only affects incoming mail. We do implement SPF but only on a "soft" basis (and again, that affects incoming mail).
I am at a loss as to why the 5.7.1 error references SPF at all.
Error message follows:
Your message did not reach some or all of the intended recipients.
Subject: RE: Pie chart
Sent: 8/17/2009 9:03 AM
The following recipient(s) could not be reached:
foo@bar.com on 8/17/2009 9:03 AM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<mail2.xyzzy.org #5.7.1 smtp;550 5.7.1 SPF unauthorized mail is prohibited.>
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
@Mestha: Our domain is configured for SPF. The tools at kitterman.com and vamsoft.com seem to indicate that our record is valid, and indeed I haven't made any changes in the record since I first set it up a couple years ago. Doing some DNS checks on intodns.com shows a missing MX A-record for our INCOMING mail server, but no other problems.
@Subsun: I have confirmed that it occurs when sending from Outlook. My user claims that it also happens from OWA, but a message I sent to that address over OWA did not generate a bounce. Still, using either method the mail is coming from our one-and-only outgoing mail server. We have McAfee AV (via ePO) here, but I do not have it configured to scan outgoing email.
Like Mestha, my first thought (from the text of the error) was that somebody was enforcing a hard SPF check, but to go from no problems whatsoever to having this happen twice in the same day with addresses on two different domains seemed unlikely, especially since (as near as I can tell) my SPF records are perfectly valid, and in any case haven't changed since before we had this issue.
@ollfried:
SPF record (last octets hashed) is:
v=spf1 ip4:72.32.207.xx ip4:216.158.xx.x ip4:216.158.xx.y include:foo.net -all
The public IP I'm sending mail over is the second 'ip4' entry in the above, and there is a valid MX record for that server. That IP reverse-resolves to the same name as the MX A-record: mail2.mydomain.tld. HELO string is the same: mail2.mydomain.tld.
Well, if your SPF record is correct and you are sure your sending server's IP is listed it may just as well be a problem on the receiving end - as you said it's only a few recipients. Do they happen to be all at one or two domains? I would contact those people and ask their postmaster for input, maybe they clarify why the mail is being rejected. And it may not even be your fault.
Are you really, really sure, that this is the IP you connect through? I've seen several people messing around with these things after their firewall git updates or network admins did something else to optimize traffic.
If you like, you can send a testmail to antwerpen(ät)uni(minus)mat
If everything else fails I recommend using ~all instead of -all, this will let SPF fail soft and your mails should get through,
I've received a few more complaints from users for a total of 4 domains that trigger this error. On a hunch I checked the MX records for these domains and, sure enough, they are all using the same hosted email service ("secureserver.net").
I still fail to understand why I'm getting the "SPF unauthorized mail is prohibited" error when our SPF record checks out, but the fact that it's only happening with ONE target mail server lends a lot of weight to the "it's them, not us" theory. If there are no updates to the situation by the end of the day I'll close this question and assign points.
secureserver.net is GoDaddy's email system. Therefore there will be a lot of domains that will have a problem as it is one of the biggest email hosting systems on the planet - I know one of their servers hosts over 250,000 domains. I would suggest getting your SPF record removed, and then recreated again using one of the SPF wizards.
Simon.
I do have one comment on the very first comment:
"Alas the use of SPF records is still very low, so doing a hard block on them is not really advisable."
I am not sure if I misunderstand this, but I do not agree with this statement. Obviously Simon is unarguably one of the most knowledgeable experts here so I must be careful :)
I don't think there is anything wrong with enforcing SPF records, we do that, too. Of course we only enforce if the SPF record exists, but in this case I think it's perfectly fine to block e-mail if it's a "hard" entry. My point is that if an SPF record exists the idea of those is that the sender organization's tells me which servers are authorized to send e-mails in their name. If a non-authorized server sends e-mail I think it's perfectly fine to block that e-mail, because it's either a) not legit or b) there is a configuration problem on the sender's end. In case of a) blocking it was a good idea, and in case of b) the sender needs to fix their systems or their SPF record.
Or am I wrong here?
I still see more servers without SPF records than with.
I also see large numbers of servers with wrong SPF records, or simply set to allow all servers.
That basically makes it useless.
It needs AOL, Yahoo, Gmail and Hotmail to all announce that SPF records will be required from a certain date to make SPF records make a difference. Until that happens, many will not have them.
Simon.
The problem with SPF records is that it does NOTHING to stop the amount of spam that you receive. It is almost exclusively for the benefit of others. Therefore there is no incentive for anyone to deploy it. If it was something that benefited the person setting it then you would see a higher use as everyone wants a new way to try and reduce spam.
Simon.
FWIW a couple of my users have recently started having this problem too ... and guess what, the recipients are also on GoDaddy's secureserver.net!
So NotifyNcc, I'm curious. Reading through this discussion, it sounds like a lot of good comments and suggestions were offered, but your problem did not actually get resolved. Is that correct? Does the problem still persist?
If so, perhaps I'll try to talk to someone at GoDaddy....
Thanks in advance!
Go through Microsoft's SPF wizard and see if the output matches your current SPF record. http://www.microsoft.com/m
We ere getting the same problem. Seems like it is now a common issue with secureserver.net. We've had our SPF record for years and have never recieved this bouce back. It started happening sporadically this week. We have went through microsoft's SPF wizard among other SPF tests and all have checked out and says our SPF record is configured correctly. Any more suggestions out there??? The error is below.
Your message wasn't delivered because of security policies. Microsoft Exchange will not try to redeliver this message for you. Please provide the following diagnostic text to your system administrator.
The following organization rejected your message: smtp.secureserver.net.
Diagnostic information for administrators:
Generating server: exmf025-nj-2.domain.local
johndoe@marcradio.com
smtp.secureserver.net #<smtp.secureserver.net #5.7.1 smtp; 550 5.7.1 SPF unauthorized mail is prohibited.> #SMTP#
Has anyone found a fix for this GoDaddy secureserver.net bounce backs. Any domain we email using secureserver.net we get smtp;5.7.1 SPF unauthorized mail is prohibited. This problem start about a month ago. I have tried changing our spf but no luck. Here is what our spf looks like v=spf1 ip4:209.234.69.138 a:webmail2.archwall.com a:ntsrvex2k3.archwall.com -all.
Business Accounts
Answer for Membership
by: MesthaPosted on 2009-08-17 at 08:12:04ID: 25115200
The reason it is coming from your server is because the remote server is rejecting it. The server in the NDR is NOT the server that is rejecting the message, but the server generating the message. It is the next hop that has the problem.
That is someone being very brave to mandate SPF records. They will be losing a lot of email messages by doing that.
Do you have an SPF record in your own DNS entries? The whole point of SPF records is that everyone has them, so that sites reject email based on them. Alas the use of SPF records is still very low, so doing a hard block on them is not really advisable. You may be using PSF records for inbound email, but you need to have them on your own domain as well.
Simon.