Launching a website without a security checklist is how you end up fixing critical issues under pressure. This pre-launch guide covers every configuration to verify before flipping the switch.
Anay Pandya
1,858 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
A website launch checklist that skips security is only half a checklist. The most common post-launch emergencies — expired certificates, unprotected admin panels, spoofable email domains, and missing check your security headers — are all preventable with a 30-minute pre-launch review. This guide walks through every layer, from DNS configuration to post-launch monitoring, with specific items to verify before go-live.
<div class="zf-stat-callout" style="background:#0d1117;border:1px solid rgba(16,185,129,0.25);border-left:3px solid #10b981;border-radius:4px;padding:16px 20px;margin:24px 0"> <p style="margin:0 0 4px;font-size:10px;font-weight:700;text-transform:uppercase;letter-spacing:0.15em;color:#10b981;font-family:monospace">ZeriFlow Data — 12,400+ sites analyzed</p> <p style="margin:0;font-size:13px;color:#e2e8f0;line-height:1.6;font-family:monospace">Our scan corpus of 12,400+ sites reveals 43% transmit session cookies without the HttpOnly flag, and 38% omit the Secure attribute — exposing session tokens to XSS and network interception.</p> </div>
Keep reading
Is your site actually secure?
Run a free check — 60 seconds
Scan your site in 60 seconds — it's free: ZeriFlow →
DNS is the foundation everything else sits on. Errors here affect deliverability, security, and even SEO.
### Domain Settings - [ ] Domain registered with a reputable registrar (Cloudflare, Namecheap, Google Domains) - [ ] Registrar account secured with a strong password and 2FA - [ ] WHOIS privacy enabled (prevents your personal contact information from being publicly listed) - [ ] Domain auto-renewal enabled with a valid payment method - [ ] Domain expiry date checked — at least 12 months remaining at launch
### DNS Records - [ ] A record (or AAAA for IPv6) pointing to correct server IP - [ ] CNAME for www (or A record if apex domain is not supported by your CDN) - [ ] MX records configured correctly for your mail provider - [ ] TTL values appropriate — 300–3600 seconds for records likely to change; 86400 for stable records
### DNSSEC - [ ] DNSSEC enabled at the registrar level if supported - [ ] DS record published and validated (use MXToolbox DNSSEC lookup to verify) - [ ] DNSSEC prevents DNS spoofing attacks where an attacker intercepts DNS resolution to redirect visitors to a fake site
### Email Security (SPF, DKIM, DMARC)
- [ ] SPF record: v=spf1 include:[your-mail-provider] ~all — authorizes your mail provider to send on your behalf
- [ ] DKIM: public key published in DNS, signing configured in your mail provider
- [ ] DMARC: at minimum v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
- [ ] Verify all three with MXToolbox before launch — a misconfigured SPF record can silently cause your transactional emails to be rejected
Email security is one of the most commonly skipped items on a website launch checklist. A domain without DMARC can be impersonated trivially by spammers and phishers — your new brand domain becomes a spam vector within days of registration if not configured.
HSTS is the instruction that tells browsers "always use HTTPS for this domain, even if the user types http://." Without it, an attacker on the same network can strip HTTPS on a user's first visit.
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age of at least 1 year (31536000 seconds) — shorter values provide weaker protectionincludeSubDomains included if all subdomains support HTTPSpreload directive and submit to hstspreload.orgVerify HSTS is set on the HTTPS response, not the HTTP response. A common mistake is setting HSTS before the redirect — browsers ignore HSTS headers received over HTTP.
Content-Security-Policy — configured and tested (use Report-Only mode during development to catch violations before enforcing)X-Frame-Options: DENY — prevents your site from being embedded in an iframe on another domain (clickjacking protection)X-Content-Type-Options: nosniff — prevents MIME-sniffing attacksReferrer-Policy: strict-origin-when-cross-origin — controls what URL is sent in the Referer headerPermissions-Policy — restrict browser features to what the site actually uses: camera=(), microphone=(), geolocation=()Server header does not reveal exact version numbers (Apache/2.4.52 is unnecessary and helpful to attackers)Run a ZeriFlow scan at this point to verify all headers are actually being served. Configuration in your framework or server config does not always translate correctly to what the browser receives — a scan gives you the ground truth.
For any site that sets cookies (analytics, session management, consent):
Secure + HttpOnly + SameSite=Strictyourdomain.com/admin — use a non-obvious path or restrict by IPPerformance is included in a security checklist because performance failures can be security incidents: a site brought down by load is indistinguishable from a DDoS attack if you cannot handle baseline traffic.
Cache-Control: public, max-age=31536000, immutable for fingerprinted assets)Monitoring should be in place before launch, not after the first incident.
The last step before launching is an automated scan that verifies the infrastructure layer — TLS, security headers, cookies, DNS, and email security — in one pass.
Running ZeriFlow on your staging environment (if it mirrors production configuration) or on the production URL immediately before launch gives you:
This takes 60 seconds and produces a shareable report. For client projects, this report is part of your professional deliverable.
| Category | Status |
|---|---|
| DNS / DNSSEC | ☐ |
| SPF | ☐ |
| DKIM | ☐ |
| DMARC (p=quarantine minimum) | ☐ |
| HTTPS / TLS 1.2+ | ☐ |
| HTTP → HTTPS redirect (301) | ☐ |
| HSTS (1 year+) | ☐ |
| Content-Security-Policy | ☐ |
| X-Frame-Options | ☐ |
| X-Content-Type-Options | ☐ |
| Referrer-Policy | ☐ |
| Cookie flags (Secure + HttpOnly + SameSite) | ☐ |
| Admin panel protected | ☐ |
| Rate limiting on auth endpoints | ☐ |
| Uptime monitoring active | ☐ |
| Certificate expiry monitoring active | ☐ |
A: Prioritize in this order: (1) broken HTTPS / certificate issues — these block all users and all security; (2) missing HSTS — direct risk of SSL stripping; (3) no HTTP→HTTPS redirect — leaks traffic and credentials; (4) missing security headers — high impact for low effort; (5) email security (SPF/DKIM/DMARC) — high-visibility spam risk; (6) cookie flags — important for authenticated applications specifically.
A: Both, but they serve different purposes. Staging catches issues before they go live. Production confirms nothing was lost in the deployment pipeline. CDN configurations, environment-specific headers, and certificate installation only appear on production.
A: No. Security headers are browser-enforced protections against specific client-side attacks (XSS, clickjacking, MIME sniffing). They do not protect against server-side vulnerabilities (SQL injection, authentication bypass, RCE), insecure dependencies, or social engineering. They are one layer of defense, not the only layer.
A: DNS, DMARC, and uptime monitoring fully apply. HTTPS and basic headers are handled by the platform (verify they are configured correctly — platforms vary). You cannot customize security headers in most website builders, which is a real limitation. For professional or commercial sites handling user data, this is a reason to prefer a platform that allows header customization (Cloudflare Pages, Netlify, Vercel — all support custom headers).
A: For most sites, yes. Modern registrars (Cloudflare, Google Domains) handle DNSSEC with a single toggle and no manual key management. The protection it provides — preventing DNS cache poisoning and DNS spoofing — is meaningful, especially for e-commerce, SaaS, and any site handling authentication.
A secure website launch is the same as any other professional launch: it follows a checklist rather than relying on memory or intuition. The items in this guide take less than a day to implement for a typical project and represent the baseline that any site handling user data should have before going live.
The last step before you flip the switch: run a scan and document the configuration state.
Start your free ZeriFlow scan → — no credit card, instant results.
<!-- zf-internal-links -->
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
June 24, 2026
Best Security Tools for AI Startups
Monitor your security score
Schedule recurring scans and catch regressions after deployments.