The Pre-Handover Check: Headers, TLS, and DNS in One Routine

Handing a website to a client is a moment of trust. The client assumes the site is finished, and any problem discovered afterwards reflects on the person who delivered it. A short, repeatable pre-handover routine catches the most embarrassing gaps: missing security headers, an expiring certificate, and email records that were never finished. It takes minutes, it produces a record you can share, and it prevents the awkward message a week later that starts "our emails are going to spam". Security Header and DNS Checker pairs the header check with the DNS check, which is why it fits this routine so well.

Run the routine on the live address, not on a staging copy. Staging environments often have different server settings, different certificates, and no email records at all, so a clean staging report proves nothing about the site the client will actually use. If the live site is not yet pointed at its final domain, say so in the handover note and schedule a second run after the switch. A check is only meaningful against the address the public will visit.

Step one: headers and TLS

Start with the security headers, reading the report the way a reviewer would. Is HSTS present with a sensible lifetime? Is framing blocked? Are the content-type and referrer policies set? A missing CSP is common and is not, on its own, a reason to delay handover, but it should be noted as a follow-up rather than silently omitted. The client deserves to know what is done and what remains, in plain language, not a grade without explanation.

Check the TLS certificate in the same pass. The report shows the certificate's validity period, and the question to answer is simple: does it expire soon, and will it renew automatically? A certificate expiring in ten days with no auto-renewal is a handover problem, even though the site works today. Note the expiry date in the handover document, along with who is responsible for renewal — the host, a plugin, or a manual process. Certificates are the most common cause of a site suddenly showing a browser warning, and warnings destroy visitor trust instantly.

Step two: DNS and email authentication

Next, check the domain's DNS and email records. Confirm that SPF lists every service that sends mail for the domain: the website itself, any contact form, a newsletter tool, and an invoicing system if one exists. Confirm DKIM for each sender, remembering that DKIM is per-service, so one valid signature does not cover the others. Read the DMARC record and record both its policy and its reporting address. A policy of none with reports enabled is a fine handover state, provided the client understands it is a starting point and that the policy should be tightened once reports confirm no legitimate sender is failing.

This step also catches a frequent handover gap: the previous developer's records. Domains change hands, mailing tools change, and old SPF entries pointing at services nobody uses anymore linger for years. They are harmless clutter until they are not — an outdated entry can, in rare cases, let a service nobody monitors send mail that passes authentication. A handover is the right moment to list every entry and ask whether each one is still needed. For the detail behind each record, see the SPF, DKIM, and DMARC guide.

Worked example: a fictional handover, with findings

Imagine a fictional freelance developer, Alex, handing over a small business site at example.org for an invented client, Northfield Studio. Alex runs the checker on the live address and finds: HSTS present, CSP missing, X-Frame-Options present, TLS valid for eleven months with auto-renewal enabled, SPF listing the website and the newsletter tool, DKIM valid for the website only, and DMARC at policy none with a reporting address set.

Alex's handover note writes itself from that report. Done: HSTS, framing protection, TLS with auto-renewal, SPF covering both senders, DMARC monitoring in place. To do: add a DKIM record for the newsletter tool before the next campaign, and consider a report-only CSP once the site's third-party scripts are inventoried. Nothing is hidden, nothing is overstated, and the client can see exactly what was checked. If the client later reports a mail problem, the note shows whether DKIM for the newsletter was fixed or still outstanding, which turns a blame discussion into a task list.

Step three: write it down and re-check

A check without a written record is barely better than no check. Save the report's findings, the date, and the address checked, in the handover document. List each finding as done, outstanding, or intentionally deferred, with a reason for any deferral. "CSP deferred because the booking widget's script sources are still being inventoried" is a professional judgement. Silence about CSP is a gap waiting to be discovered.

Schedule one re-check after handover, ideally after the first real mail campaign or the first month of traffic. Headers can change when a host updates server settings, DNS records can be edited by someone else with access, and certificates renew — or fail to renew — on their own schedule. A single follow-up run, compared against the handover record, shows whether anything drifted. Pair this routine with a page-level review from the On-Page SEO and Redirect Checker, which covers titles, headings, and redirect chains, and add the Structured Data Generator if the site uses schema markup. Together, the handover covers the protective, the visible, and the structured sides of the site.

Honest limitations

This routine checks what a site sends and what DNS publishes at one moment. It does not prove the site is secure, it does not audit the application's code or passwords, and it does not fix anything it finds — each fix is a separate server or DNS change. Results can also differ between pages, since headers set on the homepage may not match those on the rest of the site. Treat the routine as a documented snapshot and a task list, not as a promise of safety, and be honest with the client about that boundary.

FAQs

What should I check before handing a site to a client?

Security headers, TLS certificate validity and renewal, and the domain's SPF, DKIM, and DMARC records, run against the live address. Record the findings in the handover note, including anything deferred and why.

Should I run the check on staging or live?

Live. Staging usually has different server settings, certificates, and no email records, so a clean staging report proves nothing about the site the public will visit. If the live domain is not ready, schedule a second run after the switch.

Is a missing CSP a reason to delay handover?

Not necessarily. CSP is the most complex header to add safely, and a rushed policy can break legitimate features. Note it as a follow-up with a plan, rather than hiding it or delaying delivery for it alone.

How often should I re-check after handover?

At least once after the first real mail campaign or first month of traffic, and again whenever the host, mailing tools, or domain settings change. A follow-up run compared against the handover record shows whether anything drifted.

A checker result is a starting point for fixes, not the fix itself; for the header-by-header detail behind the report, see the HTTP security headers guide.

human review pending client designation