SPF on a subdomain that's a CNAME

Why the record is refused

A CNAME says "this name is an alias for another name". The DNS standard doesn't allow any other record at a name that has a CNAME (RFC 1034 §3.6.2, restated in RFC 2181 §10.1). An SPF record is a TXT record and has to live at exactly the name that sends mail, so it can't sit next to the CNAME. The same goes for MX. That's why cPanel and BIND report "CNAME and other data", and why some other DNS panels simply won't save it.

shop.example.com CNAME stores.example-host.net.

shop.example.com TXT "v=spf1 …" ← not allowed alongside the CNAME

What it means for email on that name

• Lookups follow the alias. When a receiver looks up SPF for shop.example.com, DNS follows the CNAME and returns the TXT records of the target. If the target publishes no SPF, the subdomain has none either. If the target does publish SPF, that record now speaks for your subdomain and authorizes whichever servers the target's owner listed.
• MX follows it too. Mail sent to @shop.example.com goes wherever the target's MX points, or bounces if it has none.
• Names below it are unaffected. The rule only covers the exact name. _dmarc.shop.example.com and selector._domainkey.shop.example.com are different names, so you can still publish DMARC and DKIM records there.
• DMARC still protects it. If the subdomain has no DMARC record of its own, receivers use the parent domain's record: the sp= tag if present, otherwise p=.

What to do: pick the case that fits

1. The name is only a website (most common)

Nothing needs fixing. No email is sent from @shop.example.com, so it doesn't need SPF or MX. To stop others spoofing it, rely on DMARC: set sp=reject (or p=reject) on the parent domain once your real senders pass, or publish _dmarc.shop.example.com with v=DMARC1; p=reject for this one name. A checker that marks missing SPF here as a "problem" is wrong; ours reports it as information.

2. You need to send mail as @that-name

Replace the CNAME first, then add SPF (and MX if you receive mail there):

• Use A/AAAA records if your web host gives you fixed IP addresses.
• Or use your DNS provider's alias feature (often called ALIAS, ANAME or CNAME flattening), which answers with addresses instead of a CNAME, so other records are allowed at that name.

Check with your web host before you remove a CNAME: some hosts need it to verify the domain or issue certificates.

3. Send from a different name

Often simpler: leave the website alias alone and send from the parent domain or a dedicated subdomain like mail.example.com or news.example.com, with its own SPF, DKIM and DMARC.

4. You control the target name

If the CNAME points to a name you own, you can publish SPF at the target. Remember it then applies to every name that aliases it.

Worked example: our own subdomain

This site runs at tools.mistermarbi.com, which is a CNAME to marbi-tools.pages.dev (the hosting platform). It's website-only: all our email goes from mistermarbi.com and notify.mistermarbi.com.

• A TXT query for tools.mistermarbi.com follows the alias and finds no SPF at the target. That's expected, and there's nothing to add.
• The MX query does the same: there's no mail server, because nobody receives mail at @tools.mistermarbi.com.
• DMARC is inherited from mistermarbi.com.

Run it in the checker above: SPF and MX come back as Info: this name is an alias, not as problems.

Quick reference

• SPF (TXT) and MX: not allowed at the CNAME name itself.
• DMARC: allowed, at _dmarc.name.
• DKIM: allowed, at selector._domainkey.name.
• A/AAAA: only if you replace the CNAME (or use your DNS provider's ALIAS/flattening).

Related: SPF checker · MX checker · DMARC checker