Our own posture
Every check we run, run against us.
A tool that will not show you its own domain is asking you to take its word for something. This page runs the same scanner against emailsecurity.pro and publishes whatever comes back, hourly, including anything unflattering.
emailsecurity.pro
Anyone can send mail as this domain and you would never know. There is no policy telling receivers to reject forgeries, and no reporting to tell you it is happening.
140 DNS queries · 199 ms
- 1No aggregate report address (rua=)Add 'rua=mailto:<address>' to the record.
- 2DMARC policy is p=none (monitoring only)Use your aggregate reports to confirm every legitimate sender aligns, then move to p=quarantine, then p=reject. Most domains can complete this in 4-8 weeks.
- 3No CAA recordPublish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"
- 4No explicit subdomain policy (sp=)Consider adding 'sp=reject' if no subdomain sends mail.
Sending services detected
Read from your SPF includes and MX hosts, then checked for a matching DKIM key.
DMARC
- Policy
- none
- Coverage
- 100%
- Alignment
- dkim=r spf=r
DKIM
111 selectors probed
No key found. Selectors cannot be listed from DNS, so this is not proof DKIM is missing, only that we could not verify one.
SPF
Worst-case evaluation across every include.
- include:amazonses.com
- include:_spf.mx.cloudflare.net
Findings (9)
HighNo aggregate report address (rua=)›
Without rua= you receive no aggregate reports, which means you have no way to see who is sending mail as your domain, whether it authenticates, or what would break if you moved to p=reject. This is the single biggest blocker to enforcement.
Add 'rua=mailto:<address>' to the record.
RFC 7489 s7
HighDMARC policy is p=none (monitoring only)›
Receivers are told to take no action on mail that fails authentication. This gives you visibility but no protection -- spoofed mail is still delivered.
Use your aggregate reports to confirm every legitimate sender aligns, then move to p=quarantine, then p=reject. Most domains can complete this in 4-8 weeks.
RFC 7489 s6.3
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'.
LowNo MTA-STS policy›
Without MTA-STS, mail to your domain can be downgraded to plaintext by an active network attacker, because SMTP's STARTTLS is opportunistic by default.
Publish a TXT record at _mta-sts.emailsecurity.pro and a policy file at https://mta-sts.emailsecurity.pro/.well-known/mta-sts.txt.
RFC 8461
LowNo TLS-RPT record›
You have no visibility into TLS failures on mail sent to your domain, which makes transport problems invisible until someone complains.
Publish 'v=TLSRPTv1; rua=mailto:<address>' at _smtp._tls.emailsecurity.pro.
RFC 8460
LowNo CAA record›
Any certificate authority in the world may issue a certificate for this domain. A mis-issued certificate can be used to intercept mail on the wire and to impersonate your domain over HTTPS.
Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"
RFC 8659
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.
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 2 passing checks
PassSPF lookup count is healthy (2/10)›
Worst-case evaluation stays within the limit with headroom to spare.
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.
Reporting a vulnerability
Email incident@esecforte.com. We acknowledge within two working days. Please give us reasonable time to fix an issue before disclosing it publicly.
Why this page exists
Publishing our own result is the cheapest honest signal we can give. It costs nothing when we are right and it is uncomfortable when we are not, which is exactly what makes it worth reading.