Hosting, SSL and email without the chaos.

01

Why these three tangle.

They share a single dependency: the domain name. DNS decides where your site resolves, which certificate authority can prove ownership, and whether your email is trusted. Change one record carelessly and you can take down a website and a mailbox in the same afternoon.

They also tend to be spread across the most vendors and owned by the fewest people. It is common to find the domain registered by a former employee, hosting bought on someone's personal card, and email set up by whoever was nearest at the time.

02

Domains and DNS.

Start here, because everything else inherits from it.

• The registrar account is owned by the organisation, not a person
• Registrar lock enabled and auto-renew on, with billing that will not expire
• Contact address is a role mailbox someone still reads
• A written record of what each DNS entry is for — the mystery TXT record is always load-bearing
• Sensible TTLs, lowered deliberately before a planned migration

03

Certificates.

Most TLS incidents are not a failure of encryption, they are a failure of calendars. Someone renewed manually last year and has since left.

• Automated renewal wherever the stack allows it
• Expiry monitoring that alerts a team, not an individual
• Apex and www both covered, plus any subdomain that faces a customer
• Mixed content cleaned up, so the padlock reflects every route rather than the homepage
• The full chain served correctly — check with a client that is not your own browser

04

Email authentication.

This is where most estates are quietly broken. Mail appears to work because recipients you already correspond with are lenient, and then a campaign or an invoice run lands in spam.

• SPF listing every service that legitimately sends as you — and only those
• DKIM signing enabled on each of them, not just the main mailbox provider
• DMARC published, monitored, and eventually moved beyond p=none
• Departed staff mailboxes converted or forwarded deliberately, not left live
• Shared mailboxes rather than personal accounts for anything operational

05

Who should hold the keys.

Two rules cover most of the risk. First, the organisation owns every account at the registrar, host and mail provider — a supplier may have access, but never sole access. Second, someone can name the person responsible for each layer without checking.

Consolidating vendors helps, but it is secondary. A tidy single vendor that nobody has the password for is worse than three vendors with clear ownership.