[Hello71]

why can't you just periodically fetch and cache the records yourself? i.e. an ALIAS record for SPF. if the customer doesn't want to use dynamic dns, then you could even provide this service for them, of course charging a premium for the "enterprise feature".

[marcbradshaw]

There are services which do that, but it doesn't work in every situation. It can't (for example) cope with SPF macros, which is where the server looking up the record can replace parts of the record it is requesting with variables from the SMTP session (for example, by inserting the connecting IP address into the record lookup domain). In short, as stated in the article "email is complicated"

[sillystuff]

> why can't you just periodically fetch and cache the records yourself?

The only way this will help you is if you recursively de-reference all the records, and replace them with a list of allowed sender IPs. Now you have a new problem. You only get 255 characters in a single string in DNS. You can chain multiple 255 character strings together into a single record though, so you can get up to 4K characters. But, if you have a bunch of authorized spoofers (e.g., mailchimp) that different departments of your organization uses, even 4K characters may not be enough (source: I went through this exercise a couple years ago and our organization would have needed closer to 8K characters for the de-referenced records).

Our solution is to include our own outbound MTAs, and ?all. On inbound, we don't use SPF as a signal at all, as there are too many sites with misconfigured records.

Long term, we are trying to get each department to send spoofed mail using per-department subdomains, e.g., [e-mail], [e-mail], etc.

DKIM + DMARC is designed to handle the above without any of the issues SPF has.