As people who’ve read my previous post would know, I recently started using Purelymail for my email needs (the how and why of it can be found here). I also mentioned there, that Cloudflare’s proxy-by-default nature caused Purelymail to not detect my CNAME settings and disabling the proxy did the job. I contacted Purelymail’s Scott about this and he eventually pushed a fix out that *should* have fixed it, but since he did not have a Cloudflare account, he couldn’t verify this exact case.

Well, the fix didn’t work.

This made me wonder, why? I trust that Scott is more aware of what he’s doing than I am so the fix must have been legitimate and that something is special about Cloudflare’s handling of this. So I did some testing! (yes I still use dnscontrol)

diff --git a/dnsconfig.js b/dnsconfig.js
index f5fd1836f8ec..a53bab70de84 100644
--- a/dnsconfig.js
+++ b/dnsconfig.js
@@ -24,6 +24,8 @@ var DEV_RECORDS = [
     CNAME('purelymail2._domainkey', '', CF_PROXY_OFF),
     CNAME('purelymail3._domainkey', '', CF_PROXY_OFF),
     CNAME('status', '', CF_PROXY_OFF),
+    CNAME('test_domain_no_proxy', '', CF_PROXY_OFF),
+    CNAME('test_domain_with_proxy', ''),
     MX('@', 50, ''),
     TXT('@', 'v=spf1 ~all'),
     TXT('@', 'purelymail_ownership_proof=0xd34db33f'),

Running dig on both the subdomains, I spotted something interesting.

$ dig @
;; ANSWER SECTION: 289	IN CNAME	3589	IN	A	3589	IN	A	3589	IN	A	3589	IN	A
$ dig @

The proxied CNAME record isn’t actually a CNAME after all! Cloudflare creates an A record for it and handles the redirection internally. This makes the CNAME aspect of the record opaque to DNS lookups which in turn trips software like Purelymail’s backend. I’ve reported my findings to Scott and am awaiting his response.

And that’s it! Nothing too fancy, just something I found kinda weird.