
What Requires Attention
The BIG Questions
Domain Overview
Technical Findings
Email Authentication
Mail Transport Security
DNS Security
Brand & Certificate Controls
Priority Actions 4 total Achievable: Low Risk
Change your DMARC policy from p=none to p=quarantine (then p=reject). Review your DMARC aggregate reports first to ensure legitimate senders pass authentication.
Publish an MTA-STS DNS record and host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This tells senders to require TLS when delivering mail to your domain.
Your SPF record uses ~all (softfail), which asks receivers to accept but flag unauthorized senders. Upgrading to -all (hardfail) instructs receivers to reject unauthorized senders outright. Verify all legitimate sending sources are included before switching. Note: if you later enable DMARC enforcement (p=reject or p=quarantine) with DKIM, ~all becomes acceptable because DMARC evaluates both SPF and DKIM alignment before making decisions (RFC 7489 §10.1).
TLS-RPT (TLS Reporting) sends you reports about TLS connection failures when other servers try to deliver mail to your domain. Helps diagnose MTA-STS and STARTTLS issues.
Appendix — Additional Resources
Full technical details including raw DNS records, DKIM public keys, IP/ASN mappings, resolver consensus evidence, and verification commands are available in the Engineer's DNS Intelligence Report.
Verify Report Integrity SHA-3-512 Has this report been tampered with? Verify below
Tamper-evident fingerprint binding this analysis to its data, domain, timestamp, and tool version.
dfab623e636ac313680da541858cc79995f87165b55e93133a1043a25a7cccf33e366dd27e94d673d0c957288cb051d5ecb2149f33cebf904731b862bb42df23
