Moving a domain’s DNS to Cloudflare can break email authentication if required CNAME records are not recreated in the new DNS zone. In one support case, a third-party email platform reported that its sender-authentication connection had been severed after Cloudflare was introduced.
The original instructions told the site owner to add the records in GoDaddy, but DNS was now managed in Cloudflare. The developer also found an older SendGrid authentication set in the DNS backup, but the new request referenced a different mail host. Rather than guessing that the old targets were still valid, the team requested the complete new host-and-target values from the email provider, added those CNAME records in Cloudflare, and completed the reconnection.
Issue background
A WordPress site had recently moved its DNS management to Cloudflare. Shortly afterward, a third-party email service reported that its domain-authentication connection was no longer valid.
The provider asked for three CNAME records with hostnames similar to:
s1._domainkey
s2._domainkey
em9014The instructions said to add them in GoDaddy. That advice no longer matched the site’s actual DNS architecture because authoritative DNS had already moved to Cloudflare.
The site owner was not familiar with DNS management, so the task required both identifying the correct DNS provider and making sure the exact CNAME targets were known before any records were changed.
Diagnosis
The developer reviewed the available DNS backup and found an older SendGrid authentication configuration:
em232 → u14169873.wl124.sendgrid.net
s1._domainkey → s1.domainkey.u14169873.wl124.sendgrid.net
s2._domainkey → s2.domainkey.u14169873.wl124.sendgrid.netThose records were useful as historical context, but they were not sufficient to recreate the new authentication setup.
The provider’s new instructions referenced em9014 instead of the previous em232. That strongly suggested that a new sender identity or SendGrid domain-authentication set had been created.
Because of that change, the old target values could not safely be assumed to apply to the new records.
The task initially included only the host portions of the requested CNAME records, not the destination targets. A valid CNAME requires both pieces:
- The hostname or record name.
- The destination or target hostname.
The developer therefore paused the DNS change and requested the full records from the email provider rather than guessing.
Resolution steps
The documented fix was:
- Confirm where authoritative DNS is managed. Even though the domain was registered or historically managed through GoDaddy, the active DNS zone was now in Cloudflare.
- Review the previous sender-authentication records. The developer checked the DNS backup and found the older SendGrid CNAME set.
- Compare the old and new hostnames. The previous mail host used
em232, while the new request usedem9014. - Do not reuse old CNAME targets automatically. A changed mail host can indicate a completely new sender-authentication configuration, so the historical targets may no longer be valid.
- Request the complete DNS records. The team asked the email provider to supply the full host-and-target pairs for
em9014,s1._domainkey, ands2._domainkey. - Add the new CNAME records in Cloudflare. Once the complete values were received, the developer added the requested records to the active Cloudflare DNS zone.
- Return the setup to the email provider for refresh or verification. With the records in place, the provider could recheck the domain-authentication connection.
The source task does not reproduce the final destination values in text because they were supplied through an attached image. For that reason, those targets are intentionally not invented here. In any similar setup, use the exact CNAME targets generated by the current SendGrid or email-platform authentication configuration.
Final outcome
The required email-authentication CNAME records were added to Cloudflare using the complete values provided by the email service, and the task was marked complete.
The key troubleshooting decision was recognizing that the old SendGrid records were historical evidence rather than a safe template for the new configuration. The change from em232 to em9014 indicated that the provider’s sender-authentication setup had changed, so the new target values had to be obtained before updating DNS.
The broader lesson is that moving DNS to Cloudflare changes where future DNS updates must be made, even if the domain is still registered at GoDaddy. When an email provider asks for DKIM or sender-authentication CNAMEs, confirm the authoritative DNS provider first and always use the current host-and-target values generated by that email platform.
If your email authentication breaks after moving DNS to Cloudflare or you need help restoring SendGrid CNAME records, contact Freshy. Our WordPress team can verify the active DNS zone, compare historical records safely, and restore the current authentication records without guessing at outdated values.
