DNS & domain security
Your domain is an identity. Stop other people using it.
An unprotected domain can be used to send invoices to your customers in your name, and the first you hear about it is a complaint. The controls that prevent this are DNS records — and the same records, misconfigured, will quietly stop your own mail from arriving. This work is about getting both halves right.
You might need this if
- Customers or suppliers report invoices and payment-detail changes that you never sent.
- Your DMARC policy is still p=none years after it was added, because nobody was confident enough to tighten it.
- Nobody knows which of the fifteen TXT records on the domain are still needed.
- A lapsed registrar lock, or a domain whose renewal depends on one person’s personal card.
- Subdomains left pointing at cloud resources that were deleted.
- DNS is spread across three providers and nobody is sure which one is authoritative.
What the work covers
Not every engagement includes all of this. The scope is agreed in writing before anything starts.
Domain authentication hardening
SPF, DKIM and DMARC brought to an enforcing policy at the pace your real sending traffic allows, including a restrictive policy on subdomains that should never send mail.
DNS zone audit and cleanup
Every record inventoried and attributed to a system. Records nobody can account for are flagged, not deleted on a guess.
Dangling record review
Finding CNAME and A records pointing at deprovisioned cloud resources, which are the usual route to a subdomain takeover.
Registrar protection
Transfer lock, auto-renew, registrant contact hygiene and multi-factor on the registrar account — the controls that matter most and get checked least.
DNSSEC
Signing the zone where your registrar and DNS provider both support it, with an honest explanation of what DNSSEC does and does not protect against.
MTA-STS and TLS reporting
Publishing an MTA-STS policy and a TLS-RPT address so mail to your domain cannot be silently downgraded to an unencrypted connection.
How we approach it
- 01
Inventory first
We export the full zone and map each record to the service that depends on it before proposing a single change.
- 02
Observe before enforcing
DMARC stays in monitoring mode while aggregate reports are collected, so we can see every legitimate sender before a policy starts rejecting mail.
- 03
Change in reversible steps
TTLs are lowered first. Each change goes out on its own, is verified from an external resolver, and is observed before the next one.
- 04
Verify from outside
Records are checked against public resolvers, not only against the provider’s own dashboard, because those disagree more often than you would expect.
- 05
Document the zone
You end with a zone where every record has a stated owner and purpose, so the next person does not have to guess.
What you end up with
- A documented DNS zone with every record attributed to a system
- An enforcing DMARC policy, or a written plan with the conditions for reaching one
- Subdomain policy preventing mail from domains that should never send
- A list of dangling records and takeover risks, with remediation steps
- Registrar hardening checklist, completed
- MTA-STS and TLS-RPT published where supported
Technologies involved
Tools and standards this work is carried out with — listed because they are what the job uses, not as a claim of vendor partnership.
- DMARC aggregate reporting
- DNSSEC
- MTA-STS
- TLS-RPT
- CAA records
- Cloudflare
- Route 53
- PowerDNS
- BIND
What this will not do
DMARC enforcement stops others sending as your exact domain. It does not stop lookalike domains, display-name spoofing, or a compromised mailbox sending genuine mail. Those need different controls, and we will say which ones apply to you.
On client examples: we do not publish case studies, logos or testimonials without written permission from the client, and we have none cleared for publication yet. If you need evidence of relevant work before engaging, ask — we will share what we can, appropriately redacted, and say plainly where something was a lab build rather than a client engagement.
Questions about this service
How long does it take to get to DMARC enforcement?
Typically four to eight weeks, and most of that is waiting rather than working. Aggregate reports need two to four weeks to reveal every system sending as your domain, including the ones that only run at month end. Rushing that step is how a legitimate mail stream gets silently rejected.
Is DNSSEC worth enabling?
It depends on your registrar and DNS provider supporting it cleanly, and on who you are. DNSSEC protects against DNS responses being forged in transit. It does nothing about a compromised registrar account or a weak password, which are far more common attack routes — so we would rather fix registrar hardening first and treat DNSSEC as the next step, not the first one.
What is a dangling DNS record and why does it matter?
A CNAME or A record pointing at a cloud resource that has since been deleted. Because the record still resolves toward the provider, anyone who claims that resource name can serve content on your subdomain — including a convincing phishing page on a hostname your customers trust. It is a common finding and a quick fix once identified.
Can you work on this if our DNS is managed by someone else?
Yes, and it is common. We can produce the exact record values and the order to apply them, and work alongside whoever holds access. It is slower than having access ourselves, but it keeps your access control intact, which is usually the right trade.
Want to know where your domain stands today?
The free email health check reads your live SPF, DKIM and DMARC records and explains what each one is currently doing. Start there, then bring us the parts that need a decision.