Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues

Tõnu Tammer <> Tue, 02 March 2021 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2B8B3A1853 for <>; Tue, 2 Mar 2021 05:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=n8twzQZ7; dkim=pass (2048-bit key) header.b=WB1O4rtd
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vQ6aCZEaSckQ for <>; Tue, 2 Mar 2021 05:47:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 615C63A184D for <>; Tue, 2 Mar 2021 05:47:04 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 4C7483F8F3 for <>; Tue, 2 Mar 2021 15:46:57 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1614692817; bh=SMcIphWyzpNw8h6l1NZRzNP7kZIYfsZTJ8Se+5ajWfg=; h=To:References:From:Date:In-Reply-To; b=n8twzQZ7fOPJGCNF4yybc2KNiElbzvTEdebC2qbnYJbi/wPIsf/GO9URjKpH5dv24 i52Lw60RY1d3w+Qbtw/4NtSxgFSe9X8m7P1TgCYDlf4EP4q+UJRP2uDKJ0Dpd76N/E qHfATXWvYxc30NSl2qF3ydrA2gHi92gWyJghrkgYiSGHOhvWe03i6bG2Ea9QLJ8Ibx +FTXo9BwiLtlbv2lZ5arnB+gCGe4LO3IwboEehfpc6EdbfToSHNgy+c6BLsR9FFJ8z Vb7A36ch7E8fDu7m8hQAQLI4xef4PxOgS65tctrEReFda5D+k+Qb/fSHlvvIG5guqi yZNsF0un+1N4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mailcertee; t=1614692817; bh=SMcIphWyzpNw8h6l1NZRzNP7kZIYfsZTJ8Se+5ajWfg=; h=To:References:From:Date:In-Reply-To; b=WB1O4rtdKRoUOJtjU7D06r5LKZZqgQb3g94hZ40Vd1nIAftoZhNry32hph7VT4nLl U+E81Mm4yiskLajCyZc+HA6vH0jjTWL5l3NZ1m+GpceP7V68tqODf3JUInDfGCwi+7 h7TbVhu+94FNcZKEnPFeHqUrYprtztD+VmrYfyTIlSy3TPIm/Z7kAlSZiD7C0qwCm7 tHuA5NQ6HuUakP+B3fSs0vo7S1ijr8NyoSaoy7DWr4M20o8I2iXUmQOGtAX3IuCZk/ mV56vr9yaL7YULBkyWPyqTfZ7i22ThgIWbIOkFRTmXGpQJV6NGMeKkAztn+QX3B6+B wIMyF4CbAI7rQ==
References: <> <> <> <> <> <>
From: =?UTF-8?Q?T=c3=b5nu_Tammer?= <>
Message-ID: <>
Date: Tue, 2 Mar 2021 15:46:55 +0200
BIMI-Selector: v=BIMI1; s=default;
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [dmarc-ietf] Using CNAME records to DMARC templates causes issues
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Mar 2021 13:47:09 -0000

Current RFC does not mention CNAME and while, in theory, it should work, 
we have seen that it does not always do so. Therefore, I would also 
support explicitly mentioning CNAME in the RFC.

It is true that people can make mistakes but people already make typos 
and other mistakes but having CNAME added to RFC would help in case of 
some service providers are managing the DMARC via CNAME.


On 02.03.2021 14:09, jbouwh wrote:
> L.S.
> I would suggest update the DMARC standard make explicit how CNAME can 
> be used or not.
> Beside of that, the opendmarc software should address this as a bug in 
> some way. Their opendmarc-check tool shows the correct policy that 
> fails from the opendmarc service when used on a CNAME-ed DMARC policy.
> The usecase I have seen failing only was one CNAME level deep.
> The failing mechanism in opendmarc for fetching the DMARC policy now 
> seems to leed leads to a 'none' policy.
> Regards, Jan
> Douglas Foster schreef op 2021-03-02 12:51:
>> Because CNAME usage was not mentioned in the previous DMARC document,
>> existing implementations may not have tested this configuration.   For
>> the policy publishing organization, this increases the possibility
>> that some recipients may treat the mail as not protected by DMARC.
>> As with any deployment issue, the publishing organization has no
>> reliable way to know if the deployment of DMARC implementations with
>> full CNAME support is "essentially complete".  This uncertainty may be
>> acceptable for some organizations, but may be an obstacle for others,
>> depending on their motivations for implementing DMARC.
>> On the implementation side, the use of CNAME will introduce the
>> possibility of referral errors, which may or may not require
>> mentioning in the DMARC specification, since such issues have probably
>> been addressed in core DNS documents.   The issues that come to mind
>> are:
>> CNAME referrals to non-existent names
>> Nested CNAME referrals (what depth is allowed?)
>> CNAME referrals that produce loops or excessive nesting depth.
>> DF
>> On Tue, Mar 2, 2021 at 6:12 AM Tim Wicinski <>
>> wrote:
>>> Using a CNAME at  _dmarc.example should not be a problem, as long as
>>> the CNAME target is a TXT record.  The DNS resolver functions should
>>> should handle this seamlessly. This does sound like a vendor
>>> software
>>> problem.
>>> I am aware of DKIM records being deployed using CNAMEs pointing to a
>>> TXT record target.
>>> Has anyone seen the above error condition when testing DKIM records?
>>> This definitely sounds like an issue with the software.
>>> Nobody should shy away from publishing DMARC records that are CNAMEs
>>> to DMARC
>>> TXT records elsewhere. Using this design should be strongly
>>> encouraged.
>>> tim _______________________________________________
>>> dmarc mailing list
>> _______________________________________________
>> dmarc mailing list
> _______________________________________________
> dmarc mailing list

Tõnu Tammer
CERT-EE juht / Executive Director of CERT-EE
Riigi Infosüsteemi Amet / Estonian Information System Authority

Mobile: +372 53 284 054

PGP:0x77A8997 / 9477 6B86 6A1E 849B C456  46D6 9CA8 9E41 77A8 997B