Brand Protection — Domain Management

Attackers who cannot take control of a brand's actual domains do the next best thing: register a variant of them, or spoof mail from them. Domain management for brand protection has three layers: minimum security requirements every organization should meet, increased measures as the brand matures, and attack-vector-specific mitigations. Authentication mechanics live in SPF, DKIM, and DMARC; this article covers the portfolio-management discipline around them.

Minimum security requirements

Requirement	Practice
Domain inventory	Register every domain the company owns (a spreadsheet suffices; a dedicated tool is better — it can double for certificate and nameserver management). For each domain: written purpose, and the named people responsible for its security and maintenance. Keep it current as domains and staff are added, deleted, or changed. Track how each domain is hosted and configured in DNS, and ensure any outsourced provider integrates with your DNS infrastructure provider.
Protect registrant accounts	Treat domain-name protection as a standing part of security policy. Keep registrant account credentials private; recovery only by the most senior domain-administration staff under extreme circumstances. On staff changes, rotate the corresponding account credentials — especially passwords. Never use a transfer-contact email address as the login for domain self-administration pages (hijackers look up transfer contacts via WHOIS and routinely test whether that address doubles as the username). Use role addresses, not personal addresses, for contacts. MFA on every domain account.
Current contact info	Any change to company name, legal address, phone, or email must trigger an update cycle with all registrars. Registrars are a key defense against hijack attempts; current details put them in the best position to protect you.
Official policies	Codify decisions and processes — especially domain decommissioning/reconfiguration, change-control policy, and which departments have authority to make changes.
Document everything	Policies, registers, and regular staff communication keep the business prepared for incidents and able to accept legitimate changes quickly.

Increased security measures ("quick wins")

• Role aliases for domain control and notifications — send registrar/DNS notifications to a role account (domainregistrar@example.com), not an individual's mailbox, so notifications survive turnover, vacation, and leave.
• Choose the DNS authority deliberately — local open-source authoritative servers, an on-premises appliance, or a cloud authoritative DNS service each trade off differently on DNSSEC, email-authentication, and security support. Audit the resulting configuration with free tools (e.g., Zonemaster, https://zonemaster.iis.se/en/).
• Choose the right registrar — registrars specialize (budget/hobbyist, bulk-speculator, language-targeted). Register production/core domains with a corporate registrar that specializes in protecting critical assets; a retail registrar may be fine for defensive registrations. Minimum feature set to require: redundant infrastructure, protection against accidental expiry, domain monitoring (is it up and responding?), 2FA on the management console, a registrar lock service (the combination of clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibited, preventing unauthorized deletion, transfer, or modification), and DNSSEC support.
• Defensive registration — proactively register TLD variants of the brand (brand.co.uk when you are brand.com) and create a policy for high-risk domains that will never be used in production: lookalike names, typos, common abbreviations/shortenings (e.g., "BofA" for "Bank of America"), combined with commonly abused terms like "login" or "account", and any vector you have already had to combat. You cannot register an infinite number — prioritize, set a budget, re-evaluate from experience, and coordinate with your monitoring and takedown programs. What you can't buy based on risk tolerance and budget, you should monitor.
• Consolidate SSL/TLS certificate management with DNS management — same team, similar legal/technical challenges. Monitor certificate transparency for lookalike certificate registrations, not just lookalike domains. Publish CAA records to prevent unauthorized certificate issuance for your domains.
• EPP status codes and locks — set clientTransferProhibited, clientDeleteProhibited, clientUpdateProhibited on organizational domains. Beyond that, consider registry lock (out-of-band protection against unauthorized change/deletion, arranged through the registrar) and, above that, registrar lock services requiring out-of-band confirmation before any change. After locking, routinely re-check WHOIS to confirm the domain is still locked and that nameservers, DNS configuration, and contacts have not been modified without your knowledge — consider a third-party change-alerting service.
• Back up DNS configuration — secure storage of DNS config means you can always revert (e.g., after account compromise). Build urgent domain/DNS restoration into business-continuity planning and tabletop exercises; check whether insurance covers domain/DNS incidents; fold domain hijacking into incident response.
• Monitor for abusive third-party domains — commercial services do this reliably; not doing it exposes the brand to significant abuse.

Attack vectors and mitigation

Squatters, lookalike domains (homographs), and encroachments

Monitor new-domain registrations for lookalike names (many brands outsource this to a managed service). Data sources:

• ICANN CZDS (Centralized Zone Data Service) — zone files for all gTLDs, but not ccTLDs; add ccTLD zone files per your threat landscape.
• SSL certificate registrations (certificate transparency logs).
• Paid feeds of newly registered / newly observed domains.

Discovered lookalikes must be triaged as benign vs. malicious. The kit's definition: a malicious domain is one used for malware distribution, botnet command-and-control, phishing, business email compromise, or spam. A bad-faith trademark registration that is not also used for those activities is brand-offensive, not malicious — the distinction determines which remediation path works.

Class	Path	Notes
Malicious (proof of phishing, credential theft, malware, botnet C2, spam)	Takedown request to the domain's registrar (found via WHOIS). Provide detailed evidence: screenshots of offending content, a sample lure email with full headers. If hosting is a separate entity, contacting the host may kill the content faster. If the registrar is non-responsive, escalate to ICANN (which accredits registrars).	ICANN-accredited registrars normally only treat a domain as malicious if it was registered and used for phishing/malware/botnet C2. Compromised (legitimate but hacked) domains are a different problem — suspension is usually the wrong remedy. After takedown, monitor for resumed activity; alternatively purchase the domain (some registrars will transfer it to the brand), useful for alerting victims and gathering statistics.
Brand-offensive (trademark infringement, non-malicious)	Same takedown path works only if phishing/malware/C2 is also involved (gTLDs; ccTLD processes depend on each ccTLD's ToS). Otherwise: informal appeal to the owner (identified via hosted content or WHOIS) — unless the registrant appears malicious — then formal UDRP or URS proceedings, or civil litigation. UDRP/URS cost money and take a few months, but success can transfer control of the domain to the brand.	Pure trademark disputes are legal matters — see compliance for the KB's legal-jurisdiction articles and involve trademark counsel.
Suspicious but unproven (or failed takedowns)	Purchase, or monitor for changes in hosted content and DNS records.	Best practice: purchase a limited number of highly suspect or potentially useful domains; monitor the rest via technology plus human review.

Spoofing (for email)

Spoofing = mail that appears to come from the legitimate domain (or a near-miss like microsoftt.com) but does not; an attacker needs no control over a domain to emit spoofed mail claiming to be from it. Mitigation:

• Monitor for lookalike domains (open-source toolsets or third-party vendors); on abuse, file a registrar complaint per the takedown process above.
• Authenticate every domain you own — including domains that never send mail. SPF, DKIM, and DMARC on the whole portfolio, per the M3AAWG Email Authentication BCP.
• Consider removing MX records from domains you never receive or send mail on.

Protective DNS records for non-sending and parked domains

The kit points to the M3AAWG Protecting Parked Domains BCP for the record shapes (see also the document index). For a domain (or subdomain) that sends no mail, publish all four:

Record	Value	Effect
SPF	example.com. TXT "v=spf1 -all"	No host is authorized to send mail with this MAIL FROM; receivers hard-fail forgeries.
DKIM	*._domainkey.example.com. TXT "v=DKIM1; p="	Wildcard key record with an empty public key — revokes all selectors, so no DKIM signature for the domain can verify.
DMARC	_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@yourbrand.example"	Instructs receivers to reject anything claiming the domain in the From: header; the rua address still shows you attempted abuse. Subdomains inherit p=reject by default (sp unset) — see DMARC deployment.
Null MX	example.com. MX 0 .	RFC 7505: explicitly declares the domain receives no mail, so senders fail fast instead of retrying, and the absence of MX cannot fall back to the A record.

Apply this to defensive registrations the day they are purchased — a defensively registered but unprotected cousin domain is exactly the asset a phisher wants to spoof. When a parked domain is later activated for sending, unwind these records as part of normal authentication setup and domain warm-up (sending-infrastructure practices).

Account takeover (ATO) of the registrar account

A single guessed, phished, or socially engineered credential can hand an attacker the entire domain portfolio — and hamper your own access to it. Specific dynamics:

• Email is often the only channel registrars use to notify registrants of account activity — and an attacker who controls the account can alter DNS so those notifications never arrive (e.g., when the registrant's admin/tech contact addresses are hosted in the compromised domain). Register a contact address outside your own domain so takeover notifications still reach you.
• Phishers also impersonate registrars and DNS providers to harvest registrant credentials. The usual objective is changing your nameserver IPs: control of name resolution yields access to your inbound mail, a real-time copy of your website, credential capture, and use of the domain for spam or crime.
• Domain shadowing: the stealthier variant — the attacker leaves your site and mail untouched and quietly creates new subdomains (or wholly new domains billed to your stored payment method) under their own control, e.g. login.yourcompany.com, email.yourcompany.com, pointed at attacker infrastructure. Very hard to detect because few registrars provide monitoring for new domains/subdomains added to an account. Countermeasures: use such registrar monitoring where it exists; schedule regular spot-checks of the domain-management account for recent changes; and pull passive-DNS reports of new hostnames appearing on your domains.

Mitigation checklist: MFA on all accounts; monitor for anomalous behavior (unusual logins); lookalike-domain monitoring; registrar complaint on identified abuse (takedown process above); documented mitigation processes shared with security teams.

Software vulnerability

Attackers scan registrar/administration portals for web-application vulnerabilities (e.g., SQL injection); one successful exploit can disclose credentials for many domain accounts at once. Keep software patched and run a responsible vulnerability-disclosure program.

ESP relevance

For an ESP the portfolio is larger than the corporate brand: sending domains, bounce/return-path domains, tracking domains, and per-customer delegated subdomains are all assets attackers can shadow, squat, or spoof. Cousin-domain reputation bleed and the customer-domain-delegation hierarchy are covered in sending-infrastructure practices and blocklists & Spamhaus (domain strategy for ESP customers); DMARC explicitly does not protect against lookalike domains — monitoring and defensive registration are the only controls for that gap.

Further reading named by the kit

• ICANN SSAC-044, "A Registrant's Guide to Protecting Domain Name Registration Accounts" — deeper security measures.
• ICANN Centralized Zone Data Service — https://czds.icann.org/home (gTLD zone files only).
• ICANN Trademark Clearinghouse — https://newgtlds.icann.org/en/about/trademark-clearinghouse (consult legal counsel).
• M3AAWG Protecting Parked Domains BCP — https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf