Based on RFC 1034 and RFC 1035 for the CNAME record itself, and RFC 2181 for the DNSSEC clarification.
A CNAME record is a DNS alias. It points one domain name at another domain name, instead of pointing at an IP address. When a resolver hits a CNAME, it follows the alias to the target name and looks up the real records there.
CNAME stands for Canonical Name, and the record is defined in RFC 1034 Section 3.6.2, titled "Aliases and canonical names." Think of it like a forwarding label: www.example.com can be an alias that says "I am really example.com, go look there."
Here is the part the search results usually miss. Most CNAMEs people add in 2026 are not for websites. They are for email authentication. Your provider asks for a CNAME so it can manage a DKIM key, an MTA-STS policy, or a BIMI asset on your behalf. We see this from the operator's side every day: DMARCTrust hosts MTA-STS policies behind a customer CNAME, so we will use that as a worked example later in this guide.
What you will learn
How a CNAME record works
A CNAME record has two parts: the alias (the name you are defining) and the canonical name (the target it points to). When a resolver looks up the alias, the authoritative server returns the CNAME, and the resolver re-queries the target for the record type it actually wanted.
Here is the simplest example. Your website lives at example.com, and you want www.example.com to follow it:
A browser asking for www.example.com gets the CNAME, follows it to example.com, reads the A record, and connects to 203.0.113.10.
The same pattern shows up when you point a subdomain at someone else's service. A shop hosted on a platform looks like this:
You never touch the IP address. If the platform moves shops.myplatform.com to a new server, your shop.example.com follows automatically. That is the whole point of a CNAME: the target owner controls the destination, you just point at the name.
Chain following. A CNAME can point to a name that is itself a CNAME, forming a chain. RFC 1034 Section 5.2.2 says resolvers should follow these chains, signal CNAME loops as an error, and catch aliases that point to non-existent names. It also notes that multiple levels of aliasing are inefficient and should be avoided, even though they are not an error. Keep chains short.
CNAME vs A record (and vs ALIAS / ANAME)
The quickest way to keep these straight: an A record ends at an IP address, a CNAME ends at another name. ALIAS and ANAME are vendor inventions that fake a CNAME where a real one is not allowed.
| Record | Points to | Standard? | Use it when |
|---|---|---|---|
| A / AAAA | An IPv4 / IPv6 address | Yes (RFC 1035) | You control the host and know its IP. Required at the zone apex. |
| CNAME | Another domain name | Yes (RFC 1034) | You want a subdomain to track a target name a provider controls. |
| ALIAS / ANAME | Another domain name, resolved to an IP by the DNS host | No (provider-specific) | You need CNAME-like behavior at the apex, where a real CNAME is forbidden. |
ALIAS and ANAME are not in the DNS standard. They are a feature of specific managed DNS providers. The DNS host resolves the target to an address behind the scenes and answers your apex query with A and AAAA records, so the rest of the world sees ordinary address records. Cloudflare calls its version CNAME flattening, and Amazon Route 53 calls its version an ALIAS record. The behavior is similar; the names and limits differ by vendor, so confirm what your DNS host supports.
The rules that break CNAME records
Three RFC rules cause almost every CNAME problem. Learn them once and you will avoid the mistakes that fill support tickets.
Rule 1: a CNAME cannot share a name with other records
This is the big one. RFC 1034 Section 3.6.2 states it directly:
"If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different."
So if shop.example.com has a CNAME, it cannot also have an MX record, a TXT record, or an A record at the same name. The reason is consistency. A resolver that has cached the CNAME is allowed to use it for any record type without checking back with the authoritative server, so the alias and its target can never drift apart.
Rule 2: the one DNSSEC exception
RFC 1034's "no other data" rule has a single narrow exception, added by RFC 2181 Section 10.1:
"An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data."
In plain terms: when DNSSEC signs your zone, the signing-related records are allowed to live next to a CNAME because they describe the CNAME itself. Everything else is still forbidden. You rarely need to think about this by hand, because your DNS provider manages the DNSSEC records for you, but it is why the blanket "nothing else, ever" phrasing you see online is slightly too strong.
Rule 3: no CNAME at the zone apex
The apex (also called the root or naked domain) is example.com with nothing in front of it. The apex must carry an SOA record and NS records, because that is what defines the zone and its name servers. By Rule 1, a name with a CNAME cannot hold those records, so a CNAME at the apex is impossible. This is not a vendor limitation; it follows directly from the RFC.
That is exactly why ALIAS, ANAME, and CNAME flattening exist. When you need "point my naked domain at this provider's name," your DNS host resolves the target to addresses and publishes real A / AAAA records at the apex on your behalf. The apex stays standards-compliant; you get CNAME-like convenience.
Rule 4: never leave a dangling CNAME
Security risk: subdomain takeover. A dangling CNAME points to a target that no longer exists or is no longer yours, for example a cloud service you decommissioned. RFC 1034 Section 5.2.2 says aliases pointing to non-existent names should be caught as errors, but DNS will happily keep serving the CNAME.
If an attacker can register or claim that abandoned target (a freed-up cloud bucket, a cancelled SaaS tenant), they control whatever www.example.com or shop.example.com serves. That is a subdomain takeover. The fix is simple: delete the CNAME the moment you decommission the service it points to.
Why your email provider asks for a CNAME (delegation)
Here is the question that actually drives most CNAME edits today: "Why did my email provider ask me to add a CNAME?" The answer is delegation.
When you publish a CNAME that points into a provider's domain, you hand that provider control of the record's real value. They can change what the alias resolves to whenever they need, and your DNS never changes again. For email authentication this matters because keys and policies rotate. A provider that can rotate a DKIM key, or update an MTA-STS policy, without filing a DNS-change request with you is a provider that can keep your email secure without friction. The CNAME is the handoff.
The three email uses below all rest on this one idea.
DKIM CNAME delegation
DKIM signs your outbound mail with a private key and publishes the matching public key in DNS. Some providers ask you to publish that public key directly as a TXT record. Others ask for a CNAME that points at a key they host, so they can rotate the key on their side without touching your zone.
Microsoft 365 is the classic CNAME example. For a custom domain, Microsoft generates two key pairs and asks you to publish two CNAME records, selector1._domainkey and selector2._domainkey, pointing into your <tenant>.onmicrosoft.com domain. Microsoft holds both keys and rotates between the two selectors for you.
Illustrative shape only. Do not copy these values.
Pull the exact values, do not guess them. The onmicrosoft.com shape above is the format Microsoft now calls the "old DKIM format," kept for existing and initial domains. Since May 2025, new custom domains get a different target ending in -v1.dkim.mail.microsoft. Microsoft's own documentation warns that "the old and new formats can't coexist for the same selector," so a string copied from an old blog post may be wrong for your tenant. Get the current values from the Microsoft 365 Defender portal, or run Get-DkimSigningConfig -Identity example.com | Format-List Selector1CNAME,Selector2CNAME in Exchange Online PowerShell. Always confirm against current Microsoft docs.
Now the correction the rest of the web gets wrong: DKIM does not always use a CNAME. Google Workspace publishes its DKIM key as a TXT record at google._domainkey, not a CNAME. So "DKIM needs a CNAME" is provider-specific, not a rule of DKIM. CNAME-based DKIM is common with Microsoft 365, SendGrid, Mailgun, and Amazon SES; TXT-based DKIM is what Google Workspace uses. Follow the record type your platform actually tells you to publish.
Provider walkthroughs with the exact records: Office 365 DKIM setup, Google Workspace DKIM setup, SendGrid DKIM setup, and Amazon SES DKIM setup.
MTA-STS policy hosting over a CNAME
This is the part no other explainer can write from experience, because we operate it. MTA-STS (RFC 8461) requires you to serve a policy file over HTTPS at https://mta-sts.<yourdomain>/.well-known/mta-sts.txt, with a valid TLS certificate. Standing up a web server and certificate just to serve one text file is a chore, so DMARCTrust hosts it for you.
You publish a single CNAME:
That alias delegates the HTTPS endpoint to us. We serve the policy file and the TLS certificate, and we auto-generate the policy ID so your DNS TXT record stays in sync.
This is the exact same delegation pattern as a CDN: you point a name at a host someone else operates, and they serve the content and the certificate. Because we are on the receiving end of that CNAME, we treat it carefully. Our provisioning step runs a DNS preflight before creating the hosted endpoint, and our deprovisioning step refuses to tear down the endpoint while your CNAME still points at mta-sts-proxy.dmarctrust.com. That guard exists specifically to prevent the dangling-CNAME problem from Rule 4: we will not leave you pointing at a target we just deleted. See hosted MTA-STS for how the module works, or the MTA-STS fundamentals guide for the protocol detail.
BIMI and CNAME
BIMI is where the web tends to overclaim, so let us be precise. BIMI itself is published as a TXT record at default._bimi.example.com. That TXT record does not need a CNAME, and BIMI does not require one.
CNAME shows up only in the asset-hosting layer. The BIMI TXT record references your logo (an SVG file) and, for most inbox providers, a Verified Mark Certificate or Common Mark Certificate (a PEM file) by HTTPS URL. Teams often serve those asset hosts, or a dedicated brand subdomain, behind a CNAME that points at a CDN. That CNAME is a convenience for hosting the files, not a BIMI dependency. If someone tells you "BIMI needs a CNAME," they are conflating the asset host with the BIMI record.
How to add and check a CNAME record
Adding a CNAME in any DNS panel comes down to three fields:
- Type: CNAME.
-
Name / host: the alias, the subdomain you are defining (for example
shopormta-sts). Most panels assume your domain, so you enter the label, not the full name. -
Target / value / points to: the canonical name you are pointing at (for example
shops.myplatform.com). Many providers expect a trailing dot. - TTL: how long resolvers may cache the record. The default (often 1 hour) is fine; lower it only just before a planned change.
After publishing, verify it from the command line with dig:
DNS changes usually appear within minutes, but can take up to 48 hours to fully propagate.
Cloudflare-proxied CNAMEs look hidden. If a CNAME is proxied through Cloudflare (the orange-cloud toggle), a public dig returns Cloudflare's IP addresses, not the CNAME target, because Cloudflare answers on your behalf at the edge. The CNAME is still there in your zone; it just is not visible externally. Turn the proxy off (grey cloud) when you need the raw CNAME to be resolvable, which matters for DKIM and MTA-STS delegation.
Common CNAME mistakes
Almost every broken CNAME traces back to one of these.
A CNAME at the zone apex
You cannot CNAME example.com itself. Use your DNS host's ALIAS, ANAME, or CNAME flattening at the apex instead.
A CNAME alongside MX or TXT at the same name
RFC 1034 forbids it. If a name has a CNAME, it cannot also hold MX, TXT, or A records. Put those records on the canonical target, or drop the CNAME.
Trailing-dot and relative-name errors
In a zone file, shops.myplatform.com without a trailing dot can be read as shops.myplatform.com.example.com. Use the fully-qualified target with the trailing dot, or follow your panel's exact format.
A dangling CNAME after you cancel a service
A CNAME pointing at a decommissioned target invites a subdomain takeover. Remove the CNAME when you remove the service it points to.
A DKIM selector CNAME pointing at the wrong tenant value
Microsoft 365 DKIM breaks if the selector CNAMEs point at a stale or wrong onmicrosoft.com value. Pull the current values with Get-DkimSigningConfig and see DKIM failures troubleshooting.
Expecting a CNAME to also handle email
A CNAME does not carry MX. Mail for the alias is governed by the MX records on the canonical target, not the alias. Plan your mail routing on the real host.
Want to see the records on a domain right now? Run a free DNS and DMARC check to inspect what is published, or build a DMARC record with our generator once your authentication records are in place.
Frequently asked questions
What is a CNAME record?
A CNAME (Canonical Name) record is a DNS record that makes one domain name an alias for another domain name. Instead of pointing to an IP address the way an A record does, a CNAME points to a second name, and the resolver then looks up the real records (A, AAAA, MX, and so on) on that target name. CNAME records are defined in RFC 1034 Section 3.6.2.
What does CNAME stand for?
CNAME stands for Canonical Name. The canonical name is the real, primary name of a host; the CNAME record makes a second name an alias that resolves to it. RFC 1034 Section 3.6.2 is titled "Aliases and canonical names" and defines this behavior.
What is the difference between a CNAME and an A record?
An A record maps a name directly to an IPv4 address (and an AAAA record maps to an IPv6 address). A CNAME record maps a name to another name, not to an IP. When a resolver follows a CNAME, it then looks up the address records on the target. Use an A record for the canonical host; use a CNAME when you want one name to track another name.
Can I use a CNAME at the root domain?
No. The zone apex (the root of the domain, like example.com with no subdomain) must hold SOA and NS records, and RFC 1034 Section 3.6.2 says a name with a CNAME cannot hold any other data. A CNAME at the apex would conflict with the required SOA and NS records. Providers work around this with vendor pseudo-records such as ALIAS, ANAME, or Cloudflare's CNAME flattening, which are not part of the DNS standard.
Why can't a CNAME coexist with other records?
RFC 1034 Section 3.6.2 states: "If a CNAME RR is present at a node, no other data should be present." The reason is consistency: a resolver that caches the CNAME can use it for any record type without re-checking, so the data for a canonical name and its alias can never disagree. The one narrow exception is DNSSEC. RFC 2181 Section 10.1 permits SIG, NXT, and KEY records alongside a CNAME, and nothing else.
Why does my email provider need a CNAME?
Most CNAMEs people add today are for email authentication. A CNAME lets a provider manage a record on your behalf, so they can rotate a key or update a policy without you editing DNS again. Microsoft 365 uses two CNAMEs for DKIM, and DMARCTrust hosts your MTA-STS policy behind a single CNAME. The provider controls the target; you only publish the alias once.
Does DKIM require a CNAME?
No, this is provider-specific. Microsoft 365, SendGrid, Mailgun, and Amazon SES typically use CNAME records for DKIM so they can rotate keys for you. Google Workspace publishes DKIM as a TXT record, not a CNAME. So the common claim that "DKIM needs a CNAME" is false in general. Always follow the exact record type your sending platform tells you to use.
What is a dangling CNAME?
A dangling CNAME is a CNAME that points to a target name that no longer exists or is no longer controlled by you, for example a deleted cloud service. RFC 1034 Section 5.2.2 says aliases that point to non-existent names should be caught as errors. Danglers are a security risk: if an attacker can claim the abandoned target, they can serve content under your subdomain, which is called a subdomain takeover. Remove CNAMEs as soon as you decommission the service they point to.
Related guides and resources
Standards and specifications
- RFC 1034 - Domain Names, Concepts and Facilities (defines CNAME in Section 3.6.2)
- RFC 1035 - Domain Names, Implementation and Specification
- RFC 2181 - Clarifications to the DNS Specification (CNAME and DNSSEC, Section 10.1)
- RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
Tools
- DMARC checker - inspect the DNS and authentication records on any domain
- DMARC record generator - build your DMARC TXT record step by step
- Hosted MTA-STS - serve your policy behind a single CNAME