Scenario · Before you touch a site
Create or remove an email address
“We've hired a new coordinator — can she get an email address?” Or, after someone leaves: “Close her mailbox.”
Creating a mailbox for a new hire is simple. Closing one down after someone leaves is the part that quietly causes damage, because a mailbox that just disappears silently bounces whatever was still arriving there — including, often, the website's own form notifications. This reads where a domain's mail actually lives so you're not guessing which provider to go to, and confirms nothing about the domain's mail setup broke in the process; the actual mailbox change always happens by hand in that provider's own console.
What to ask for
See it work
A real run of Hosting & DNS:
example.com
hosting: Cloudflare (origin hidden)
platform: —
CDN/edge: Cloudflare
nameserver: Cloudflare
IP: <ip> CLOUDFLARENET - Cloudflare, Inc., US
email:
SSL: SSL Corporation
registrar: RESERVED-Internet Assigned Numbers Authority
registered: <date>
last change:<date>
account: active — SEO (Active)
expects: seo, analytics, content
CS: Jordan Casey
specialist: Priya Nandan
tech SEO: Sam Okafor
writer: Morgan Reyes
editor: Alex Chen
content dev:Jamie Park
HOSTING PLAYBOOK
wiki disabled (--no-wiki)
wrote ./out/hosting-and-dns.json
report: ./out/hosting-and-dns-hosting-and-dns.htmlThe captured report, exactly as a run hands it to a client —open the full report ↗
Clerical on the creation side and genuinely risky on the removal side, because a mailbox that stops existing without a forward silently bounces whatever was still arriving at it — including, frequently, form notifications and directory listings nobody remembers configuring.
- Find out where the mail actually lives. The hosting and DNS read reports the domain’s mail provider. On an inherited client this is regularly not what anyone assumed, and guessing wastes an access request.
- For a removal, find out what still sends there before closing anything. Website form notifications, the Business Profile contact, directory listings, booking confirmations. This address is probably wired into something, and nobody documented it.
- [manual] Make the change in the provider’s console. Create the mailbox at the right permission level, or — for a leaver — convert it to a forward or a shared mailbox rather than deleting it outright. Deletion is the irreversible option and it is rarely the one that was needed.
- [manual] Re-point whatever step 2 found. Form notification recipients on the website, listings, anything else. This is the actual work of a removal and it is the part that gets discovered later by a missed enquiry.
- Re-read the domain’s mail configuration. What you are checking for is that nothing about the domain’s authentication changed — a provider change or a records edit made while in there can affect deliverability for every address on the domain, not just this one.
- [manual] Send a test in both directions and keep the headers from a delivered message. For a removal, confirm mail to the old address goes where it should now rather than bouncing.
- Record it. Who, which address, created or removed, forwarded where, and the date.
Deletion is not the same as removal
The request says “close her mailbox” and the safe interpretation is “stop her reading it and keep the mail arriving somewhere”. Step 3 defaults to a forward for that reason: the cost of keeping an address alive is nothing, and the cost of bouncing enquiries nobody knew were going there is a client conversation.
What this does not cover
The mailbox. There is no mail-administration tool here: creating, removing or forwarding an address all happen in the mail provider's console by hand. What this reads is the domain's public mail configuration, which is enough to tell you *which* provider to go to — the thing most often unclear on an inherited client — and to catch a change that broke authentication for the whole domain.