Unable to proxy CNAME entries anymore?

We’ve had a Cloudflare account for years and starting around Thursday of last week we have been unable to turn the orange cloud on for CNAME entries anymore with “sendgrid(dot)net” as the contents. The option for proxy exists when creating a new CNAME entry but attempting to save with the orange cloud on yields the error:

This kind of record cannot be proxied (Code: 9004)

Note if the CNAME entry contains anything other than “sendgrid.net”, I can proxy and I can get the orange cloud to work. After saving non-proxy attempting to change to orange cloud with “sendgrid.net” doesn’t have the option; the entry just says DNS Only.

What am I missing?? URLs being clicked from emails sent to customers are all being greeted with the HTTPS security warning. Entering page rules to force SSL are not working because, obviously, we’re not proxied.

That sounds new, but I know people were having problems with Sendgrid CNAMEs set to :orange: when they should have been set to :grey: for validation.

If you’re using one of their custom content features, this may be an unintended consequence. I suggest you open a ticket here and ask about restoring that capability.

To contact Cloudflare Customer Support, login & go to https://dash.cloudflare.com/?account=support and select get more help. If you receive an automatic response that does not help you, please reply and indicate you need more help.

@sdayman and @daniel47, we have the same issue.

Here’s our setup:
Kubernetes on AWS, Cloudflare proxy enabled for the CNAME record pointing to the k8s load balancer.
SendGrid, presently, configured without Cloudflare proxy - this is their automated CNAME record e.g. urlXXXX.domain pointing to sendgrid.net
Up until a couple days ago, we were unable to turn on Cloudflare’s proxy.
Now, we are able to do so - BUT this causes a separate issue which I presume is why you disabled the option in the first place (see below).

A couple days ago, IE11 users (primarily) and mobile Chrome users, started seeing “Blocked Request: Unable to verify certificate” and “ERR_CERT_COMMON_NAME_INVALID” errors when trying to connect using these links.

My feeling is that a recent change forces the non-HTTPS SendGrid links to be converted to HTTPS, which is causing the issue as SendGrid does not auto-provision a custom SSL for their customer’s domain.

Now that we can enable Proxying of the CNAME record again, if we do that, the Whitelabelled link verification fails on Sendgrid (dig doesn’t resolve the record as sendgrid dot net even though it technically does end up there).

And that causes links in our transactional emails to fall back to sendgrid.net domain links, not our domain’s.

They say this (enabling HTTPS links on their side, and therefore provisioning a certificate) can be done “upon request to support after enabling Full SSL and the Proxy on Cloudflare” but 1) they don’t reply and 2) why would they ask that Full SSL and the Cloudflare proxy be enabled on the CNAME record?

This leaves us with:

  1. Either Certificate failures if we do not enable the Cloudflare proxy, or,
  2. Non-whitelabelled links from “our domain” if we enable the proxy.

Is there a way to set something up on Cloudflare, after enabling Full SSL and the Proxy, for the CNAME verification to succeed on SendGrid’s side?

I’m surprised that in Daniel’s case however initially having the proxy enabled means you would still get domain-branded links, as presumably SendGrid’s verification would fail, unless you emailed them and they enabled SSL?

I think Cloudflare team had made a system-wide mistake. As of this writing my orange clouds are back for sendgrid.net entries. The domainkey entries are as of this writing NOT proxiable (which is correct, as the verfiication would fail) - I think perhaps they had an over-reaching rule to disable proxy for all sendgrid.net entries instead of specific ones.

This is now resolved.

Georgios, for your case, I used to have the same problem. SSL needs to be set to full. If you can’t do full, create a page rule for the specific urlXXXX value then force to “full” for the SSL entry.

I’m new to Cloudflare DNS, but may have a similar issue. We use Microsoft 365 for email. I switched DNS within the last month. Starting around Sunday 10/25/2020, emails to sites that do DKIM analysis begain to fail. Lookups to selector2._domainkey.OurRealDomain.com were no longer providing the TXT info that contains our DKIM public key. On Cloudflare DNS, selector2._domainkey.OurRealDomain.com
is a CNAME for _domainkey.OurTennant.onmicrosoft.com

Now that I am reading you’ve been a Cloudflare user for years and started having trouble recently, I don’t know if 1) it never worked for us and mail worked until the TTL ran out, or 2) it broke on Thursday like yours and we just didn’t notice…

There are no grey cloud / orange cloud choices for the selector2._domainkey. CNAME record. Is that as expected?

Longer description of the problem here: