WordPress Domain & DNS: The 9 Settings Every Agency Should Lock Down

Most conversations about WordPress security never reach the domain. They stop at plugins, passwords, a firewall, maybe a security plugin with a reassuring dashboard. All of that protects the site. None of it protects the thing the site depends on, which is the domain name and the DNS records that point it at a server. A site can be perfectly patched and still be stolen, because the attacker does not need to break into WordPress at all. They only need to change where the domain points, and your traffic, logins and email belong to someone else while your actual WordPress install sits untouched, serving nobody.

So before any of the nine settings below, here is the single most important one stated plainly. The most important DNS setting to lock down is the registrar lock, the transfer prohibition flag set on the domain at your registrar. Every other item on this list, DNSSEC, CAA records, the email authentication triad, builds a wall around the domain, and the registrar lock is what stops an attacker from picking the whole domain up and carrying it to a registrar you do not control, where none of your walls apply any more. Lock that first, secure the registrar account that holds it, and then work outward. This article is the full checklist, in that order, with the specific hijack each setting is there to prevent.

Start at the registrar: transfer locks and account control

A domain name lives at a registrar, and the registrar account is the master key to everything. Whoever controls that account controls the domain, the website and the email regardless of how hardened the WordPress install is. This is why the first two settings are not technical DNS records at all. They are the locks on the front door.

The first is the registrar lock. In the language of the domain system this is an EPP status code, usually shown as clientTransferProhibited, and it tells the registry to refuse any request to transfer the domain to a different registrar. Good registrars switch it on by default, but default is not the same as verified, so open the domain in your registrar dashboard and confirm it is actually set. For higher value domains, add clientUpdateProhibited and clientDeleteProhibited as well, which block edits to nameservers and contacts and prevent deletion. The worst case this prevents is the cleanest kind of hijack there is. An attacker who gets into your registrar account, or who social engineers a registrar support agent, simply transfers the domain to their own registrar. Once it has moved, recovery is no longer a setting you toggle, it is a formal dispute that takes weeks, during which your brand is offline.

The second setting is the security of the registrar account itself, because the lock is only as strong as the login protecting it. Enforce a strong, unique password and turn on two-factor authentication, ideally an authenticator app or a hardware key rather than SMS, since text-message codes can be intercepted through SIM swapping. Lock down the recovery email too, because an attacker who can reset your registrar password through a weak mailbox has bypassed the 2FA entirely. While you are in there, switch on auto-renew and confirm the billing card on file is valid. The most common domain disaster across an agency portfolio is not a sophisticated attack. It is a domain that quietly expired because the renewal card had lapsed, dropped from the owner's control, and was registered by a squatter who now wants real money to give the brand back.

DNSSEC: proving the answer has not been forged

With the domain itself locked, the next layer protects the answers DNS gives out. Ordinary DNS was designed in a more trusting era, and it has no built-in way to prove that the response a visitor's resolver received is genuine. That gap allows cache poisoning, where a resolver is tricked into storing a forged record. To every visitor using that resolver, your domain now quietly resolves to an attacker's server, with no warning because nothing about the address bar looks wrong.

DNSSEC closes this gap by cryptographically signing your DNS zone, so resolvers can verify that an answer genuinely came from you and was not altered along the way. Enabling it is a two-part job and both halves are mandatory. You switch on signing at whatever provider hosts your DNS, and then you publish a matching DS record at your registrar, which links your signed zone into the chain of trust that runs up to the top-level domain. Do only the first half and nothing is protected. The one caution worth stating, because it causes real outages, is that DNSSEC must be kept in sync. If you ever move DNS to a new provider and leave a stale DS record behind at the registrar, the domain will fail validation and stop resolving entirely, a self-inflicted outage, which is exactly why DNS records belong on a maintained checklist rather than in someone's memory.

CAA records: controlling who can issue your certificates

DNSSEC protects the routing of your domain. A CAA record protects its identity, specifically the HTTPS certificates that prove a site is really yours. A Certification Authority Authorization record is a small DNS entry that names which certificate authorities are permitted to issue certificates for your domain. Authorities are required by industry baseline rules to check for this record before they issue, so if you publish one allowing only the authority you actually use, every other authority is obliged to refuse.

The worst case here is subtle. If an attacker can get a valid, browser-trusted certificate issued for your domain, perhaps by exploiting a weak validation step or a compromised authority, they can stand up a clone of your site that shows the reassuring padlock and triggers no security warnings at all. Visitors and even cautious staff have no visible signal that anything is wrong. A CAA record shrinks that attack surface to the one or two authorities you have deliberately chosen, and you can include an incident reporting address so an authority can notify you if a request is ever refused on your behalf.

The email triad: SPF, DKIM and DMARC

The next three settings belong together because they solve one problem, which is that by default anyone on the internet can send email that claims to be from your domain. For an agency this is the invoice fraud and the phishing email that lands in a client's inbox appearing to come from you, and it does real damage to a relationship you were hired to protect.

SPF, the Sender Policy Framework, is a TXT record that lists the mail servers and addresses allowed to send email for your domain. A receiving server checks incoming mail against that list, and a strict policy ending in a hard fail tells receivers to reject anything that is not on it. SPF stops the most basic spoofing, but it has a known weakness, which is that it breaks when a message is forwarded. DKIM, DomainKeys Identified Mail, covers that gap. Your sending mail server signs every outgoing message with a private cryptographic key, and the matching public key is published in your DNS. Receivers verify the signature, which proves the message was genuinely authorised by your domain and was not tampered with in transit, and unlike SPF that proof survives forwarding.

DMARC is the setting that turns the other two into an actual defence. On its own, SPF or DKIM failing does not guarantee a forged message is rejected, because receivers are left to decide. A DMARC record, published at a dedicated subdomain, ties SPF and DKIM together, requires that the visible sender address aligns with them, and states explicitly what receivers should do with mail that fails: monitor it, quarantine it, or reject it outright. The worst case it prevents is exact-domain phishing, an attacker emailing your clients from your real domain rather than a lookalike, and only a reject policy genuinely stops that. The honest catch is that most domains have a DMARC record stuck on monitoring, which watches the abuse happen without blocking it. The correct path is to start in monitoring mode, read the reports it sends you, fix any legitimate mail that fails, then move deliberately to quarantine and finally reject. Since major mailbox providers began requiring DMARC for bulk senders, this is no longer optional for any agency that emails its clients.

Separate DNS from your hosting, and watch it for changes

The last two settings are about architecture and vigilance, and they are the ones agencies skip most often. The first is to separate where your DNS is managed from where your site is hosted. Many WordPress sites simply use the nameservers their host provides, which is convenient and quietly dangerous, because it means a single compromised hosting login also hands over full control of DNS. An attacker who breaks into the hosting account can then repoint your mail records to intercept email and add records to issue fraudulent certificates, all from one breach. Moving DNS to a dedicated, hardened provider with its own separate account and its own two-factor authentication contains that blast radius, and it means your DNS keeps working even when your host has an outage.

The final setting is monitoring, because every protection above can be undone by a change you do not notice. Almost every domain hijack is silent. The site keeps loading, the email keeps flowing, and the first sign of trouble is a confused customer. Continuous monitoring of your DNS and registration data closes that blind spot. You want alerts on the changes that matter, a nameserver change, a modified mail record, a new or altered A record, a changed DS record, an edited registrant contact, and an approaching expiry date. The worst case monitoring prevents is duration. It is the difference between a hijack caught within the hour and one that runs for a week, skimming traffic or rerouting mail, before anyone realises the domain was the thing that was attacked.

Locking it down, and where WitsCode fits

Those are the nine settings. Lock the domain against transfer, secure and two-factor the registrar account with auto-renew on, sign the zone with DNSSEC, restrict certificate issuance with a CAA record, complete the SPF, DKIM and DMARC email triad and push DMARC past monitoring to enforcement, separate DNS control from hosting, and monitor everything for unauthorised change. Almost none of it costs money and almost all of it is a one-time configuration. The reason it still goes wrong is that DNS is invisible until the moment it fails completely, taking the site and the email down together, and that a checklist set up correctly in year one quietly rots. DS records are left stale after a host migration, SPF drifts out of date as new tools are added, and DMARC sits on monitoring for two years because nobody owned the next step.

That ownership is what WitsCode provides as a managed DNS and domain governance retainer. Across a portfolio of more than 250 sites, we have learned that the domain layer is rarely lost to a clever exploit. It is lost to a lapsed renewal, a registrar account with one shared password, or a DS record nobody kept in sync. On a retainer we hold this checklist for you, keep DNSSEC and certificate records aligned through every migration, run continuous change monitoring, advance DMARC to enforcement on a real schedule, and own renewals so a domain never quietly slips away. If your agency manages client domains and the DNS layer is currently nobody's explicit job, that is the gap we are built to close.