On 2019-03-05, Zdenek Wagner <zdenek.wag...@gmail.com> wrote: >> > And the last thing, setting of DMARC at tug.org is wrong, the DNS >> > query returns the SPF record, not the DMARC record. >> >> No, it isn't wrong - there is no setting for DMARC. >> A dns query for _dmarc.tug.org TXT records returns two records: >> >> _dmarc.tug.org. 8555 IN CNAME tug.org. >> tug.org. 8555 IN TXT "v=spf1 a a:freefriends.org >> mx:freefriends.org a:fencepost.gnu.org include:_spf.google.com ~all" >> >> tug.org has a wildcard CNAME *.tug.org -> tug.org (which strikes me as >> bad practice, but not wrong). >> >> DMARC does not specify whether CNAMEs should be followed, but even if >> they are, DMARC only looks at valid DMARC records. >> > Yes, there is CNAME but it refers to a SPF record, not to DMARC > record. DMARC should contain a different type of information with a > different syntax.
It seems you understand the DNS no better than DMARC. A CNAME record is an alias, and it does not refer to an SPF record. The CNAME redirects the name *.tug.org (including _dmarc.tug.org) to tug.org . Since TUG has SPF set up, there is a TXT record at tug.org containing SPF information. There could be many other TXT records at tug.org, as well as A, MX and other records. Hence a query for TXT records at _dmarc.tug.org returns the information that there is an SPF TXT record at tug.org . It does not return any DMARC TXT record, either at _dmarc.tug.org or at tug.org . Thus DMARC correctly concludes that tug.org does not have DMARC set up. Having just checked the DMARC wiki, I find that CNAMEs are expected to be followed when looking up DMARC records. So now tug.org could do two thing to deploy DMARC - it could attach a DMARC TXT record to tug.org, in which case lookup for _dmarc.tug.org wil find that via the CNAME; or it could - correctly - put the DMARC record at _dmarc.tug.org, in which case lookup for _dmarc.tug.org will find that record directly, as wildcard CNAMEs are not applied to any domain for which a real record exists.