A receiving SMTP server is bouncing my emails. I think it has an error in how it validates SPF records. What I can’t figure out is what part of the header an SMTP server is supposed to look at to determine the sending SMTP server’s domain. What field in the incoming header is it supposed to use to check against SPF records?
My theory is that it is supposed to use the server that initiated HELO in the Received From field. However, it seems to be using the “from” field instead. In my case they are necessarily different (unlike, for example, a gmail account).
The tech support people on the receiving end are useless.
Here is the bounce message. Red details have been changed for privacy reasons:
>>> cooking@gas.com (after RCPT TO): 550 5.1.1 204.232.172.40 is
>>> not allowed to send from <gas.com> per its SPF Record.
>>> Please inspect your SPF settings, and try again. IB508
>>> <http://x.co/srbounce>
My SPF record is
Type Name Value TTL
TXT @ v=spf1 include:secureserver.net -all 1 Hour
The address that’s authenticated is the “envelope from” address (RFC5321.MailFrom), also sometimes called “Return-Path” or bounce address. This is different than the “header from”, which is typically what your email client displays.
At a glance, this looks like a decent overview of SPF.
Are you saying that I need an SPF record that shows I am allowed to send from the same domain that the email address is in? That sounds a little crazy.
More or less, yes. You need an SPF record in the domain associated with the “mail from” address on the email envelope. I find it easiest to think of this as the “mail from” part of the SMTP exchange.
I’m not sure why you think that’s crazy. SPF is intended to provide receiving servers with a means of independently verifying that the server that’s transmitting email that comes from “kyrie@foo.com” is authorized to send mail on behalf of foo.com. That assurance comes from the fact that the person who controls the foo.com domain has inserted the SPF TXT record that lists it as an authorized sender.
It’s not a perfect solution. It doesn’t do anything about verifying the actual email address that people see, the “header from” one, and it somewhat breaks the original SMTP concept of indirectly connected SMTP servers relaying email about to get it where it needs to go. DKIM is intended in part to address those problems.
>>> cooking@gas.com (after RCPT TO): 550 5.1.1 204.232.172.40 is
>>> not allowed to send from <gas.com> per its SPF Record.
>>> Please inspect your SPF settings, and try again. IB508
>>> <http://x.co/srbounce>
Are you using a Rackspace account to send email from a mobile device or something? If so, you’ll need to add emailsrvr.com to your SPF record.
You might also consider using “~all” instead of “-all”. I don’t suggest “-all” unless you’re absolutely sure you’re not going to be sending email from anywhere besides the domain(s) supplied in the SPF record.
As I understood it, you need an SPF record that shows you are allowed to send from the IP address you send from. You do this by using the “mx” value (if you are sending from your mail server), or the “a” value (if you are sending from one of your other servers). The mx and a values tell the recipient how to lookup and legitimize IP addresses.
You use the “include” value if you are sending from somebody else’s servers.
So if I wanted to send a message claiming that I was melbourne@gas.com, (reply to envelope address gas.com), using mail.secureserver.com, gas.com would need to have SPF txt record, on the gas.com name server, which includes secureserver.com. The include string tells the recipient how to lookup and legitimize IP addresses.
Which appear to be what the OP had.
I don’t like the dash in “-all”, and I don’t know if server wild cards are required.
Rackspace is the host on the receiving side. My host is GoDaddy. The Rackspace rep told me the bounce message I got was from my own host, not them, and couldn’t/wouldn’t do anything to help.
Maybe I am just not understanding something here. Under what circumstances would a domain not authorize email to be sent from itself? I would think that it would be a default to accept email from a server in a domain that matches the domain in the email address. It is not validating that specific email address, only the domain name in the email address.
I think I may have figured out what is going on. I did not include a key piece of information that at first I thought was not relevant.
The email I sent was to a person, and I copied another email address; let’s call the copied email address board@myhoa.com. I am on the board of the HOA, and board@myhoa.com is just a forwarder to all board members (there is no actual mailbox). Rackspace is the host for the forwarder. So Rackspace is getting an email from me, and forwarding it. I think this is not the same type of forwarding as when you click Forward on an email; it is more like it sends the email and it appears to the recipient as if it had been sent directly to the recipient by the original sender. I guess it repackages the headers to look that way.
So now my email host gets the email, and sees that the only SPF record is for secureserver.net, and it bounces the email. The bounce message must somehow get back to me since Rackspace was forwarding on my behalf.
Here’s a real world example: I run some systems that use Amazon Web Services. When they send email, it comes from a host using an IP address registered to Amazon, in the amazon.com domain. Nonetheless, Amazon would not be happy if my servers started originating email as jbezos@amazon.com.
That makes perfect sense and is exactly the sort of thing SPF is set up for. That sort of forwarding is usually called relaying. You need to set up an SPF record in myhoa.com that indicates that Rackspace is authorized to relay messages on its behalf, like vonespy indicated. Here is Rackspace’s guidance on how to do so.
I have problems with emailsrvr.com, too. I have no association with Rackspace. I do not use Rackspace or emailsrvr.com for anything. When my domain sends email to a Yahoo address I get a DMARC report of a DKIM and SPF failure because emailsrvr.com is not a valid sender for email from my domain. That is correct, email originating from emailsrvr.com but claiming to be from my domain should fail. I could add emailsrvr.com to my SPF and DKIM records, but that will just mean that anybody using emailsrvr.com will be able to send spam that appears to be from me.
I don’t know if the fault is with emailsrvr.com relaying things in a way that breaks DKIM and SPF, or if there is actually spam originating from emailsrv.com claiming to be from my domain, which just happens to be sent to Yahoo, but not Google. I’ve only ever received DMARC reports from Yahoo and Google, but I have a tough time imagining a spam campaign with no gmail address in it.
Well, when the domain doesn’t have an SPF record with an ‘a’ or ‘mx’ value it’s not authorized
It certainly used to be the default to accept email from a server … but if you decide that you want SPF authentication, then you only accept email from a server named (by ‘a’, ‘mx’ or ‘include’) in a SPF record. AFAIK, it was never default/common by anyone to match a domain in the email address against anything before SPF, and mostly still isn’t. Forwarding was part of how the system was expected to work.
I still (rarely) send mail through a foreworder, and with no SPF record it still works on the rare occasions I try. People aren’t seeing a lot of junk mail from my domain or from my forwarder, and I’m not getting blocked. Simply fixing the ‘-all’ might fix your problems: simply removing your SPF record might fix your problems
Hmm, yeah, that explains it. Because this error is most assuredly telling you that the receiving end said that it received a message from 204.232.172.40 saying it was being sent from your domain in the HELO/EHLO exchange. It appears that the mail list server is configured to send the message as being from @gas.com when it relays for you. You have correctly deduced that since that IP is not included in the secureserver.net SPF records, it’s getting rejected (also due to the -all statement). Really, if you can rely on that IP address not changing, you can change your SPF record to:
That should stop it. I would suggest contacting whoever runs this mail list and ask them if they have an SPF record you could use through an include statement (e.g. include:myhoa.org*). If not, if they can provide their IPs or their network range, you can add it using the ip4 syntax for the SPF record.
*Caveat: there is a limit of 10 DNS lookups on SPF records. If they have 10 lookups already in their record, you can’t include them with this statement.
It’s probably safe to assume that Rackspace / emailsrvr.com is almost certainly going to have multiple outbound mail servers / addresses so using that include will cover anything in the emailsrvr.com domain. And I still support using “~all” since it gives the receiving server more flexibility in case something isn’t configured quite right.
