Digital transformation baseline · Article 3
The Neighbours' Reputation
Nobody visiting a site can see a DNS record, a shared server's sending history, or a machine-readable identity claim in a script tag. All three decide, before a human ever forms an opinion, whether the site or its mail gets treated as legitimate at all. Both are now resolved for the production domain — done early, and done deliberately, not as a last-minute scramble.
Third in the digital transformation baseline series.
A consultancy that sells digital competence doesn't get to skip the parts of trust a visitor can't see. Two of the three that decide it before anyone forms an opinion are now handled — done early, and done deliberately. The third is a live decision, not a gap.
Authentication travelled because someone made it travel
The original finding was straightforward: the interim .xyz production host had none of the three published, so outbound mail from it was scored against the worst assumptions a receiving server can make about an unauthenticated sender on a low-trust TLD. That gap closed with a full SPF, DKIM and DMARC suite live in that domain's DNS.
The migration target didn't repeat the wait. The production domain behind this article went live with its own complete set from day one — SPF, a DKIM key at the default selector, and a DMARC policy in monitor mode — confirmed by direct DNS query rather than assumed from the setup steps having been followed. Monitor mode (p=none) is the correct starting point, not a shortfall: it means reports get read before enforcement tightens, rather than legitimate mail getting silently rejected on day one.
It would be easy to write this as "the migration fixed its predecessor's biggest gap" and stop there. What's actually worth noticing is the sequencing: authentication wasn't bolted on after mail started bouncing — it shipped with the domain, before a single message needed to rely on it.
A clean domain on a listed server is still a listed sender
The original interim host sat on a shared server whose reputation belonged to every other domain hosted alongside it, not to any one of them individually. A domain's own age and history reset on a migration to a new name. A shared server's reputation doesn't reset for anyone — it was never any single domain's to begin with.
The production domain now runs on its own, separate server account rather than inheriting the old one. Checked directly against two independent blocklist services: not listed on either. A clean result today doesn't guarantee it stays clean forever — shared infrastructure can pick up a bad neighbour later — so this is a check worth repeating periodically, not a box ticked once and forgotten.
The through-line so far
A new domain buys you a new reputation for exactly the parts of trust that were ever yours to reset.
What's already public, and what isn't decided yet
Every page now carries structured data naming the legal entity, a real registered address, and a company registration number a script can check against the public register without asking a human to trust an unverified claim. That's a small thing to add and a large thing to fabricate — which is exactly why nothing here is invented.
Security response headers do similar work from a different angle: signals a browser enforces silently and an outside scoring service checks in seconds, none of it visible in the rendered page. That rollout is still in progress rather than finished — worth its own article once it is, rather than a status line buried in this one.
What this article doesn't settle
- Corroboration is still single-source. One external profile links back to the site. Trust that could be borrowed from established properties currently isn't.
- WHOIS privacy is still on, trading the cheapest available identity signal for the maintainer's own privacy preference — a genuine tension, not an oversight, and not resolved here on anyone's behalf.
- The blocklist check is a point-in-time result, not a standing guarantee — worth a periodic re-check rather than a permanent close, per the note above.
- Security response headers are still being rolled out in stages, deliberately, rather than flipped all at once.
The through-line
A new domain buys you a new reputation for exactly the parts of trust that were ever yours to reset — and a decision, made once and monitored rather than assumed, for the part that was never going to reset on its own. Authentication travelled because someone made it travel, on purpose, ahead of needing it. A server's history won't do that by itself; it simply belongs to whichever neighbourhood the domain ends up in.