v=spf1 include:spf.falconide.com include:sendgrid.net include:_spf.google.com ip4:xx.xxx.xxx.x ~all
Above is my SPF record for my domain, I am using an external tool to get open-source threat intelligence, in the tool it says my SPF config is not secure. Support is unavailable at the moment.
Does anything look insecure about the config?
No, this looks ok. The only thing I would change is to put the ip4 mechanism first.
You don’t provide any specifics of the actual error report, but it would not surprise me if it is misreporting thé ~all as a problem, even though it’s very unlikely to be. We would need to see your DMARC config to tell.
Maybe it just doesn't want you to use the soft fail?
If possible, try changing ~all to -all
Check the fail policy and qualifiers items of SPF records in Wikipedia:
https://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
https://en.wikipedia.org/wiki/Sender_Policy_Framework#Qualifiers
Use softfail (~all) as hardfail is NOT at all reliably enforced and can act in unexpected and seemingly random ways (suddenly a hosting company or mailbox provider stops or starts honoring hardfails).
Only a few mailbox providers reject based on just an SPF hard fail, and that's a moving target. For this reason, ~ALL is a best practice.
It’s DMARC that more reliably rejects if you want to tell mailbox providers to reject mail that fails DMARC. To to pass DMARC, either SPF or DKIM must fail and the domains in alignment. In. relaxed mode (by far the most common), alignment means the same organizational domain so example.com aligns with foo.example.com.
Always start with a p=none, a reporting only policy in DMARC and only VERY cautiously ramp up to a more aggressive DMARC policy such as p=reject or p=quarantine, as they can break legit mail if there’s legit mail that fails DMARC.
Delay deploying a more aggressive DMARC policy until you're sure all your legit mail's accounted for and authenticated. That way, only mail that's not authorized by you or flat out domain spoofing email (spammers and phishers) will fail DMARC.
Also, note that many ESPs by default have you use your own donain as the header from and use a domain of their own as the Envelope From.
If you request and setup a custom mail from domain, you can often get a subdomain of your domain set up the Envelope FROM (example.example.com) and the header from example.com (that recipients actually see).
If your envelope from isn’t example.com itself but instead foo.example.com then having the SPF set in your organizational domain uses as the header from won’t be useful. SFP is useful in the envelope from not the header FROM.
DKIM is signed by the header from domain (usually your organizational domain, example.com) and SPF is relevant in the envelope FROM domain only (e.g.,foo.example.com).
Also, keep in mind that an SPF record only allows 10 DNS lookups to be valid so check with a couple validation tools to makes sure it’s 10 or under. The above SPF you set uses 6/10 DNS lookups and is valid.
The SPF you have in your organizational domain isn't going to help, unless your Envelope From Domain is example.com.
And again ~ALL isn’t a problem. You can confirm this by doing some web searches on the risks and benefits of setting a softfail vs. a hardfail in SPF.
Some ESPs use their own domain as the envelope from meaning you need to explicitly work with your ESP to configure foo.example.com as the envelope from to get domain alignment with example.com, your organizational domain, and DKIM signing domain.
A complication is that many ESPs use a domain of there own for your Envelope From Domain and offer services/features such as a "custom sending domain," enabling you to use a subdomain of your own domain as the Envelope From Domain. Given that alignment policies have recently become more strict, it's a good idea to use a subdomain of your own domain as the Envelope From Domain rather than an ESP domain. For example, Microsoft recently enacted a policy whereby domain mis-alignment by itself causing either SPF or DKIM to fail is in itself enough to route email to spam. Other mailbox providers have been moving toward this sort of measure to try to get a handle on domain spoofing and the phishing and spamming that comes along with it.
Envelope FROM domain: Recipients do not see this domain. Header FROM domain: Recipients can see this in the visible FROM line.
