SPF issues

[bbigford]

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

[momurda]

include: requires a domain, not a server
Additionally i think a ?include:mail.sendingproviderdomain.com is the proper way to include 3rd party domains.

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Examples:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

"v=spf1 include:example.com -all"
If example.com has no SPF record, the result is PermError.
Suppose example.com's SPF record were "v=spf1 a -all".
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
If there is no match, other than the included domain's "-all", the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example.

Trust relationships — The "include:" mechanism is meant to cross administrative boundaries. Great care is needed to ensure that "include:" mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified otherdomain to prevent cross user forgery, "include:" mechanisms should give a Neutral rather than Pass result. This is done by adding "?" in front of "include:". The example above would be:

"v=spf1 ?include:example.com -all"

In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall Fail. (Better names for this mechanism would have been "if-pass", "on-pass", etc.)

ip4: is for ip addresses and serves as a way to say that these ips can send mail as yourdomain.com regardless of whether they are yours.

[dbeato]

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not check the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

[bbigford]

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

[dbeato]

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

[bbigford]

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

[dbeato]

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

[bbigford]

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

[dbeato]

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

[bbigford]

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

[dbeato]

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

Yes, your thinking is correct.

[bbigford]

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

Yes, your thinking is correct.

Cool, thanks.

[dbeato]

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

@dbeato said in SPF issues:

@bbigford said in SPF issues:

This one is stumping me. I resolved another engineer's issue, but I don't see why there was an issue to begin with. Here are some high points:

• On-premises Exchange server.
• Another provider needed to be added to SPF, as they are a service that sends on behalf of the client's domain.
• v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all
• Above SPF record was present when issue was happening.
• I looked up their spf record, which was v=spf1 ip4..... many IPs.
• PTR for exchange.ourdomain.com resolves, using MXToolbox.
• Forward lookup is fine as well.
• Removed mx a include:exchange.ourdomain.com and added ip4:<OurPublicIP>
• v=spf1 ip4:<OurPublicIP> include:mail.sendingproviderdomain.com ~all

What I don't get is why the first SPF doesn't check out. There is a PTR record in GoDaddy, and a host record pointing at the correct IP. SPF should read "any MX records, and IPs, for exchange.ourdomain.com are allowed to send; including a provider, and for spoofing there will be a soft fail".

Where am I wrong?

SPF does not neck the mx records of the includes, it checks only the A and MX records of the domain with the SPF record. You should add the SPF record of the exchange.ourdomain.com Email Servers (Namely Office 365, G-Suite or any other email vendor).

On-prem Exchnage. I also saw a vendor that has theirs written as mx:<email.domain.com>... I've saw some written with a:<hostname> but not mx: ... Didn't know that was a thing.

So how would you write an spf record for our instance to have validation? It works now with the public IP, but I can't figure out why the FQDN doesn't work.

Is your exchange.ourdomain.com hsoted elsewhere than Internally?

Hosted? I'm not sure I understand the question. It's internal Exchange, record is in GoDaddy.

Yeah, l was wondering if it was Office 365 or same type outside the office. But in short having include:exchange.domain.com it is looking for all the SPF records on that subdomain which causes the failure on lookup.

Why does that cause a failure? Can you explain a little further?

Okay, so this is the SPF you had and was failing

v=spf1 mx a include:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

Now this record was stating that the following records were allowed to send on behalf of your domain:
1-The MX records of your domain
2- The A records of your domain
3- The SPF record of exchange.ourdomain.com
4- The SPF record of mail.sendingproviderdomain.com.

Since you did not have an SPF record for exchange.ourdomain.com it was failing to register that as an allowed Sender.
If you wanted to include the exchange.ourdomain.com on your SPF it should be as below:

v=spf1 mx a ptr:exchange.ourdomain.com include:mail.sendingproviderdomain.com ~all

A PTR is what search for domain names on the SPF.

See more here:
http://www.openspf.org/SPF_Record_Syntax#include
http://www.openspf.org/SPF_Record_Syntax#ptr

Thanks for the clarification. At a very basic level, would it be correct to say include:exchange.ourdomain.com is creating essentially a circular lookup, since the SPF record there includes a sub domain that it is already trying to look up? Because of that reason, ptr:exchange.mydomain.com is looking at the IP... I could put ip4:<ourPublicIP>, but if I put ptr:exchange.mydomain.com I can change the public IP lookup in less places... this being one less place.

Is my thinking correct?

Yes, your thinking is correct.

Cool, thanks.

You got it anytime.