Zoho books is not finding my SPF record and this is causing deliverability issues. Invoices go to spam.
DKIM records were found no problem but the SPF is not working. I contacted Zoho support and they said it may be a gray vs orange cloudflare account issue? I believe they may be referring to proxy status but they have not yet answered that.
SPF record is as follows: “v=spf1 include:zohocloud.ca include:sender.zohobooks.ca ~all”
The mentioned SPF record here is the exact one as appearing when querying your domain for the TXT records.
This one would only be relevant for traffic to your website, not for email traffic.
If you do not intend to have a website on your domain, you can ignore that one.
The TXT (v=spf1...) is correct for the apex / naked domain / root domain, and works fine for your domain from multiple locations worldwide.
However, I’m wondering, did you actually configure the set up on Zoho using the naked domain?
Or did you configure it with a sub-domain, like invoices.example.com or billing.example.com on Zoho’s end?
If the latter, with e.g. invoices.example.com/billing.example.com, then you would need to add the TXTSPF record on the actual sub-domain (e.g. invoices.example.com/billing.example.com), and not just on the naked domain.
I do not have any subdomains set up. The Books account is set up under the main organization account, which uses the apex domain. The email account for the organization works, but there seems to be an issue somehow coming down the line.
Email was first to be set up, and works fine.
Books was next and now has this issue with SPF record not being found.
Then Inventory, which says “Unable to Fetch DKIM record Details” and won’t even let me get into the page to validate the domain.
If it is not configured with a subdomain, and is just using the root domain, does it seem like the issue is more likely somewhere on the Zoho side than on the Cloudflare side?
Here are the two records that I have with name “_domainkey”.
The Zoho one is actually not the one that they asked me to put, they asked for “Zoho DKIM._domainkey”, but Cloudflare would not take that so I changed it to what it is now. I do not think it is working properly though.
I think you are right about their validator, though. I have spoken with them and they agree it should be reflected in my account, but it is not working. They have someone looking at it now.
I am seeing a technically valid RSA 2048 bit public key on both of these “_domainkey” records.
Technically valid isn’t the same as being valid for your purpose though:
To also be valid for your purpose, the long “p=” is needs to be a match both in your DNS, as well as on e.g. Zoho’s end in this case.
“Zoho DKIM”, … with an actual space between “Zoho” and “DKIM”?
If so, that would be strange, as you cannot have spaces in (sub-)domain names like that.
Sounds like we need to wait for them to step in.
It is (and has been) very common with e.g. throw away domains to deliver spam, so from time to time, it gives very give good / effective results with filtering recently registered domains away.
I would generally not be expecting any positive outcome from delivering from a domain that is less than a minimum of 60 - 90 days old.
By digging in to spam myself, I have seen a lot of examples where it could seem to make sense to refuse, or even flag deliveries from domains as suspicious, during their first (and likely cheapest) year of registration.
In fact, I have seen one of these domain health / email health checkers out there, that are alerting you about your domain’s age, even when the age of you domain registration is with three digits (e.g. 100+ days).
From 2023-11-18 (your domain’s registration date) to 2023-12-26 (the date of your initial post here), that is just a little over one month.
The age of your domain registration could possibly be playing a role in the spam folder decision here, even when and if all other things (e.g. DKIM) actually works perfectly.