TLS and email checks: weak HTTPS and a spoofable domain
A near-expiry or weak TLS certificate, and a domain without SPF/DMARC, are launch-blocking trust issues. Here is what to set.
Two quiet trust problems show up at launch: a weak HTTPS setup, and an email domain anyone can impersonate.
TLS / HTTPS
A certificate that is close to expiry, or a server still allowing old protocols (TLS 1.0/1.1) or weak ciphers, undermines the padlock users rely on. Most hosts (Vercel, Netlify, Cloudflare) manage certificates automatically — if yours doesn't, renew it and disable legacy protocols.
Email spoofing (SPF / DMARC)
If your domain has no SPF and DMARC DNS records, anyone can send email that appears to come from you@yourdomain.com — a gift for phishing your own users. Shipshape only flags a permissive or missing policy (e.g. an SPF +all), not a normal ~all.
The fix
- Add an SPF TXT record listing who may send for your domain; avoid
+all. - Add a DMARC record (start at
p=noneto monitor, then tighten toquarantine/reject). - Keep TLS auto-renewing and disable TLS 1.0/1.1.
FAQ
Why does Shipshape check email DNS for a web app?
Because a domain without SPF/DMARC can be spoofed — attackers can send phishing email that looks like it comes from you, targeting your own users. It is a launch-time trust gap.
My host manages HTTPS — do I still need to care about TLS?
Usually the cert is handled for you. The check matters if a cert is near expiry or your server still allows old protocols (TLS 1.0/1.1) or weak ciphers.
Related questions
- Sensitive data shipped to the browser: config, internal fields, and bulk PII
- An outdated frontend library with a known vulnerability
- Is Shipshape legit? What it does and doesn’t do
- Supabase anon key vs service_role key: which is safe to expose?