Cannot create CNAME and TXT-record for same subdomain

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.

What I did:

  1. Set up a TXT-record:
    _DMARC TXT “v=DMARC1; p=quarantine;; fo=1; pct=10”.

  2. Create CNAME record:

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.

Hi Gunni,

Thanks for your message, and welcome to deSEC.

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.

Stay secure,

Gunni, you seem to have used to generate your DMARC TXT record, which is fine.

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.


Hi @fiwswe,

what you described is correct and in practice, I’m receiving these reports on my postmaster-address as well as on the center-service.
They explain how to set it up at 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 txt
;; ANSWER SECTION:    3597    IN      CNAME 300 IN TXT "v=DMARC1; p=none; fo=1;;;"

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 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.


Hi Gunni,

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

  1. there is a CNAME redirect configured for the name, and that CNAME record points to,
  2. there is a TXT record configured at

In particular, there is no TXT record at 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 The only record configured at is the CNAME record.

So, dig asked for a TXT record for 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.

Stay secure,