emailsecurity.pro
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.
(stored result) · 143 DNS queries · 518 ms
- 1MTA-STS policy mode is 'testing'Move to 'mode: enforce' once TLS-RPT reports show no failures.
Identity
Sending services detected
Read from your SPF includes and MX hosts, then checked for a published DKIM key.
Identity
DMARC
- Policy
- reject
- Test mode
- off
- 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:amazonses.com
- include:_spf.mx.cloudflare.net
Findings (4)
LowMTA-STS policy mode is 'testing'
In testing mode a sender that implements MTA-STS delivers even when a connection fails the policy, so the policy does not yet stop a downgrade.
Move to 'mode: enforce' once TLS-RPT reports show no failures.
RFC 8461 s5
InfoAmazon SES uses selectors we cannot discover
Detected via SPF include:amazonses.com. SES generates a random per-identity selector when Easy DKIM is enabled, so it cannot be discovered from DNS. Check the SES console for your selector. We cannot confirm or rule out DKIM signing for this service from DNS alone.
Add your Amazon SES selector so we can verify it on every scan.
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 7 passing checks
PassAggregate reporting is configured
Aggregate reports are requested at: [email protected].
PassDMARC policy is p=reject
Receivers are asked to reject mail that fails authentication. RFC 9989 asks a domain at p=reject to DKIM-sign its mail rather than rely on SPF alone, since SPF does not survive forwarding.
RFC 9989 s7.4
PassSPF lookup count is healthy (2/10)
Worst-case evaluation stays within the limit with headroom to spare.
PassSPF ends in '-all' (hard fail)
Unauthorised hosts are explicitly rejected. This is the correct end state.
PassTLS reporting is configured
A TLS-RPT record at _smtp._tls.emailsecurity.pro 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 comodoca.com, digicert.com, letsencrypt.org, pki.goog, sectigo.com, ssl.com 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. Wildcard certificates are limited separately, to comodoca.com, digicert.com, letsencrypt.org, pki.goog, ssl.com.
RFC 8659
PassDANE is published and protected by DNSSEC
Senders that support DANE verify your mail servers' certificates against the TLSA records in your signed zone, which defeats both downgrade attacks and certificate substitution.
RFC 7672
Transport and zone
Where your mail lands, and whether the DNS carrying your records can be trusted.