The Domains Nobody Thinks About Are the Ones Getting Abused

Every MSP has them in their client base. Domains that were registered for a project that never launched. A legacy brand that got folded into a new one. A domain the client bought five years ago "just in case." A marketing site with no email attached to it.

A domain the client bought because someone else might register the .net version of their .com and they wanted to get ahead of it. It redirects to the main site, or it used to, or it does nothing at all now.

Nobody's logging into those DNS portals. Nobody's running security assessments against them. They just sit there, pointed at a parking page or nothing at all, quietly becoming a liability.

A domain with no email service has no opinion about email, from a spam filter's perspective. That means anyone can forge it. There's nothing in DNS to say "this domain doesn't send email, reject anything that claims to be from it." Without that, it's an open invitation for spoofing, and attackers know it.

This post covers the specific DNS records that close those doors, and why each one matters, whether you're dealing with a parked domain, a web-only domain, or anything else that isn't actively sending email.

Why Inactive Domains Are High-Value Targets

An attacker looking to run a phishing campaign wants a domain that looks legitimate but won't trigger blocklists. New domains raise flags. Actively-used domains are more likely to have SPF, DMARC, and DKIM in place.

Parked domains are the sweet spot. They often have enough age to look credible, and they almost never have any email authentication records. The organization that owns the domain isn't watching it. Their MSP probably isn't watching it either.

Spoofing from a parked domain lets attackers send email that appears to come from a real company, sometimes a brand the recipient already trusts, with no technical controls in DNS pushing back on it.

Beyond spoofing, there are a few other risks worth flagging:

Subdomain takeover. If a domain has DNS records pointing to cloud services that were deprovisioned (an old Azure web app, a Heroku instance, an AWS S3 bucket), an attacker can sometimes claim that service and take control of what resolves at that subdomain. This is more common than most people expect.

Zone enumeration. Without DNSSEC and without deliberately restrictive records, DNS zones can be walked in ways that expose internal infrastructure information.

Reputational damage. A phishing campaign run off a client's forgotten domain reflects on that client. When their customers get phishing emails from what looks like them, the trust damage is real regardless of who's technically responsible.

SPF: Tell the World This Domain Doesn't Send Email

SPF (Sender Policy Framework) is a TXT record on the root of your domain that tells receiving mail servers which IP addresses are authorized to send email on its behalf.

For a domain that sends no email at all, the record is simple:

That's it. v=spf1 identifies this as an SPF record. -all means "no servers are authorized to send email from this domain, hard fail anything that claims otherwise."

Some guides will tell you to use ~all (soft fail) instead of -all (hard fail). For a domain that genuinely sends no email, there's no reason to be soft about it. -all is the right answer.

Why it's not enough on its own: SPF only validates the envelope sender (the technical "from" address that mail servers negotiate behind the scenes). It doesn't protect the display "From:" header that users actually see. That's what DMARC is for.

DMARC: The Policy Layer That Enforces Everything Else

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is what tells receiving mail servers what to do when an email fails SPF or DKIM checks. Without it, failing SPF is a yellow flag. With a reject policy in place, it's a stop sign.

For a parked domain, the record goes at _dmarc as a TXT record:

Breaking that down:

• v=DMARC1 — version identifier
• p=reject — policy for the root domain: reject email that fails authentication
• sp=reject — policy for subdomains: same rule applies to anything.yourdomain.com
• adkim=s — strict DKIM alignment (the signing domain must exactly match the From domain)
• aspf=s — strict SPF alignment (same requirement for SPF)

The sp=reject piece is important and often missed. If you set a reject policy on the root domain but don't set one for subdomains, an attacker can shift to spoofing from mail.yourdomain.com or support.yourdomain.com and your DMARC policy won't catch it.

You can optionally add a rua= tag pointing to an email address or reporting service to receive aggregate DMARC reports. For parked domains, that's more maintenance overhead than it's worth unless you want visibility into spoofing attempts.

DKIM: Null the Key

DKIM (DomainKeys Identified Mail) works by signing outgoing email with a private key, and publishing the corresponding public key in DNS so recipients can verify the signature. If a domain doesn't send email, it has no DKIM keys, which means there's nothing for receivers to validate against.

You can explicitly publish a null DKIM record to signal that no valid signing keys exist for this domain. The record goes at *._domainkey:

The empty p= value indicates a revoked or intentionally absent key. Any email claiming to carry a DKIM signature from this domain will fail validation.

This one is less universally deployed than SPF and DMARC, but it costs nothing and adds another layer to the signal.

MX Records: Remove Them If They're Not Needed

If the domain doesn't have an email service, it shouldn't have MX records pointing at mail servers. MX records sitting around from an old email setup, or inherited from a previous owner, tell the world that this domain is set up to receive mail.

Check for MX records and remove any that aren't actively in use. If a domain has genuinely never had email, it may have no MX records at all, which is fine. If they're there and shouldn't be, clean them up.

One nuance: some services use a null MX record to explicitly signal that a domain accepts no mail. This is defined in RFC 7505 and some mail servers will respect it. It's a good practice if you want to be explicit:

CAA Records: Lock Down Certificate Issuance

CAA (Certification Authority Authorization) records control which certificate authorities are permitted to issue SSL/TLS certificates for a domain. Without them, any CA can issue a certificate for your domain if they can pass their validation check.

For a parked domain where you don't want any certificates issued, add two CAA records at the root (@):

issue controls standard certificate issuance. issuewild controls wildcard certificates. The flag value 0 means non-critical (standard). Setting both to ";" (an empty policy value) tells compliant CAs not to issue any certificates for this domain or its subdomains.

This matters because certificate issuance is one of the mechanisms used in subdomain takeover attacks. Locking it down removes one more lever.

HTTPS and A Records: Don't Leave the Door Ajar

If the domain isn't serving a website, think carefully about what your A and AAAA records are pointing to. A record pointing at a deprovisioned cloud resource is the setup for subdomain takeover. A record pointing at nothing useful is just noise.

Options:

• Point A records to 0.0.0.0 (or remove them entirely if no web presence is intended)
• If the domain is parked at a registrar's parking page, understand that those pages often serve ads on your client's domain name, which isn't always a great look
• If you want a clean "this domain is intentionally parked" experience, point it to a simple static page you control that says as much

The same logic applies to any CNAME records pointing at old SaaS services. If that Heroku app or Azure Static Web App instance doesn't exist anymore, the CNAME pointing to it is a liability.

The Minimum Viable Hardened Parked Domain

For a domain with no email, no website, no active services, here's the baseline record set:

Six records. That's the baseline. None of them are complicated, but all of them need to actually be there.

The Scale Problem

That's where the operational complexity comes in for MSPs.

A single parked domain isn't a big lift. The challenge is that most MSPs are managing dozens of client organizations, each of which has multiple domains, some actively used, some not. Identifying which domains are hardened, which are partially hardened, and which have nothing in place is not something you can do manually across a full client base without a significant time investment.

And DNS is spread across multiple registrars and DNS providers. One client might have domains at Namecheap, another at GoDaddy, a third split between Cloudflare and Porkbun. There's no single place to look.

That's the operational gap that Unified DNS was built to close. It pulls together DNS zones from across all your providers into one place, runs DNS Security Assessments that specifically check for SPF, DMARC, DKIM, DNSSEC, and CAA records, and flags gaps across your entire client base in one view.

The goal isn't to make you a DMARC expert for every client. It's to make sure nothing slips through because nobody was looking at it.

If you want to see what that looks like against your actual client DNS, get started here.

Zoe Montague is the founder of Silverfern Technology Consultants and the creator of Unified DNS, a DNS management platform built for MSPs.