Skip to content
More support
Open Ticket
  • There are no suggestions because the search field is empty.

How Do Wildcard CNAME Records Work and Do They Affect SPF or DKIM Records?

When setting up email authentication records like SPF and DKIM, DNS configuration plays a crucial role. One often overlooked aspect is the use of wildcard CNAME records (e.g., *.example.com) and how they might interact with email authentication mechanisms.

In this article, we will explain what wildcard CNAME records are, how they work, and whether they impact SPF or DKIM validation. 

What Is a Wildcard CNAME Record?

A wildcard CNAME record is a DNS record that automatically maps any subdomain that hasn’t been explicitly created to a specified target domain.

For example:

*.example.com    CNAME    anotherdomain.com


With this configuration:

  • random.example.com → points to anotherdomain.com

  • mail.example.com → points to anotherdomain.com (only if you don’t have an explicit mail.example.com record)

  • Any undefined subdomain (including _domainkey DKIM selectors) will also resolve to anotherdomain.com

So, if you haven’t explicitly set records for:

  • kl._domainkey.example.com

  • s1._domainkey.example.com

They will inherit the wildcard and also point to anotherdomain.com.

Do Wildcard CNAME Records Affect SPF?

How SPF Works

SPF (Sender Policy Framework) uses a TXT record published on the domain or subdomain to specify which mail servers are allowed to send emails on behalf of your domain.
For example:

example.com       TXT      "v=spf1 include:_spf.google.com ~all"


SPF lookups for a domain query only that specific domain and not other subdomains unless explicitly used.

Impact of a Wildcard CNAME

  • SPF validation happens on the envelope domain used in the email’s "MAIL FROM" or "Return-Path."

  • If the SPF check is for example.com, the wildcard *.example.com has no effect.

  • However, if your SPF includes a subdomain and that subdomain does not have its own SPF record, a wildcard CNAME can misdirect the SPF lookup to the wrong domain.

✅ SPF Example with a CNAME

If you create:

spf.example.com      CNAME     spf.externalprovider.com


And in your SPF record:

example.com          TXT      "v=spf1 include:spf.example.com ~all"


The receiving mail server will follow the CNAME and resolve spf.externalprovider.com for SPF validation.

⚠️ Problem with Wildcard CNAME

If you have a wildcard:

*.example.com        CNAME     anotherdomain.com


And you don’t explicitly create spf.example.com, then SPF lookups for spf.example.com will resolve to anotherdomain.com.
If anotherdomain.com does not have a valid SPF, this may lead to SPF failures.

Do Wildcard CNAME Records Affect DKIM?

How DKIM Works

DKIM uses a TXT record stored under a selector subdomain in the _domainkey namespace:

For example:

s1._domainkey.example.com      TXT      "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."


The receiving mail server retrieves this public key via DNS to validate the DKIM signature.

Impact of a Wildcard CNAME

If you have a wildcard CNAME such as:

*.example.com       CNAME      anotherdomain.com


and you forget to explicitly create s1._domainkey.example.com, DNS will automatically redirect that query to anotherdomain.com.

If anotherdomain.com does not have a corresponding DKIM key for that selector, DKIM validation will fail.

✅ Correct DKIM CNAME Example

Some email service providers ask you to create CNAMEs for DKIM, like:

s1._domainkey.example.com    CNAME    s1._domainkey.provider.com

s2._domainkey.example.com    CNAME    s2._domainkey.provider.com


In this case, the DKIM lookup will correctly follow the CNAME to the provider’s DKIM record.

⚠️ Risk with Wildcard CNAME

If you rely on a wildcard instead of explicitly creating the DKIM selector records, you risk misdirecting the DKIM query to an unrelated domain, causing DKIM failures.

Wildcard CNAME records (*.example.com) are useful for web services but can unintentionally interfere with email authentication if not carefully managed.