Emails sent from all 3 email addresses I have set up in the Rackspace Cloudways Add-On are ending up in Spam in GMail.
When I "View Original Message" in GMail, I see...
SPF: NEUTRAL with IP 173.203.187.81
DMARC: 'FAIL'
... where 173.203.187.81 is an IP address Rackspace.
My DNS provider is CloudFlare.
There is a DMARC policy set up, which is the following...
_dmarc.boldstatements.com.au v=DMARC1; p=none; ruf=mailto:[email protected]; rua=mailto:[email protected]
Cloudways provided me with this DKIM TXT record...
20220817-maluhsjy._domainkey v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0PqtvPuYkElqS+b80iEj4aepAdf6n+CDXRFTG/1Q8RMdw/D6hNmQpv8FCTyIuplZt/qTxBbBFrPLJK5tp7bqkSEG2YpPSnHDCGihaOCsRkJP0aAbnuQRmjHq6H0yCwtJKjRhW7H4pbjx9/LA6dXIaw4N1emtSLWcGejVrhVZ+CwIDAQAB
When I use dnschecker.org and a few other DNS lookup tools, to look at my TXT records I get the following strange output...
\239\187\191v=spf1 a mx include:_spf.elasticemail.com include:emailsrvr.com -all
These characters \239\187\191
are definitely not in the TXT record in CloudFlare.
CloudWays' support claims that these characters are causing the DMARC to fail, but since they don't appear on other DNS checkers such as https://mxtoolbox.com/ and https://www.whatsmydns.net/, and since SPF is returning "neutral", I suspect they are actually a bug in https://dnschecker.org/ and the DNS checker that Cloudways support are using.
Any thoughts?
NOTES
Thanks to Patrick Mevzek's answer below I was able to find a solution.
Just a quick description of how I ended up in this mess in the first place: Basically I copy pasted the values of the DNS records from a Cloudways support chat window straight into Cloudflare.
And to remove the characters I needed to copy the value from Cloudflare into Notepad++, change the encoding to ANSII, which made the extraneous characters appear, delete them, then change back to UTF-8 (just in case), and paste back into CloudFlare.
example.com
isSELECTOR._domainkey.example.com
. In your case the selector is20220817-maluhsjy
.example.com
, the relative DNS record name for the DKIM key with that selector would be20220817-maluhsjy._domainkey
, exactly what we see. That is correct.emailsrvr.com
SPF record. DMARC fail is strange, especially when the policy itself is set tonone
. It could be because Google failed to read your SPF record, e.g. they receive corrupted DNS too. Or it could be something else. Is it possible to (at least, temporarily) delegate this domain to some other, knowingly working DNS servers, and see if the problem persists?