google.com
Receivers are told to reject mail that fails authentication for this domain.
Receivers are told to reject mail that fails authentication for this domain. Keep watching aggregate reports so a new sending service does not silently start failing.
Score held up: DMARC is enforcing at p=reject, so nobody else can send as this domain. That is the hard part, and it is done. What is left below is about your own mail arriving, not about anyone spoofing you.
131 DNS queries · 448 ms
- 1Could not verify DKIM signing for Google WorkspaceConfirm DKIM is switched on in Google Workspace, then add your selector here so every future scan can verify it directly.
- 2CAA has no reporting addressAdd a record such as: 0 iodef "mailto:[email protected]"
- 3No explicit subdomain policy (sp=)Consider adding 'sp=reject' if no subdomain sends mail.
- 4SPF ends in '~all' (softfail)Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.
Identity ·Sending services detected
Read from your SPF includes and MX hosts, then checked for a published DKIM key.
Identity ·DMARC
- Policy
- reject
- Coverage
- 100%
- Alignment
- dkim=r spf=r
Identity ·DKIM
111 selectors probed
No key at the 111 selectors we tried. Selectors cannot be listed from DNS, so this is not proof DKIM is missing.
Identity ·SPF
Worst-case evaluation across every include.
- include:_spf.google.com
Findings (6)
MediumCould not verify DKIM signing for Google Workspace›
Google Workspace was detected via SPF include:_spf.google.com, MX smtp.google.com, so it is authorised to send mail as google.com. We checked the selectors it uses by default (google, google2048) and found no key. Google Workspace lets you choose your own selector name, so this may simply mean yours is custom. If signing genuinely is not enabled, mail through this service will fail DMARC once forwarded.
Confirm DKIM is switched on in Google Workspace, then add your selector here so every future scan can verify it directly.
RFC 6376
LowNo explicit subdomain policy (sp=)›
Subdomains inherit p=, which is usually what you want. Setting 'sp=reject' explicitly protects unused subdomains even while the parent is still at p=none.
Consider adding 'sp=reject' if no subdomain sends mail.
LowSPF ends in '~all' (softfail)›
Softfail is the correct setting while you are still discovering senders, but it asks receivers to accept unauthorised mail and merely note it.
Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.
LowCAA has no reporting address›
You have restricted which authorities may issue certificates, but nobody is told when one refuses a request. An iodef address turns an attempted mis-issuance into an alert instead of a silent event.
Add a record such as: 0 iodef "mailto:[email protected]"
RFC 8659
InfoEligible for BIMI›
Your DMARC policy is already enforcing, which is the hard prerequisite for BIMI. Publishing a logo is now largely a branding exercise.
Publish an SVG Tiny PS logo plus a VMC, then add a default._bimi record.
InfoZone is not signed with DNSSEC›
This is the common case and not a misconfiguration -- most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.
If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.
RFC 4033
Show 6 passing checks
PassAggregate reporting is configured›
Aggregate reports are requested at: [email protected].
PassDMARC policy is p=reject›
Mail failing authentication is rejected outright. This is the correct end state.
PassSPF lookup count is healthy (1/10)›
Worst-case evaluation stays within the limit with headroom to spare.
PassMTA-STS is in enforce mode and covers every MX host›
The policy at https://mta-sts.google.com/.well-known/mta-sts.txt is in enforce mode and its mx patterns match all 1 MX host. A sender that implements MTA-STS delivers only over TLS, with a valid certificate, to a host the policy lists.
RFC 8461 s5
PassTLS reporting is configured›
A TLS-RPT record at _smtp._tls.google.com asks sending servers that support TLS reporting to send reports on failed TLS connections to mailto:[email protected].
PassCertificate issuance is restricted by CAA›
Only pki.goog may issue certificates for this domain, so a certificate for your mail hosts or your MTA-STS policy endpoint from any other authority would be a mis-issuance.
RFC 8659
Transport and zone
Where your mail lands, and whether the DNS carrying your records can be trusted.
This is the configuration. It is not the whole picture.
A DNS scan cannot tell you whether google.com’s mail actually aligns, because alignment is decided per message at the receiver. Collect DMARC aggregate reports to see every source sending as this domain.