… seems legit? Although perhaps a bit too restrictive if the subdomains have valid SPF records that allow. DEFAULT DENY ALL … except … But this seems to imply problems with a sender’s wildcard dns?
Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Open a ticket for Hotmail<http://go.microsoft.com/fwlink/?LinkID=614866> ? From: mailop <mailop-boun...@mailop.org> On Behalf Of Mark Alley via mailop Sent: Thursday, May 16, 2024 3:11 PM To: mailop@mailop.org Subject: [EXTERNAL] [mailop] v=spf1 -all SPF treewalk? Hey all, got a dubious claim I read today that's somewhat of a head-scratcher. Let's lay out the scenario. * The following DNS answers are returned when queried (pseudocode): * domain.com IN TXT "v=spf1 -all" * test.domain.com IN TXT - NXDOMAIN * _dmarc.test.domain.com IN TXT - NXDOMAIN * _dmarc.domain.com IN TXT - NXDOMAIN * An email is sent with the RFC5321.mailfrom and RFC5322.from "t...@test.domain.com"<mailto:t...@test.domain.com>. * The email is not signed with DKIM. * The HELO FQDN has an SPF record with the corresponding MTA's IP in it. This claim stated that (and I'm quoting verbatim here), "I forced many ESPs to start failing SPF for any subdomain of a domain that has no explicit SPF, and fails SPF at the primary domain level (Context note: when v=spf1 -all exists at the primary domain)". Has anyone observed or heard of this SPF treewalk-esque evaluation logic being used by Receivers when an empty SPF fail policy is used at the organizational domain, but the subdomain used for SPF evaluation doesn't exist? - Mark Alley
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
