Alright, I've been banging my head against this for two days now and I'm officially out of my own ideas. I'm trying to get Vanta to pass the Gmail DKIM scan as part of a compliance framework. According to every tool under the sun, our DKIM is set up correctly. Mail-tester.com gives it a 10/10. MXToolbox says it's perfect. Our own emails are signing properly, and SPF/DMARC are fine.
But Vanta's scanner keeps failing with a generic "DKIM is not configured" error. No useful details. I've triple-checked the obvious:
* The selector (`vanta1` in our case) is published in DNS as a CNAME pointing to Vanta's provided record.
* The CNAME is at the correct location: `vanta1._domainkey.mydomain.com`.
* TTL has propagated, we've checked from multiple external DNS resolvers.
* The record resolves correctly and doesn't have any stray spaces or characters.
My gut says this is either a Vanta-specific scanner quirk or their documentation is missing a crucial piece. Has anyone else fought this particular beast and lived to tell the tale? What did you have to do that wasn't in their setup guide?
Here's our DNS record for reference, anonymized:
```text
vanta1._domainkey IN CNAME vanta1.dkim.vanta.com.
```
I'm running BIND internally, but that shouldn't matter. Before anyone asks, yes, I've already raised a ticket with support, but you know how that goes. I'm hoping someone in the trenches has seen this.
Oh, the classic "scanner that works differently than the entire public internet" scenario. Been there with a few other compliance platforms. You've checked the public validators, which is right.
But >their scanner keeps failing with a generic "DKIM is not configured" error
That's the tell. When a proprietary scanner says "not configured," it often means it's not seeing the record *it expects* at the exact moment of its scan. Two things to check that aren't always obvious:
1. **DNS Propagation vs. Scanner Cache:** Their scanner might be hitting a specific, stubborn recursive resolver (like Google's 8.8.8.8) that's still holding a stale cache, even if other tools show it as live. Try changing the TTL on the CNAME to something very low (like 60 seconds) for a brief period, wait an hour, then run their scan again. Sometimes you have to force the issue.
2. **CNAME Chain Resolution:** I've seen scanners, especially security-focused ones, choke if the CNAME points to another CNAME (a chain) or if the final target record is hosted on a domain that has any DNS lookups they deem suspicious (like using a different cloud provider). Can you share the *full* resolved value of your CNAME? Not the alias, but where it ultimately points after a `dig CNAME` and then a `dig TXT` on that target? That's where the scanner is actually fetching the public key from.
It's probably a timing or resolution depth issue their docs didn't bother to mention.
APIs are not magic.