On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd= 40bayviewphysicians....@dmarc.ietf.org> wrote:
> If I followed Neil’s discussion of MajorCRM: > > > > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they use it. > And client's domain is only in the Mail from uses the vendor's domain ( somevendorxyz123.foo.com). It passes SPF in but it's not in alignment with the organizational domain name (example.com) that the client uses in the header from. This is super common and, as a practical matter, it works... except if you ever want to use DMARC's policy for anything other than reporting. The vast majority of people think that if you add include:bar.com (whatever vendor KB says) in the SPF that they are good to go. So many businesses have several entries in their organizational domain's SPF record yet the RFC5321.from is the vendor's domain. The client sometimes goes over the 10 DNS lookups with includes that aren't doing anything for them. I'm not sure that 10 DNS lookup limit. There are some prominent services of various sorts for which the single include will do over 10 DNS lookups and hat's just one of many includes a client might have (I know this isn't about SPF per se). Yes, I can usually quickly set up a subdomain to use instead of somevendorxyz123.foo.com but this isn't always possible or it requires pushing to get it done. This makes DMARC a sketchy tool to use for any policy above none which is in and of itself useful.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
