# SMTP: How does the receiving server validate using SPF?

**URL:** <https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852>\
**Category:** Factual Questions\
**Created:** [May 15, 2020, 1:43pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852 "2020-05-15T13:43:20Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![CookingWithGas](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cookingwithgas/32/485_2.png) [@CookingWithGas](https://boards.straightdope.com/u/CookingWithGas)\
**Post date:** [May 15, 2020, 1:43pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/1 "2020-05-15T13:43:20Z")

</div>

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](mailto: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&gt](http://x.co/srbounce&gt);

My SPF record is

```auto

Type Name Value TTL
TXT @ v=spf1 include:secureserver.net -all 1 Hour

```

The header of my sent email shows

smtp.helo=“[p3plsmtpa06-02.prod.phx3.secureserver.net](http://p3plsmtpa06-02.prod.phx3.secureserver.net)”; dkim=none (message not signed) header.d=none; dmarc=none (p=nil; dis=none) [header.from=gas.com](http://header.from=gas.com)  
X-Suspicious-Flag: NO  
X-Classification-ID: b321ea8a-9642-11ea-82fd-525400a8203f-1-1  
Received: from [173.201.192.103] ([173.201.192.103:46233] [helo=p3plsmtpa06-02.prod.phx3.secureserver.net](http://helo=p3plsmtpa06-02.prod.phx3.secureserver.net))  
by [smtp10.gate.iad3a.rsapps.net](http://smtp10.gate.iad3a.rsapps.net) (envelope-from \<cooking@gas.com\>)

---

<div class="post-metadata">

**Author:** ![Kyrie\_Eleison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/kyrie_eleison/32/7682_2.png) [@Kyrie\_Eleison](https://boards.straightdope.com/u/Kyrie_Eleison)\
**Post date:** [May 15, 2020, 5:45pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/2 "2020-05-15T17:45:05Z")

</div>

> [@CookingWithGas](#):
>
> 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.

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](https://postmarkapp.com/guides/spf) looks like a decent overview of SPF.

---

<div class="post-metadata">

**Author:** ![CookingWithGas](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cookingwithgas/32/485_2.png) [@CookingWithGas](https://boards.straightdope.com/u/CookingWithGas)\
**Post date:** [May 15, 2020, 9:07pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/3 "2020-05-15T21:07:06Z")

</div>

> [@Kyrie\_Eleison](#):
>
> 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](https://postmarkapp.com/guides/spf) 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.

---

<div class="post-metadata">

**Author:** ![Kyrie\_Eleison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/kyrie_eleison/32/7682_2.png) [@Kyrie\_Eleison](https://boards.straightdope.com/u/Kyrie_Eleison)\
**Post date:** [May 15, 2020, 9:41pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/4 "2020-05-15T21:41:42Z")

</div>

> [@CookingWithGas](#):
>
> 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](mailto:kyrie@foo.com)” is authorized to send mail on behalf of [foo.com](http://foo.com). That assurance comes from the fact that the person who controls the [foo.com](http://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.

---

<div class="post-metadata">

**Author:** ![vonespy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/vonespy/32/6204_2.png) [@vonespy](https://boards.straightdope.com/u/vonespy)\
**Post date:** [May 15, 2020, 9:53pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/5 "2020-05-15T21:53:15Z")

</div>

\>\>\> [cooking@gas.com](mailto: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&gt](http://x.co/srbounce&gt);

Reverse lookup: 40.172.232.204.in-addr.arpa. 86400 IN PTR [gate.forward.smtp.iad3a.emailsrvr.com](http://gate.forward.smtp.iad3a.emailsrvr.com). [emailsrvr.com](http://emailsrvr.com) shows as being a Rackspace domain.

Are you using a Rackspace account to send email from a mobile device or something? If so, you’ll need to add [emailsrvr.com](http://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.

---

<div class="post-metadata">

**Author:** ![Melbourne](https://avatars.discourse-cdn.com/v4/letter/m/b5e925/32.png) [@Melbourne](https://boards.straightdope.com/u/Melbourne)\
**Post date:** [May 16, 2020, 7:48am UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/6 "2020-05-16T07:48:50Z")

</div>

> [@CookingWithGas](#):
>
> 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.

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](mailto:melbourne@gas.com), (reply to envelope address [gas.com](http://gas.com)), using [mail.secureserver.com](http://mail.secureserver.com), [gas.com](http://gas.com) would need to have SPF txt record, on the [gas.com](http://gas.com) name server, which includes [secureserver.com](http://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.

---

<div class="post-metadata">

**Author:** ![CookingWithGas](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cookingwithgas/32/485_2.png) [@CookingWithGas](https://boards.straightdope.com/u/CookingWithGas)\
**Post date:** [May 16, 2020, 3:01pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/7 "2020-05-16T15:01:41Z")

</div>

> [@vonespy](#):
>
> Reverse lookup: 40.172.232.204.in-addr.arpa. 86400 IN PTR [gate.forward.smtp.iad3a.emailsrvr.com](http://gate.forward.smtp.iad3a.emailsrvr.com). [emailsrvr.com](http://emailsrvr.com) shows as being a Rackspace domain.
> 
> Are you using a Rackspace account to send email from a mobile device or something? If so, you’ll need to add [emailsrvr.com](http://emailsrvr.com) to your SPF record.

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.

> [@Kyrie\_Eleison](#):
>
> 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](mailto:kyrie@foo.com)” is authorized to send mail on behalf of [foo.com](http://foo.com). That assurance comes from the fact that the person who controls the [foo.com](http://foo.com) domain has inserted the SPF TXT record that lists it as an authorized sender.

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.

> [@Melbourne](#):
>
> 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](mailto:melbourne@gas.com), (reply to envelope address [gas.com](http://gas.com)), using [mail.secureserver.com](http://mail.secureserver.com), [gas.com](http://gas.com) would need to have SPF txt record, on the [gas.com](http://gas.com) name server, which includes [secureserver.com](http://secureserver.com). The include string tells the recipient how to lookup and legitimize IP addresses.
> 
> Which appear to be what the OP had.

Precisely.

---

<div class="post-metadata">

**Author:** ![CookingWithGas](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cookingwithgas/32/485_2.png) [@CookingWithGas](https://boards.straightdope.com/u/CookingWithGas)\
**Post date:** [May 16, 2020, 3:12pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/8 "2020-05-16T15:12:20Z")

</div>

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](mailto:board@myhoa.com). I am on the board of the HOA, and [board@myhoa.com](mailto: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](http://secureserver.net), and it bounces the email. The bounce message must somehow get back to me since Rackspace was forwarding on my behalf.

Does that make sense?

---

<div class="post-metadata">

**Author:** ![Kyrie\_Eleison](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/kyrie_eleison/32/7682_2.png) [@Kyrie\_Eleison](https://boards.straightdope.com/u/Kyrie_Eleison)\
**Post date:** [May 16, 2020, 3:52pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/9 "2020-05-16T15:52:50Z")

</div>

> [@CookingWithGas](#):
>
> Under what circumstances would a domain not authorize email to be sent from itself?

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](http://amazon.com) domain. Nonetheless, Amazon would not be happy if my servers started originating email as [jbezos@amazon.com](mailto:jbezos@amazon.com).

> [@CookingWithGas](#):
>
> 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.

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](http://myhoa.com) that indicates that Rackspace is authorized to relay messages on its behalf, like **vonespy** indicated. Here is [Rackspace’s guidance](https://support.rackspace.com/how-to/create-an-spf-policy/) on how to do so.

---

<div class="post-metadata">

**Author:** ![echoreply](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/echoreply/32/3641_2.png) [@echoreply](https://boards.straightdope.com/u/echoreply)\
**Post date:** [May 16, 2020, 6:27pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/10 "2020-05-16T18:27:04Z")

</div>

I have problems with [emailsrvr.com](http://emailsrvr.com), too. I have no association with Rackspace. I do not use Rackspace or [emailsrvr.com](http://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](http://emailsrvr.com) is not a valid sender for email from my domain. That is correct, email originating from [emailsrvr.com](http://emailsrvr.com) but claiming to be from my domain _should_ fail. I could add [emailsrvr.com](http://emailsrvr.com) to my SPF and DKIM records, but that will just mean that anybody using [emailsrvr.com](http://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](http://emailsrvr.com) relaying things in a way that breaks DKIM and SPF, or if there is actually spam originating from [emailsrv.com](http://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.

---

<div class="post-metadata">

**Author:** ![Melbourne](https://avatars.discourse-cdn.com/v4/letter/m/b5e925/32.png) [@Melbourne](https://boards.straightdope.com/u/Melbourne)\
**Post date:** [May 17, 2020, 2:39am UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/11 "2020-05-17T02:39:36Z")

</div>

> [@CookingWithGas](#):
>
> Maybe I am just not understanding something here. Under what circumstances would a domain not authorize email to be sent from itself?

Well, when the domain doesn’t have an SPF record with an ‘a’ or ‘mx’ value it’s not authorized 🙂

> [@](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![CookingWithGas](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/cookingwithgas/32/485_2.png) [@CookingWithGas](https://boards.straightdope.com/u/CookingWithGas)\
**Post date:** [May 17, 2020, 2:56am UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/12 "2020-05-17T02:56:32Z")

</div>

> [@Melbourne](#):
>
> […]simply removing your SPF record might fix your problems

Adding the SPF record was to solve a different problem, where a recipient server was refusing my email because there was no SPF record.

---

<div class="post-metadata">

**Author:** ![scabpicker](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/scabpicker/32/8268_2.png) [@scabpicker](https://boards.straightdope.com/u/scabpicker)\
**Post date:** [May 17, 2020, 11:49pm UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/13 "2020-05-17T23:49:23Z")

</div>

> [@CookingWithGas](#):
>
> 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](mailto:board@myhoa.com). I am on the board of the HOA, and [board@myhoa.com](mailto: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](http://secureserver.net), and it bounces the email. The bounce message must somehow get back to me since Rackspace was forwarding on my behalf.
> 
> Does that make sense?

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](http://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:

```auto

v=spf1 include:secureserver.net ip4:204.232.172.40 -all

```

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.

---

<div class="post-metadata">

**Author:** ![vonespy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/vonespy/32/6204_2.png) [@vonespy](https://boards.straightdope.com/u/vonespy)\
**Post date:** [May 18, 2020, 12:02am UTC](https://boards.straightdope.com/t/smtp-how-does-the-receiving-server-validate-using-spf/853852/14 "2020-05-18T00:02:15Z")

</div>

I think you’d be better off with

```auto

"v=spf1 include:secureserver.net include:emailsrvr.com ~all"

```

It’s probably safe to assume that Rackspace / [emailsrvr.com](http://emailsrvr.com) is almost certainly going to have multiple outbound mail servers / addresses so using that include will cover anything in the [emailsrvr.com](http://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.
