no more subject prefix for xetex mailing list

Julian Bradfield jcb+xetex at
Tue Mar 5 16:43:46 CET 2019

On 2019-03-05, Zdenek Wagner <zdenek.wagner at> wrote:
>> > And the last thing, setting of DMARC at 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 TXT records returns two records:
>>         8555    IN      CNAME
>>                8555    IN      TXT     "v=spf1 a ~all"
>> has a wildcard CNAME * -> (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 * (including to . 
Since TUG has SPF set up, there is a TXT record at containing
SPF information. There could be many other TXT records at, as
well as A, MX and other records.
Hence a query for TXT records at returns the
information that there is an SPF TXT record at . It does not
return any DMARC TXT record, either at or at .
Thus DMARC correctly concludes that does not have DMARC set

Having just checked the DMARC wiki, I find that CNAMEs are expected to
be followed when looking up DMARC records.

So now could do two thing to deploy DMARC - it could attach a
DMARC TXT record to, in which case lookup for
wil find that via the CNAME; or it could - correctly - put the DMARC
record at, in which case lookup for will
find that record directly, as wildcard CNAMEs are not applied to any
domain for which a real record exists.

More information about the XeTeX mailing list