E-mails are bouncing because the domain needs to have DKIM certification. I was given TXT and the IP to enter from Bluehost but it hasn’t fixed the issue.
I’m getting this message: This hostname is not covered by a certificate. To ensure full coverage, purchase [Advanced Certificate Manager] to use Total TLS for full certificate coverage of proxied hostnames.
Do I have to purchase something to get the certification??
That sounds like either something on Bluehost’s side, such as e.g. the DKIM signing hasn’t been (properly) enabled on their end.
Or alternatively, that the TXT records aren’t a (100%) match to the ones they provided, for example a copy-paste failure.
“The IP to enter”, as you mention, does however sound strange? DKIM does not have anything to do with IP addresses. (Did you mean SPF?).
Can you elaborate on what exactly they told you, what you did, and so forth?
DKIM have absolutely nothing to do with HTTP(S) traffic that Universal SSL and Total TLS provides certificates for, so the warning you see there makes absolutely no sense in this specific situation.
Simply ignore that warning, it has nothing to do with DKIM (and email traffic).
That one is because you have the domain and www set to Proxied (
), in order to make that warning go away from Bluehost, you need to switch to Unproxied (
) / DNS-only.
Unproxied () / DNS-only would however mean that Cloudflare and all it’s functions are being disabled, essentially making Cloudflare only be a DNS provider for your domain.
Did you add, modify or delete any records since this screenshot was taken?
Thanks so much for your quick replies! I didn’t do anything to the records since the screenshot.
Regarding Cloudflare only being the DNS provider, I didn’t set this up so didn’t even know Cloudflare was involved until the e-mail situation. Would making it DNS-only help fix the problem? Perhaps that’s how it was before I set all of this up the other day.
After messaging Bluehost again, they said to make this mod to the domain key:
Type : TXT
Host : _.domainkey
Value : v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDf3sZ5sN7kWme75lKvsm/yK52EpI5nJ3U1fZrikz8gHW+ocqJiD55GAwGDTGRIZLntlkHbdhUUu0bOYovA97zVDucK0W2vt/Exz6pXVyuJ7erlbQnDdePx7Ik+/69m0EP2pTDx3trH/VTCHrxXq7FVs9ifzl22R48LpOAka5LIZQIDAQAB
Fingers crossed.
The 1st person said to have it blank, then I believe someone at Cloudflare said to add this: rua=mailto:[email protected]
I just deleted it to see if that was the problem
Blank after “v=DMARC1; p=none;” I mean
The rua is the destination where DMARC aggregate reports will be sent. Leaving it blank means that you won’t see the reports. It has no effect on the disposition of your email. While leaving it blank is not ideal, it can be done. Whatever you set it to, do not use a personal mailbox. The rua has the potential to receive a high volume of automated email.
Okay, thank you. I’m in the middle of figuring that process out (wish me luck). In the meantime, could that be the reason for the e-mails still not going through?
Your DKIM record is not present in your DNS. You can use the dmarcian DKIM Inspector to test your DKIM records. I can see where things went wrong in an earlier reply.
That should be Host: default._domainkey
The word or string to the left of the ._domainkey is known as the selector. The selector is used to identify the key that was used to sign the message. This is particularly important if you have more than one source of email each using their own key to sign your messages. It is also makes it easy to allow for an overlap during key rotation. I mention it not only for educational purposes, but also so that you know what goes in the dmarcian DKIM Inspector. 
Try updating your hostname as indicated. Once you check it with the dmarcian DKIM Inspector, let us know what you see.
That’s funny…when I contacted Bluehost again today, they said to change it from that original suggestion to “_.domainkey”! I’ll change it back and hope it works. If it doesn’t, I’ll be back tomorrow! Thank you again for your help…this is a tough task for a small, small business owner. No idea how others deal with it!
They outsource to people like me who make it look easy. 
You can lose the a and the ptr in your SPF. With your domain proxied, it will resolve to a Cloudflare IP that will never send email. That renders a useless. The ptr mechanism is also expensive and inefficient. The dmarcian SPF syntax article covers that in a little more detail.
Ending with ?all makes your record considerably less effective. It upgrades any failure to a neutral. Ideally you want to end your SPF record with -all so that servers know that mail from unauthorized sources is not legitimate.
Sorry for the delay.
Proxying or Unproxying the two records as mentioned wouldn’t make a change in regards to email delivery, but solely to “fix” the Bluehost warning.
The reason I asked was because I do not see the default._domainkey nor the _dmarc record being exposed in the DNS system.
I did not see it back then, and I do still not see them exposed:
$ dig TXT default._domainkey.catalystbjj.com @kiki.ns.cloudflare.com
; <<>> DiG 9.16.37-Debian <<>> TXT default._domainkey.catalystbjj.com @kiki.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60205
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;default._domainkey.catalystbjj.com. IN TXT
;; AUTHORITY SECTION:
catalystbjj.com. 3600 IN SOA kiki.ns.cloudflare.com. dns.cloudflare.com. 2309858824 10000 2400 604800 3600
;; Query time: 40 msec
;; SERVER: 2606:4700:50::adf5:3ab4#53(2606:4700:50::adf5:3ab4)
;; WHEN: Thu Jun 15 02:32:29 CEST 2023
;; MSG SIZE rcvd: 122
$ dig TXT _domainkey.catalystbjj.com @kiki.ns.cloudflare.com
; <<>> DiG 9.16.37-Debian <<>> TXT _domainkey.catalystbjj.com @kiki.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61257
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_domainkey.catalystbjj.com. IN TXT
;; AUTHORITY SECTION:
catalystbjj.com. 3600 IN SOA kiki.ns.cloudflare.com. dns.cloudflare.com. 2309858824 10000 2400 604800 3600
;; Query time: 44 msec
;; SERVER: 2606:4700:50::adf5:3ab4#53(2606:4700:50::adf5:3ab4)
;; WHEN: Thu Jun 15 02:32:36 CEST 2023
;; MSG SIZE rcvd: 114
$ dig TXT _dmarc.catalystbjj.com @kiki.ns.cloudflare.com
; <<>> DiG 9.16.37-Debian <<>> TXT _dmarc.catalystbjj.com @kiki.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42933
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dmarc.catalystbjj.com. IN TXT
;; AUTHORITY SECTION:
catalystbjj.com. 3600 IN SOA kiki.ns.cloudflare.com. dns.cloudflare.com. 2309858824 10000 2400 604800 3600
;; Query time: 44 msec
;; SERVER: 2606:4700:50::adf5:3ab4#53(2606:4700:50::adf5:3ab4)
;; WHEN: Thu Jun 15 02:32:44 CEST 2023
;; MSG SIZE rcvd: 110
$
They all return code 3 (NXDOMAIN), indicating that they do not exist.
… which does not look consistent to what the Cloudflare Dashboard says? So that could somehow indicate a failed synchronization of the DNS records somewhere.
Adding a such record alone on “_domainkey”, without anything in front of it would make no sense at all.
While that is in theory technically valid, I would extend it and call it meaningless.
DMARC is supposed to be able to provide you reports about your mail delivery, so you have the option to move to stronger policy (e.g. quarantine, reject, …).
The “none” policy has also been referred to as “monitor mode”, but literally, how on earth can you have enabled “monitor mode”, if you do not set a destination set for the reports?
I could be tempted to say that having a such _dmarc record set, would somehow imply “the operator of this domain may not know what they are doing, do we really want to accept their mail?”.
The “?all” for the SPF policy, would likewise count as meaningless.
I would personally throw away the “a” and “mx” mechanisms though.
As mentioned above (dig outputs, …), I’m starting to worry if that part might require some deeper escalation.