Look at the Sender's SPF record (look in the TXT record of the DNS of the Sender domain). Does it match the Sender details i.e., same IP address, etc.?
Main Topics
Browse All TopicsHello, I have a client trying to email my boss and keeps coming back with the error below. It looks like its on our part but not sure how to fix it. I researched it but found pretty much nothing. Our email is hosted with GoDaddy and then we have Postini as our Spam Filtering. I looked for any SPF settings on Postini but did not see anything. Thanks for any help.
**********
The original message was received at Thu, 20 Aug 2009 11:33:49 -0500 (CDT)
from mithril@localhost
----- The following addresses had permanent fatal errors -----
<bossname@example.com>
(reason: 550 5.7.1 SPF unauthorized mail is prohibited.)
----- Transcript of session follows -----
... while talking to example.com.s7a1.psmtp.com
>>> DATA
<<< 550 5.7.1 SPF unauthorized mail is prohibited.
554 5.0.0 Service unavailable
*************
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.
Is this what you mean? They are checking into it on their side as well.
100 mail.genesishealth.com 65.125.109.6 86400 SMTP Test
Record: v=spf1 ip4:65.125.109.16/30 ip4:65.125.109.6 a:mail.genesishealth.com a:mail0.genesishealth.com a:mail1.genesishealth.com a:mail2.genesishealth.com a:securemail.genesishealth
Yes,
This means that email from the domain should only be coming from these places:
65.125.109.16-19
65.125.109.6
64.22.192.81
You should be able to see in your logs (if you have SMTP logging enabled) the IP address that the sending server is using. If the IP does not match one of the above to '-all' setting they have created instructs your server (and other servers checking SPF) to consider the email NOT FROM A VALID SOURCE.
Shaun
http://www.dnsgoodies.com/
reports that you do not have a PTR Record/Reverse DNS. This is likely to be the reason why emails from this domain aren't accepted.
Actually their email doesnt even make it out of their network. As soon as they hit the send button they get the message (Below) so i dont have any kind of logs from them at all. They sent me the message below so thats how i got it. Hopefully that help a little.
**********
The original message was received at Thu, 20 Aug 2009 11:33:49 -0500 (CDT)
from mithril@localhost
----- The following addresses had permanent fatal errors -----
<bossname@example.com>
(reason: 550 5.7.1 SPF unauthorized mail is prohibited.)
----- Transcript of session follows -----
... while talking to example.com.s7a1.psmtp.com
>>> DATA
<<< 550 5.7.1 SPF unauthorized mail is prohibited.
554 5.0.0 Service unavailable
*************
Ask your Broadband Service Provider to setup your Domain on their system such that you have Reverse DNS setup - it could be that they are not recognizing your domain and think that your system is behaving as a relay for genesishealth.com. They might therefore reject your message, which would account for the speed of failure. The SPF error looks to be a red herring here.
The IP addresses for the SPF record - many do not have properly constructed PTR records, they have their placeholders instead (one does though, seems to be a hosted IT service - 64.22.192.81). You would need to know which IP was being used to send mail, and at the moment, that has not been clarified.
It seems from the NDR you are using a hosted email solution, so that is why you do not have access to the logs.
The error message this company is getting is being generated either by your hosted email solution, MOST likely because they are sending using an IP they haven't declared in their SPF record, or possibly because of PTR, but that is not clear at the moment, we don't know what IP they are using to send mail and that is not the descriptive reason given in the failure message.
Shaun
Hmmm it looks like you might have two issues at play here:-
(1) The Reverse DNS issue I've aleady mentioned.
(2) I was a bit puzzled as to why you were not seeing an Unable to Relay message against the 550 5.7.1 handshake result. It seems that it could be your SPAM filter after all: Ok this isn't the same product as you are using:-
http://social.technet.micr
but it looks as if your LAN pc's are not being recognized as being on your LAN. The SPAM filter thinks they are outside the LAN and that they are trying to relay messages out through your mail server. This accounts for the SPF error as the SPAM filter us consulting your SPF record and correctly deducing that 192.168.0.x (or whatever your local LAN is, is not a valid sending address).
I'm a little confused with your post moorhouselondon?
Perhaps I am not understanding the issue here:
AnthonyJK - An external user is trying to send to your domain right?
The external user is getting a bounce back as above?
The external user has an SPF record setup?
You are not having any issues with outbound mail are you?
Shaun
I'm unsure whether anthonyjk has anonymised any of the output, so in the absence of this, and not sure who sender and recipient are, I'm cautious of being too specific. I'm not comfortable with seeing a message with @localhost on its' headers - if this is internet-facing then there will be problems with that.
Wow thanks for all the feedback....Here is the real domains and what happended.
A client was emailing my boss and got the following error a minute later. The client forwarded this error to me at a different email address. (All i changed below is my bosses name) The mithril@localhost is orginal and what the client sent me.
**********
The original message was received at Thu, 20 Aug 2009 11:33:49 -0500 (CDT)
from mithril@localhost
----- The following addresses had permanent fatal errors -----
<myboss@unitedlinenservices
(reason: 550 5.7.1 SPF unauthorized mail is prohibited.)
----- Transcript of session follows -----
... while talking to unitedlinenservices.com.s7
>>> DATA
<<< 550 5.7.1 SPF unauthorized mail is prohibited.
554 5.0.0 Service unavailable
*************
Were you saying that unitedlinenservices.com has a SPAM filter?
If so, my explanation is that myboss email is hitting the SPAM filter and is being treated as an incoming message before it gets to be seen by your mail server. The SPAM filter is correctly saying that SPF fails on this message because it's coming from an internal, rather than external source, so it is failing it.
If my thoughts are correct then you need to configure the SPAM filter to ignore messages on the local LAN emanating from internal IP addresses.
I disagree. I believe that the mithril@localhost may just be something postini generate.
The email is being rejected by the third party SPAM provider (postini) because they have identified tha the email is being sent from an IP address that is not included in the SPF record. SPF works on IP, not on header information such as @localhost.
I would ask the senders what public IP address is being used for sending mail and check that this is correct.
The sending domain use a -all which is a lot more strict that ~all. Are they experiencing problems elsewhere?
This must be the problem here.
Shaun
moorhouselondon - The poster is not having an issue with outbound mail. This is an issue with a specific external sender sending mail inbound.
Postini is a hosted email filtering service offered by google. It is this service that is rejecting the mail due to an SPF fail.
It looks pretty straightforward at the moment, until more information becomes obvious, my number 1 suspicion is that genesishealth is using an IP address to send mail that is not included on their SPF record.
Shaun
My apologies shaun (and to anthonyjk for confusing the issue), rereading things properly yes I agree that I have misunderstood this.
The way to deduce the info that shaun is after is in this message:-
>The client forwarded this error to me at a different email address
Was this message also sent from the genesishealth.com domain? If so, have a look at the headers within that message and this should say which IP it came from.
Here is their Message Details from when they sent to my other email address.
X-AOL-UID: 3070.1721295458
X-AOL-DATE: Thu, 20 Aug 2009 4:36:53 PM Eastern Daylight Time
Return-Path: <clientname@genesishealth.c
Received: from rly-dc01.mx.aol.com (rly-dc01.mail.aol.com [172.19.136.30]) by air-dc06.mail.aol.com (v124.15) with ESMTP id MAILINDC062-b004a8db3d952;
Received: from mail1.genesishealth.com (65-125-109-18.dia.static.
Received: from 10.20.20.9 (mithril@localhost)
by mail1.genesishealth.com with ESMTP id n7KKafc03027
for <myemail@aol.com>; Thu, 20 Aug 2009 15:36:41 -0500 (CDT)
(envelope-from smithalyce@genesishealth.c
Received: from mail.genesishealth.com (10.20.20.9 [10.20.20.9]) by mail1.genesishealth.com ([10.20.20.27]); 20 Aug 2009 15:36:41 -0500 (CDT)
Received: from ok [10.20.20.52] by mail.genesishealth.com - SurfControl E-mail Filter (6.0.0); Thu, 20 Aug 2009 15:36:34 -0500
Received: from GENESIS-MTA by mailrelay with Novell_GroupWise; Thu, 20 Aug 2009 15:36:27 -0500
X-SEF-Processed: 6_0_0_39__2009_08_20_15_36
X-SEF-ZeroHour-RefID: fgs=0
X-SEF-7853D99-ADF1-478E-88
References: <4A8D348D.CB16.0070.0@genes
X-Mailer: Novell GroupWise Internet Agent 7.0.3
From: "Client Name" <clientname@genesishealth.c
To: myemail@aol.com
Date: Thu, 20 Aug 2009 15:36:17 -0500
Message-ID: <4A8D6D71.2CD9.00F7.0@genes
In-Reply-To: <8CBEFEC173EDE13-E68-6872@w
Subject: Re: Genesis Health System - Crescent Laundry
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding:
X-AOL-IP: 65.125.109.18
I agree rDNS is not setup correctly, and the SPF details seem to reflect an IP address the email is coming from (65.125.109.18)
I have run a number of tests and I cannot get an SPF failure myself, even when I am using a duff IP address for my own domain!
It only leaves rDNS as the culprit, but it still is a VERY misleading message if rDNS is the issue.
Are there any other senders getting similar NDR's?
Are you doing SPF checks on your Exchange server at all? Any other anti-spam on your server at all?
Shaun
Shaun: You are remembering that this is setup as -all rather than ~all ? (re your earlier comment).
To my mind it is strange that AOL (who arguably are one of the more aggressive rejectors of malconfigured email out there) should choose to accept a message which has been rejected in this case. It's almost as if SPF is weighted more highly (and decisively) than RDNS by AOL.
I believe I know why this is happening.
I managed to get the SPF response by using an IP address that is on blacklists (it also has no reverse DNS).
So, checked the genesishealth IP 65.125.109.18 and lo and behold, it is on a blacklist. This is nearly certainly the issue here. See http://www.mxtoolbox.com/b
I'd also advise for genesishealth to get a Reverse DNS record setup, because this will cause problems, but also being on a blacklist will cause more problems!
Shaun
Business Accounts
Answer for Membership
by: shauncroucherPosted on 2009-08-21 at 07:19:45ID: 25152045
It sounds like they have an SPF record setup for their domain, and you are checking the list and finding that the sender is using an IP address that is not listed in their own 'Allow' list.
Shaun