CNAME vs A record: what's the difference?

What are the requirements?

An A record contains an IPv4 address

RFC 1034 defines an A record as an address record with a 32-bit Internet address. Operationally, it gives a resolver an IPv4 address for the name it queried.

; Illustrative only. Replace with values for your own domain and service.
app.yourdomain.com. IN A 192.0.2.25

The value in an A record is an IP address, not another hostname. An A record can coexist with other record types at the same owner name unless another record's rule prevents it.

A CNAME record identifies a canonical hostname

RFC 1034 defines a CNAME record as a canonical name for an alias. If a resolver receives a CNAME while requesting another record type, it restarts the query using the canonical target.

; Illustrative only. Do not publish another service's target hostname.
www.yourdomain.com. IN CNAME app.provider.example.

The trailing dot is zone-file notation for a fully qualified domain name. DNS control panels often add it automatically. Follow the DNS provider's input format, but copy the hostname supplied by the service exactly.

A CNAME can let a provider change the target hostname's A or AAAA records without requiring you to edit the alias. It does not mean the alias itself has a fixed IP address.

A CNAME owner name cannot hold other DNS data

RFC 2181 section 10.1 states: "If a CNAME RR is present at a node, no other data should be present".

A DNS name used as a CNAME therefore cannot also publish an A, AAAA, MX, TXT, or other record at that same name. This is a DNS rule, not a registrar preference.

The zone apex, such as yourdomain.com, normally cannot be a standard CNAME because it must contain SOA and NS records. Use an address record, a redirect, or a documented provider-specific apex feature instead.

MX and NS targets must not be aliases

RFC 2181 section 10.3 states: "The domain name used as the value of a NS or MX record must not be an alias."

; Illustrative only.
yourdomain.com. IN MX 10 mail.provider.example.
mail.provider.example. IN A 192.0.2.50

Do not replace a mail provider's MX target with a CNAME to make DNS records look consistent. The MX target is part of the production mail-routing path.

This rule concerns the hostname named in the MX or NS record's value. It does not prevent a separate DKIM selector from using a CNAME when an email provider directs you to publish one. See what a DKIM CNAME record is and how to set it up.

When does the requirement take effect?

RFC 1034 was published in November 1987. RFC 2181 was published in July 1997 and clarifies CNAME exclusivity plus the prohibition on alias targets for MX and NS records.

There is no rollout date or sender-volume threshold. These are DNS protocol rules whenever you publish the records. Provider-specific features such as CNAME flattening have their own current behavior, limits, and cache handling, so the provider's documentation controls those implementation details.

How do I implement the requirement?

1. Identify the exact hostname and supplied value

Start with the owner name that needs a record. Publish an A record if you have an IPv4 address. Publish a CNAME only when the service gives you a target hostname.

Do not derive a target from another account, a similar domain, or an old setup guide. Obtain the current value from the service that owns the destination.

2. Inspect records already published at that name

Before creating a CNAME, inspect all records at the same owner name. A CNAME cannot coexist there with a TXT verification record, an A record, an MX record, or another record type.

This is especially relevant for email authentication. A provider might assign a name such as selector1._domainkey.yourdomain.com for DKIM. That selector can be a CNAME, but only if it does not also need other DNS data.

3. Keep the zone apex separate

Do not publish a standard CNAME at the zone apex. If a website provider requires apex routing, use the provider's documented approach and record that dependency for the next DNS administrator.

A provider-specific alias feature may behave differently after a DNS migration. Treat it as implementation guidance, not as evidence that standard CNAME rules no longer apply.

4. Preserve mail-routing targets

Copy MX records exactly as the receiving mail provider specifies. If you control the target zone, verify that each MX target is a real host name with address records rather than a CNAME alias.

A DKIM CNAME at a selector is separate from the MX requirement. One does not justify changing the other.

5. Publish the change and allow caching to expire

Publish one focused DNS change, then allow for the configured TTL and resolver caching. Avoid combining an alias conversion with unrelated SPF, DMARC, or MX changes. Separate changes give you clearer evidence if delivery or verification later fails.

How do I validate compliance?

Use a DNS lookup to inspect the public answer for the exact hostname. For an A record, compare the returned IPv4 address with the intended service address. For a CNAME, compare the returned canonical target with the provider-supplied hostname and verify that the alias owner name has no other data.

For a mail-routing change, inspect every MX target and verify it is not an alias. Then validate at four layers where email is affected:

• DNS: Query the authoritative DNS provider and at least one public resolver after the expected cache period.
• Vendor: Check the provider's current verification status if it offers one.
• Message: Send a real message through the affected production path and inspect the delivered headers.
• DMARC: Review aggregate-report data after it accumulates to identify sources or alignment issues that DNS answers alone cannot show.

Inspect the published DNS record, then track the mail path

Check the exact hostname before changing records or asking a provider to reverify the domain.

Check the DNS record

A DNS lookup can show the public A or CNAME answer for the name you enter. It cannot prove which production senders use the domain, monitor later DNS drift, or confirm future inbox placement.

For domains with ongoing DMARC aggregate-report data, Palisade is DMARC software that analyzes reporting data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or DMARC policy change.

Start with Palisade