Has anyone else hit a wall with Vanta's Gmail DKIM scan? I've been through the setup three times now—once for our primary domain and twice for a subdomain we use for marketing—and the dashboard keeps showing a failure, even though all the DNS records appear to be correct.
Here's what I've verified so far:
* The DKIM selector (google.domainkey) and the 2048-bit TXT record are published in our DNS.
* The record is fully propagated—I've checked with multiple external lookup tools.
* Gmail itself shows "PASS" for DKIM when we send a test email to a personal account and view the headers.
The inconsistency is frustrating. I'm wondering if Vanta's scanner is particularly sensitive to something else, like:
* A specific TTL on the DNS record?
* The presence of other, older DKIM records in the zone?
* Something about how it handles subdomain delegation?
I'd really appreciate hearing from anyone who has solved this. What was the final piece you were missing? I'm happy to share more specifics of our configuration if it helps compare notes.
gh2
ship early, test often
Your subdomain theory is likely correct. Vanta's scanner doesn't follow CNAME flattening or delegation the same way a real MTA will. If your subdomain's NS records point elsewhere, the scanner might fail even though actual email passes.
Check the scan's raw error. It usually gives a DNS response code. "SERVFAIL" means it can't reach your nameservers at scan time, which is a network/connectivity issue on their end. "NXDOMAIN" means it's looking for the record in the wrong place, likely the parent zone.
Drop any old DKIM selectors. Having multiple `google._domainkey` records, even inactive ones, can confuse automated scanners.
Trust but verify, then don't trust.
Agreed on the old selectors, that's a common pitfall. But I'm skeptical about dismissing a SERVFAIL as purely "a network/connectivity issue on their end."
If Vanta's scanner is failing to reach nameservers that the rest of the internet can query, that's a scanner defect, full stop. Their tool's inability to perform a basic DNS lookup shouldn't become the user's problem to diagnose. It calls their entire methodology into question. The whole point of these security scans is to simulate real conditions, not to fail under lab conditions that don't reflect reality.
I'd be curious what the actual observed failure rate is for scans against delegated subdomains. It reeks of a lazy implementation that doesn't handle NS records properly.
Data skeptic, not a data cynic.
That inconsistency between the scanner and a real Gmail test is a classic symptom. I see this a lot with subdomain delegation setups.
The key is to run a DNS query from the perspective of the *parent* domain's nameservers. Many scanners, not just Vanta's, get tripped up if they don't properly follow NS records for a delegated subdomain. They might be looking for `google._domainkey.marketing.yourdomain.com` in the zone for `yourdomain.com`, when it actually lives on the nameservers delegated for `marketing.yourdomain.com`. Your external lookup tools might be starting from the root, while Vanta's tool isn't.
Could you share the exact domain structure you're using? Knowing whether the marketing subdomain is a true delegation or uses CNAME flattening would point us in the right direction.
True delegation versus a CNAME for the subdomain is a solid point. I've run into similar scan failures with other monitoring tools that don't follow NS records properly.
If it is a true delegation, could a temporary workaround be to duplicate the DKIM record in the parent zone for the scan's benefit, or would that cause other validation issues?
Duplicating the record in the parent zone is a terrible workaround. It'll only mask the scanner's broken logic.
If you do that, you'll have the same DKIM key published in two places. That's a configuration nightmare waiting to happen. The moment you need to rotate that key, you'll forget one and break real email.
The proper fix is for the scanner to follow NS records like any real resolver. Patching around its flaws just encourages more lazy tooling.
-- old school
I agree that duplicating the record is a bad fix, but sometimes you have to work with the tools you've got. If the security scan is a compliance requirement, the pragmatic path might be to tolerate the duplication temporarily while opening a ticket with the scanner vendor.
Just document it clearly in your runbook that the key exists in two zones, and set a calendar reminder to clean it up once their scanner logic is fixed. It's a technical debt you accept to unblock an audit, not a permanent solution.