What is a CNAME record? DNS alias records explained

What are the requirements?

The controlling specification is RFC 1034, Domain Names - Concepts and Facilities, an IETF Internet Standard. RFC 2181, Clarifications to the DNS Specification, clarifies the CNAME coexistence rule. These RFCs define DNS behavior. A mail provider can still impose its own setup instructions for a particular service.

A CNAME points to another hostname

A CNAME record identifies its owner name as an alias for the canonical name in the record data. The target is a DNS name, not an IPv4 or IPv6 address.

; Illustrative only. Publish the exact owner and target supplied for your domain.
selector1._domainkey.yourdomain.com. 300 IN CNAME selector1.provider.example.

Do not publish example hostnames in a production zone. Your email provider generates the actual owner name and target for its service.

A resolver that receives this CNAME continues resolution at selector1.provider.example. The final response may contain an A record, AAAA record, TXT record, or another record type appropriate to the original query. A CNAME does not copy the target's records into your zone. It delegates name resolution for that alias.

A CNAME owner must not have other data

RFC 1034 section 3.6.2 says that if a CNAME resource record is present at a node, no other data should be present. RFC 2181 section 10.1 makes the operational consequence explicit: an alias must have no other data.

That means this is invalid at one owner name:

mail.yourdomain.com. 300 IN CNAME mail.provider.example.
mail.yourdomain.com. 300 IN TXT "some text"

Put the TXT record at a different hostname, or use the record design supplied by the provider. Do not add an SPF, DMARC, MX, or verification TXT record beside a CNAME just because a DNS control panel permits the entry. Authoritative DNS behavior and resolver handling can become inconsistent when a name violates the rule.

An SMTP MX target must not be a CNAME

An MX record names the host that accepts mail for a domain, and you can look up a domain's MX records to see the exact hostnames it publishes. RFC 5321 section 5.1 says that the domain name in an MX record must not be a CNAME. The mail exchanger hostname must resolve directly to an address record.

; Illustrative only.
yourdomain.com. 300 IN MX 10 mx1.yourdomain.com.
mx1.yourdomain.com. 300 IN A 192.0.2.25

Do not use this pattern:

; Invalid MX target pattern.
yourdomain.com. 300 IN MX 10 mx1.yourdomain.com.
mx1.yourdomain.com. 300 IN CNAME mail.provider.example.

SMTP senders can treat an MX target that resolves through a CNAME as an error. This rule applies to the MX target, not to every hostname involved in email services. A DKIM selector or web tracking hostname may legitimately be a CNAME when the provider's instructions call for one.

CNAME chains are DNS dependencies

DNS permits a canonical name to lead to another alias, but each extra lookup adds another dependency. RFC 1034 describes following aliases while resolving a query, with protections against loops.

Keep provider-created chains intact unless the provider documents a replacement. For names you control, prefer a short chain. A long chain can make DNS failures harder to isolate and can exceed resolver limits in some implementations.

When does the requirement take effect?

There is no future enforcement date for CNAME behavior. The rules apply whenever an authoritative DNS zone publishes a CNAME record or an SMTP sender resolves an MX target.

RFC 1034 was published in November 1987 as an Internet Standard. RFC 2181 was published in July 1997 to clarify DNS behavior, including the rule that an alias cannot coexist with other data. RFC 2181 clarifies the CNAME rule rather than creating a vendor rollout date.

For email routing, RFC 5321 is the controlling SMTP specification for MX handling. Its prohibition on an MX target that is a CNAME applies to SMTP implementations, regardless of whether a DNS interface accepts the record.

How do I implement the requirement?

1. Identify the exact hostname the provider gave you

Copy the record owner name and target from the provider's current DNS instructions. Confirm whether the request is for a CNAME, TXT, MX, or another type before editing the zone.

A DKIM-related request often uses a hostname below _domainkey. It is separate from the root domain's DMARC hostname, _dmarc.yourdomain.com, which normally publishes a TXT record.

2. Check for existing records at the alias hostname

Before adding the CNAME, inspect every record at that exact owner name. Remove or relocate conflicting records only after confirming what system depends on them.

Replacing an existing MX, TXT, or address record with a CNAME can interrupt mail routing, domain verification, or an application endpoint. Record the current values and confirm the intended change with the service owner before publishing it.

3. Publish the target exactly as supplied

Use a fully qualified hostname target. Do not substitute an IP address, alter a provider-managed target, or add a CNAME at the domain apex as a workaround.

The target may be outside your domain. That is normal for a vendor-managed DKIM delegation or branded sending hostname. The important DNS question is whether the target resolves as the provider expects.

4. Allow cached DNS data to expire

Resolvers can keep an older response until its TTL expires. Check the authoritative zone first, then query public resolvers after the change has propagated through their caches.

If a provider has a verification screen, check that status separately. A successful DNS lookup shows the record is publicly resolvable. It does not prove the provider has accepted it or that the production sending path uses it.

How do I validate compliance?

Start with the record itself. Query the alias hostname and confirm that the response is a CNAME with the intended target. Then query the target to see whether it resolves to the record type needed by the service.

Use Palisade's DNS lookup tool to inspect the published CNAME and its public resolution path. Compare the result with the provider's exact DNS instructions.

For an email authentication CNAME, validate all applicable layers:

• DNS: confirm the authoritative zone and at least one public resolver return the expected CNAME target.
• Vendor: confirm the sending provider reports the domain or selector as verified, if it offers a verification status.
• Message: send a real message through the production path and inspect its raw headers. Confirm the expected DKIM result and identifier appear in Authentication-Results.
• DMARC: after reports accumulate, review aggregate-report data to identify whether the production sources authenticate and align as expected.

Inspect the CNAME before relying on it for email setup

A CNAME lookup is the right next check when you have a hostname and need to confirm its public alias target. It can reveal a typo, a missing target, or a conflicting record before you treat provider setup as complete.

Inspect the CNAME target

A public DNS lookup cannot prove which production sending sources still fail DKIM or DMARC alignment. Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step from the evidence, while a human reviews the evidence and applies the change.

Start with Palisade

Palisade does not change your DMARC policy automatically, repair every sender, or guarantee future authentication or inbox placement.