On this page

Understanding Provider-Controlled Security Checks

Why these checks are different

Most items on your domain scan — SPF, DKIM, DMARC, DNSSEC — are DNS records you can edit yourself through your registrar or DNS host. The checks below aren't. They test the configuration of the actual mail server or web server handling your traffic, which is controlled by whoever operates that infrastructure: your email provider (Microsoft 365, Google Workspace, or a self-hosted mail server), your website host, or the network/ASN provider announcing their IP addresses.

You can't fix these with a DNS record change. What you can do is know what's being checked, confirm who owns it, and ask the right question to get it resolved.

Secure Connection (TLS configuration)

What it checks: Whether your mail server and web server only accept strong, modern TLS versions (1.2/1.3) and cipher suites, and correctly implement supporting protections — STARTTLS, disabling TLS compression, downgrade-attack prevention (TLS_FALLBACK_SCSV), secure renegotiation, and HSTS (website only).

Who owns it: Your email provider or website host. If you self-host either, this falls to whoever administers that server.

What to ask them:

  • "Can you confirm TLS 1.0 and 1.1 are disabled, and only TLS 1.2+ is offered?"
  • "Are you using cipher suites with forward secrecy (ECDHE) and AES-GCM or ChaCha20, with no CBC-mode or SHA-1-based ciphers?"
  • "Is HSTS enabled with max-age=31536000 and includeSubDomains?" (website only)

What good looks like: Only TLS 1.2/1.3 offered, no weak ciphers, HSTS present on the website with a long max-age.

Certificate

What it checks: Whether your mail server's TLS certificate is valid, uses a strong key algorithm (RSA ≥2048-bit or EC ≥224-bit) and signature hash (SHA-2/SHA-3, not SHA-1), matches the correct domain name, and doesn't chain to a distrusted legacy root (e.g. old Symantec CAs).

Who owns it: Your email provider — certificate issuance and renewal happens on the mail server side, not in DNS.

What to ask them:

  • "Can you confirm the mail server's certificate is currently valid and issued by a trusted CA?"
  • "Does it use SHA-2 (or better) for the signature and a modern key size?"

What good looks like: A currently valid certificate, issued by a modern CA, using strong key/signature algorithms, matching your domain.

Modern IP Address and Network Security

What it checks: Whether your mail/web server is reachable over IPv6, and whether the network route announcing its IP address is authorized via RPKI (Route Origin Authorization).

Who owns it: Your hosting or network provider. RPKI in particular is set at the ASN/network level — this is essentially never something a customer configures directly, even if you manage your own server.

What to ask them:

  • "Does our mail/web server have a working IPv6 address?"
  • "Is the IP range we're using covered by a valid RPKI ROA?"

What good looks like: A reachable IPv6 address, and an IP range with a valid RPKI record. If your provider doesn't support either, that's a limitation of their infrastructure — worth factoring into any provider review, but not something you can escalate your way past quickly.

Post-Quantum Cryptography (PQC)

What it checks: Whether the TLS handshake uses post-quantum or hybrid (classical + PQC) key exchange, protecting today's traffic against future quantum-capable attackers.

Who owns it: Your email/website provider — this is entirely dependent on them adopting PQC-capable TLS.

What to ask them: "Do you have a roadmap for supporting post-quantum key exchange in TLS?"

What good looks like: PQC or hybrid key exchange in use. This is still an emerging standard — most providers don't support it yet, so treat this as forward-looking rather than an urgent gap.

A note on scope

A couple of these checks sit right at the edge of DNS and infrastructure:

  • DNSSEC on your mail server's own domain (not your domain) — e.g. if you use Google Workspace, this checks google.com's DNSSEC status, which is Google's infrastructure, not yours.
  • DANE Validation — once DANE Existence passes (see Setting Up DANE for Email), whether the published record actually matches your server's certificate depends on your provider keeping that certificate in sync with DNS.

Both are worth knowing about, but neither is something you can resolve by yourself.