Some gaps worth addressing

Your SPF record is published correctly and lists the services allowed to send mail on your behalf. The soft-fail (~all) is acceptable.

v=spf1 include:_spf.google.com include:mailgun.org ~all

Your DKIM signature is valid, but the signing key is 1024 bits. Modern guidance (NIST SP 800-57, M3AAWG) is 2048 bits. 1024-bit RSA is considered weak and may be downgraded by major mailbox providers in 2026.

selector:    google._domainkey.acme.example
algorithm:   rsa-sha256
key length:  1024 bits

Fix: Rotate to a 2048-bit RSA key in your mail provider's DKIM settings.

A DMARC record exists, but the policy is p=none — meaning failing messages are reported but NOT rejected. Attackers can still spoof your domain and reach inboxes. You are currently in monitoring mode only.

v=DMARC1; p=none; rua=mailto:dmarc@acme.example; pct=100

Fix: Move to p=quarantine after 30 days of clean reports, then to p=reject.

The site serves over HTTPS and responds normally.

https://acme.example responded 200 OK on port 443

Certificate is valid, trusted, and chains correctly to a public root.

issuer:       Let's Encrypt R3
subject:      CN=acme.example
not before:   2026-04-26
not after:    2026-07-25
days left:    42

Fix: Verify your auto-renewal (ACME / certbot) is healthy.

Modern TLS only — obsolete protocol versions are disabled.

Server negotiated TLS 1.3 (TLS 1.2 also supported, 1.0/1.1 disabled)

HSTS is enabled with a one-year max-age, but the header does not include includeSubDomains or preload. Subdomains are not protected and your domain is not on the HSTS preload list.

strict-transport-security: max-age=31536000

Fix: Add `includeSubDomains; preload` and submit at hstspreload.org.

Without a CAA record, any publicly trusted certificate authority can issue a certificate for your domain. Restricting issuance to your current CA reduces the risk of mis-issuance and rogue certificates.

No CAA records found for acme.example

Fix: Publish a CAA record: acme.example. IN CAA 0 issue "letsencrypt.org"

DNSSEC signing is configured at your zone but the chain of trust is broken at the parent. Resolvers will not validate your records.

DNSKEY present at zone, but no DS record at parent (.example)

Fix: Publish the DS record at your domain registrar.

Four nameservers across two providers. Good redundancy.

ns1.cloudflare.com      (Cloudflare, ASN 13335)
ns2.cloudflare.com      (Cloudflare, ASN 13335)
ns-aux1.acme.example    (self-hosted, ASN 14618)
ns-aux2.acme.example    (self-hosted, ASN 14618)

Mail routing is configured correctly with priority fallback.

10 aspmx.l.google.com
20 alt1.aspmx.l.google.com
20 alt2.aspmx.l.google.com

Employee email addresses linked to your domain have appeared in third-party breaches. This does not mean your systems were compromised — it means staff have reused or exposed work emails on services that were later breached. The risk is credential stuffing against your own logins.

47 email addresses on @acme.example appear in 3 public breach corpora.

Breach                              Date       Affected
----------------------------------- ---------- ---------
Collection #1 credential dump       2019-01    12
ProjectMgmtSaaS user export         2023-08    28
MarketingPlatform leak              2024-03    7

Fix: Enforce SSO + MFA on all internal services. Roll any shared/legacy credentials. Notify the 47 affected users to reset passwords on personal services where they reused their work email.