CNAME record and email: why aliases break mail infrastructure

A CNAME record (Canonical Name) maps one domain name to another. Unlike an A record, which points to an IP address, a CNAME says: "this name is an alias — go resolve the target instead." For web hosting, CNAMEs are convenient and widely used. For email infrastructure, they carry restrictions that trip up administrators regularly.

The core problem comes from RFC 1034 and RFC 2181: a CNAME record cannot coexist with any other record type at the same name. Since email delivery depends on MX records at the domain apex, placing a CNAME there breaks mail routing in ways that are not always immediately obvious.

CNAME at the domain apex

If you set a CNAME on example.com pointing to loadbalancer.cdn.com, you cannot simultaneously have MX records at example.com. DNS resolvers that encounter a CNAME are supposed to follow the alias and ignore any other records at that name. In practice, some resolvers return partial results, others return nothing for the MX query. The outcome: mail to user@example.com fails unpredictably.

This is why DNS providers offer "CNAME flattening" or "ALIAS" records. Cloudflare, for instance, resolves the CNAME target at query time and returns an A record to the client. That preserves compatibility with MX, TXT, and other record types at the apex. It is a provider-side workaround, not a standard DNS feature.

CNAME and MX records

MX records must point to a hostname that resolves via an A or AAAA record, not via a CNAME. RFC 2181 section 10.3 explicitly prohibits MX targets from being CNAME aliases. Some MTAs follow the CNAME chain and deliver anyway, but that behavior is not guaranteed.

A typical misconfiguration:

Here, mail.example.com is a CNAME alias. A strict MTA refuses to deliver because the MX target has no direct A record. The fix: replace the CNAME with an A record pointing to the IP of mailserver.provider.com.

Where CNAME is used correctly in email

Despite the restrictions, CNAME is common and correct in email infrastructure — just not at the sender domain apex and not in MX records. The most frequent legitimate use is DKIM setup.

When you connect a domain to an ESP (SendGrid, Mailchimp, Amazon SES), you are typically asked to add CNAME records like:

The CNAME lives on a subdomain (s1._domainkey), not the apex. No conflict with MX. The ESP manages the target record and can rotate DKIM keys without any action on your side.

CNAME and SPF

An SPF record is a TXT record on the sender domain. If a CNAME exists at the same name, a TXT record cannot (CNAME cannot share a name with any other type). SPF stops working entirely in that case.

Inside an SPF record, the include mechanism can reference a domain that has a CNAME. But each CNAME in the resolution chain adds another DNS lookup. SPF enforces a hard limit of 10 DNS lookups per evaluation — long CNAME chains eat into that budget quickly.

CNAME and DMARC

A DMARC record sits as a TXT record at _dmarc.example.com. If _dmarc.example.com is itself a CNAME pointing to _dmarc.provider.com, the DMARC policy gets read from the target domain. RFC 7489 permits this, and most validators follow the CNAME for DMARC without trouble.

The catch: you hand control of your DMARC policy to a third party. If the provider changes the record on their end, your policy changes without your knowledge. For domains where DMARC enforcement matters, keep the record on your own DNS.

Tracking domains and CNAME

ESPs use CNAME for custom tracking domains. Instead of click.sendgrid.net in the message body, the link shows click.example.com. The DNS entry for this looks like:

This helps deliverability: links on your own domain get more trust from spam filters than links on a shared tracking domain, which may have appeared in spam sent by other customers of the same ESP.

Common CNAME mistakes in email

• CNAME at the apex with MX present. The most common case. The domain stops receiving mail because MX records are effectively ignored.
• MX pointing to a CNAME. Formally prohibited by the standards. Delivery depends on the receiving MTA being lenient.
• CNAME on the envelope sender domain. The Return-Path contains a domain that is a CNAME. SPF fails because a TXT record cannot coexist with the CNAME at that name.
• Long CNAME chains. A CNAME points to another CNAME, which points to a third. Each hop is an extra DNS lookup and another potential failure point. Some resolvers cut the chain off after 8 to 10 hops.

CNAME validation and email address checking

When validating an email address, a validator checks the DNS of the recipient domain. If the domain has a CNAME at the apex, the validator follows the alias and looks for MX records on the target domain. If neither the original nor the target has MX records, the address is considered invalid.

Domains with CNAME at the apex are rare among those that actually receive mail. But among marketing domains used only for sending, this configuration shows up — and it creates problems when processing bounces, since the Return-Path domain cannot hold an SPF record alongside the CNAME.