I read that it's not valid to have a CNAME for a domain that also has its own SPF, because all records are taken from the domain that the CNAME points to.

However, this doesn't seem to be what happens for me. I have pi.dantup.com CNAMEd to dantuppi.dynv6.net, however my SPF record seems to work fine (there is no SPF on the dynv6.net domain:

https://toolbox.googleapps.com/apps/dig/#CNAME/pi.dantup.com https://toolbox.googleapps.com/apps/dig/#TXT/pi.dantup.com

This seems to work fine testing with this tool. However, a friend has his set up very similarly and it appears to not be working. Before digging into this, I'm trying to understand if what mine is doing is correct?

  • 1
    No, your setup is broken. It may only seem to work because of nonconformant DNS servers or resolvers, but conformant ones will never see your SPF record. – Michael Hampton Apr 19 '16 at 16:30
  • Bummer :( Google seems to have no problem with it (it shows my emails as spf passes), so I guess it must be the DNS server that's bad and resolvers just work with it – Danny Tuppeny Apr 19 '16 at 17:18
  • Danny, I don't think that's the case, try testing by sending an email to mailtest@unlocktheinbox.com and check-auth@verifier.port25.com - Every SPF tester I looked at the code for never references the CNAME value. – Henry Apr 19 '16 at 17:34
  • @henry Well this is in the headers of an email I sent to Gmail: Received-SPF: pass (google.com: domain of danny@pi.dantup.com designates as permitted sender) client-ip=; ?! pi.dantup.com is a cname. Both cname and txt appear here: toolbox.googleapps.com/apps/dig/#ANY/pi.dantup.com – Danny Tuppeny Apr 19 '16 at 17:49
  • That's fine, that's just an ANY query in DNS - Which returns all records. Where your port25 and mailtest results pass as well? If so you got nothing to worry about – Henry Apr 21 '16 at 15:22

The discussion you refer to describes CNAME-ing a TLD (top-level domain) to another domain. That is not a good idea.

But CNAME-ing a subdomain over to a third party is actually preferred setup to arrange, for example, bounce-handling by a third party (marketing tools and such). For example for sending newsletters via the subdomain of newsletters.example.com by a marketing tool hosted at newsmailers.org, you can use a CNAME record that points newsletters.example.com to example_com.newsmailers.org, actively delegating the responsibility for SPF and MX records for the newsletters.example.com subdomain to the external party. You cannot, however, add additional RRs (TXT / MX / A) with the same name to DNS, according to RFC 1912.

RFC 1034 section 3.6 states that the RDATA for a CNAME contains a domain name (typically where an SPF TXT record lives), while the RDATA for an MX or NS record should contain a Host Name.

Also, be carefull with CNAMEs that point to other CNAMEs. This will (most often) fail. See RFC 1912 section 2.4

If you take a look at the following article by DMARCIAN, I hope you'll find more details and information you were looking for:


If you want to see what's happening on DNS, just check: https://dns.google.com/query?name=pi.dantup.com&type=TXT&dnssec=true

If you set up a CNAME, you'll first see an answer of type 5 (CNAME) and a second answer of type 16 (TXT).

  • This is flatly wrong. The CNAME precludes reliable use of any other RRs at the node, notwithstanding any web interfaces' ideas to the contrary. – MadHatter supports Monica May 30 '18 at 7:53
  • I believe we agree that we should not use CNAMEs at the root of a domain. I also believ that we agree we should not use a TXT record with the same host name as a CNAME record. But still I believe it is fine to – Reinto May 30 '18 at 9:04
  • But still I believe it is fine to set a CNAME for pi.dantup.com targeting dantuppi.dynv6.net and dantuppi.dynv6.net being a TXT record. This is the exact way that AmazonSES, SendGrid, Office365 and many others do delegation of DKIM records. The article you mention is all about CNAMEs at the apex of a domain, is it not? – Reinto May 30 '18 at 9:11
  • This is why we frown on link-only answers: unless I read your link I can't understand what you're suggesting. Now you've made it concrete, which is good (though better if you edited it into your answer). If you edit your answer so that it uses the links as support rather than part of the content, I'll remove my downvote. – MadHatter supports Monica May 30 '18 at 9:52
  • Sorry about that. I'm new to this site. I've updated my answer and I hope it includes enough information on the topic to make clear what I meant. If you have any other pointers, I'll be glad to incorporate them into my answer. – Reinto May 30 '18 at 11:05

If you have no concern on recursive searches (take into account SPF manages 10 MAX) you can have a redirect SPF, which in my opinion is better than CNAME as SPF is essentially a TXT record on the root of the domain, a CNAME might break you and cause issues when creating other TXT records on the root like verification records which everyone seems to be using now

You can implement this SPF on the root "v=spf1 redirect=_spf.mailhostbox.com".

Where _spf.mailhostbox.com is your redirected location

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.