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 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).
-
@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.
-
@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?
-
@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.
-
@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.
-
@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?
-
@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 ~allNow 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 ~allA 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 -
@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 ~allNow 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 ~allA 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#ptrThanks 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?
-
@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 ~allNow 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 ~allA 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#ptrThanks 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.
-
@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 ~allNow 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 ~allA 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#ptrThanks 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.
-
@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 ~allNow 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 ~allA 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#ptrThanks 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.
