I would like to create a _DMARC-record for domain dot com using a TXT-record and I need to setup a CNAME for _DMARC at the same time, but the system refuses this.
Creation of the CNAME is being refused with the error message: "{ “non_field_errors”: [ “RRset with conflicting type present: database (TXT). (No other RRsets are allowed alongside CNAME.)” ] } "
Why doesn’t the system allow a TXT-record as well as a CNAME-record for the same subdomain?!?
mxtoolbox enforces this setup to validate the domain ownership.
It is generally not possible to set a CNAME and any other record for the same name. The reason is that a CNAME acts like a redirect to something else. It is meaningless to have a redirect and some other setting at the same time. – This is not a deSEC restriction, but a part of the DNS specification (see RFC 1034 page 15). It applies to other DNS providers as well.
From this fact, I conclude that there must be a misunderstanding with the DMARC setup. Can you post a link to where you got the instructions? Maybe we can clarify once we know what you’re looking at.
Your proposed _dmarc TXT record looks valid if you want 10% of the mails checked for SPF conformity and you are asking the checking systems to quarantine mails that fail the check. In your case the reports get sent to MXToolbox, not to yourself, but that may be what you want. (I have not tried that service of MXToolbox myself.) Note that you may specify more than one mail address. So you could add your own to also receive the reports.
You may want to change the subdomain _DMARC to the lower case _dmarc, as DNS does not use upper case in names. But deSEC will probably correct or flag that for you when you add the RR.
The reporting mail URIs do not have to point to the domain that contains the _dmarc TXT record and they do not need any other _dmarc subdomains in the mail address. So what do you need the _dmarc CNAME record for?
BTW: SPF and DMARC may lead to lots of reports or even delivery problems in conjunction with mailing lists. When a list server forwards your mail to the list members, it usually does not change the FROM address. So it will effectively send mail on behalf of your domain. Unless your SPF policy allows this (in which case you may as well not have one) DMARC validating mail systems will apply the DMARC policy and in your case quarantine the mail and send a report. Opinions vary whether this is a fault in the SPF concept or with the mailing list servers. But the fact is, they don’t mix well.
what you described is correct and in practice, I’m receiving these reports on my postmaster-address as well as on the mxtoolb.com-delivery center-service.
They explain how to set it up at https://mxtoolbox.com/dmarc/dmarc-setup-cname and when trying to add a domain in their customer panel.
Even though @peter provided and rfc that forbids it, mxtoolbox requires you to set up a CNAME and a TXT-record for the _dmarc-subdomain at the same time.
In practice, this works with other dns providers:
dig _dmarc.domain.com txt
;; ANSWER SECTION:
_dmarc.domain.com. 3597 IN CNAME domain.com.hosted.dmarc-report.com.
domain.com.hosted.dmarc-report.com. 300 IN TXT "v=DMARC1; p=none; fo=1; rua=mailto:55538c69@mxtoolbox.dmarc-report.com; ruf=mailto:555538c69@forensics.dmarc-report.com;"
I agree with you that deSEC is properly following the RFC1034, but is there any chance that one implements an exception for the for _dmarc-subdomain, as mxtoolbox.com is a popular service?
I filed a bug report with them, but don’t think they will listen.
DNS providers like Hurricane Electric or cloudflare allow you to create a cname and a txt record in parallel in deviation from the RFC.
The link you provided explains how to set up a CNAME record. It does not say anything about TXT records. (Some screenshots are misleading though.)
I can’t find the claim on the page that both CNAME and TXT should be set up for the same name.
That is a misunderstanding. Your output shows that
there is a CNAME redirect configured for the name _dmarc.domain.com, and that CNAME record points to domain.com.hosted.dmarc-report.com,
there is a TXT record configured at domain.com.hosted.dmarc-report.com.
In particular, there is no TXT record at _dmarc.domain.com. The TXT record is setup up at the target of the CNAME record, not at the same name. (You can verify this by querying dig TXT domain.com.hosted.dmarc-report.com.) The only record configured at _dmarc.domain.com is the CNAME record.
So, dig asked for a TXT record for _dmarc.domain.com. What you got is the information that there is a redirect configured instead, and the resolver was nice enough to follow the redirect and also give you the TXT record of the redirect target. The fact that you got a TXT record and a CNAME record does not indicate that they belong to the same name (take a look at the first column of the output).
I would be very surprised if that were true, as the resolving behavior in this case is undefined. Even if someone allowed this, you could not reasonably expect that any clients would handle the case in the way you are proposing. I suspect that the root of the misunderstanding is that the CNAME and TXT records are actually defined for different names, as in the case above.