# Brand Protection — Domain Management

> Securing a domain portfolio against hijacking, lookalike/cousin-domain abuse, and spoofing — inventory, registrar/registry locks, defensive registration, monitoring, takedown paths, and the protective DNS records for non-sending and parked domains.

Source: emailmarketing.net — https://emailmarketing.net/learn/reference/brand-protection-domain-management

Your domains can be attacked even if nobody breaks into them. Attackers who cannot take control of a brand's real domains do the next best thing: they register a variant of them, or spoof mail from them. Protecting a brand's domains works in three layers: **minimum security requirements** that every organization should meet, **increased measures** as the brand matures, and **mitigations for specific attacks**.

The authentication mechanics are covered in [SPF](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/dkim) and [DMARC](https://emailmarketing.net/learn/authentication/dmarc). The practices below concern managing the domain portfolio around them.

## Minimum security requirements

| Requirement | Practice |
|---|---|
| **Domain inventory** | Record every domain the company owns. A spreadsheet is enough, but a dedicated tool is better, because it can also manage certificates and nameservers. For each domain, write down its purpose and name the people responsible for its security and maintenance. Keep the inventory current as domains and staff are added, removed or changed. Track how each domain is hosted and configured in DNS, and make sure any outsourced provider works with your DNS infrastructure provider. |
| **Protect registrant accounts** | Make protecting domain names a permanent part of security policy. Keep the credentials of registrant accounts private, and allow recovery only by the most senior domain administrators, in extreme circumstances. When staff change, change the credentials of the corresponding accounts, especially passwords. Never use a transfer contact's email address as the login for self-service domain administration pages: hijackers look up transfer contacts in WHOIS and routinely test whether that address is also the username. Use role addresses, not personal addresses, for contacts. **Multi-factor authentication (MFA) on every domain account.** |
| **Current contact info** | Any change to the company name, legal address, phone number or email address must trigger an update with every registrar. Registrars are a key defense against hijacking attempts, and current details put them in the best position to protect you. |
| **Official policies** | Write down decisions and processes, especially for retiring or reconfiguring domains, for change control, and for which departments have authority to make changes. |
| **Document everything** | Policies, registers and regular communication with staff keep the business ready for incidents, and able to accept legitimate changes quickly. |

## Increased security measures ("quick wins")

- **Role aliases for domain control and notifications**: send notifications from registrars and DNS providers to a role account (`domainregistrar@example.com`), not to one person's mailbox, so that they still arrive when staff leave, go on vacation or take leave.
- **Choose the DNS authority deliberately.** Local open-source authoritative servers, an on-premises appliance and a cloud authoritative DNS service each have different strengths in their support for DNSSEC, email authentication and security. Audit the resulting configuration with free tools (e.g., Zonemaster, https://zonemaster.iis.se/en/).
- **Choose the right registrar.** Registrars specialize: some serve budget buyers and hobbyists, some bulk speculators, some particular languages. Register production and core domains with a **corporate registrar** that specializes in protecting critical assets. A retail registrar may be fine for defensive registrations. The minimum features to require are redundant infrastructure, protection against accidental expiry, domain monitoring (is the domain up and responding?), two-factor authentication (2FA) on the management console, a **registrar lock** service (the combination of `clientTransferProhibited`, `clientUpdateProhibited` and `clientDeleteProhibited`, which prevents unauthorized deletion, transfer or modification), and DNSSEC support.
- **Defensive registration.** Register other top-level domain (TLD) variants of the brand in advance (`brand.co.uk` when you are `brand.com`). Create a policy for high-risk domains that will never be used in production: look-alike names, typos, common abbreviations and short forms (e.g., "BofA" for "Bank of America"), combined with commonly abused words such as "login" or "account", and any variant you have already had to fight. You cannot register an unlimited number, so set priorities and a budget, review them in the light of experience, and coordinate with your monitoring and takedown programs. **Whatever your risk tolerance and budget do not let you buy, monitor.**
- **Manage SSL and TLS certificates together with DNS.** The same team faces similar legal and technical challenges for both. Monitor certificate transparency logs for **look-alike certificate registrations**, not only for look-alike domains. Publish **CAA records** to prevent unauthorized certificates from being issued for your domains.
- **EPP status codes and locks.** Set `clientTransferProhibited`, `clientDeleteProhibited` and `clientUpdateProhibited` on organizational domains. Beyond that, consider a **registry lock** (protection against unauthorized change or deletion, confirmed through a separate channel and arranged through the registrar), and above that, **registrar lock** services that require confirmation through a separate channel before any change. After locking, check WHOIS regularly to confirm that the domain is still locked, and that its nameservers, DNS configuration and contacts have not been changed without your knowledge. Consider a third-party service that alerts you to changes.
- **Back up the DNS configuration.** Storing the DNS configuration securely means you can always restore it, for example after an account is compromised. Include urgent restoration of domains and DNS in business-continuity planning and tabletop exercises, check whether your insurance covers domain and DNS incidents, and include domain hijacking in 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 newly registered domains for look-alike names. Many brands outsource this to a managed service. The data sources are:

- **ICANN CZDS** (Centralized Zone Data Service): zone files for all generic top-level domains (gTLDs), but **not for country-code top-level domains (ccTLDs)**. Add ccTLD zone files according to the threats you face.
- **SSL certificate registrations** (certificate transparency logs).
- **Paid feeds of newly registered or newly observed domains.**

Each look-alike domain you discover must be classified as benign or malicious. The kit defines a **malicious domain** as one used for malware distribution, botnet command and control, phishing, business email compromise or spam. A trademark registration made in bad faith, but not also used for those activities, offends the brand without being malicious. The distinction decides which remediation path works.

| Class | Path | Notes |
|---|---|---|
| **Malicious** (proof of phishing, credential theft, malware, botnet C2, spam) | **Send a takedown request to the domain's registrar** (found through WHOIS). Provide detailed evidence: screenshots of the offending content, and a sample lure email with full headers. If the hosting company is a separate entity, contacting it may remove the content faster. If the registrar does not respond, escalate to ICANN, which accredits registrars. | Registrars accredited by ICANN normally treat a domain as malicious only if it was **registered and used** for phishing, malware or botnet C2. **Compromised domains (legitimate but hacked) are a different problem, and suspension is usually the wrong remedy.** After a takedown, monitor for renewed activity. Alternatively, buy the domain (some registrars will transfer it to the brand), which is useful for alerting victims and gathering statistics. |
| **Brand-offensive** (trademark infringement, not malicious) | The same takedown path works only if phishing, malware or C2 is also involved (for gTLDs; processes for ccTLDs depend on the terms of service of each ccTLD). Otherwise, appeal informally to the owner (identified through the hosted content or WHOIS), unless the registrant appears malicious. Then use formal **UDRP** or **URS** proceedings, or civil litigation. UDRP and URS proceedings cost money and take a few months, but success can transfer control of the domain to the brand. | Pure trademark disputes are legal matters. Involve trademark counsel, and see [compliance](https://emailmarketing.net/learn/compliance) for legal information by jurisdiction. |
| **Suspicious but unproven** (or failed takedowns) | Buy the domain, or monitor it for changes in hosted content and DNS records. | Best practice: buy a limited number of highly suspicious or potentially useful domains, and monitor the rest with technology plus human review. |

### Spoofing (for email)

Spoofing is mail that appears to come from the legitimate domain (or a near miss such as `microsoftt.com`) but does not. An attacker does not need any control over a domain to send spoofed mail that claims to come from it. Mitigation:

- Monitor for look-alike domains (with open-source tools or third-party vendors). When you find abuse, file a complaint with the registrar, following the takedown process above.
- **Authenticate every domain you own, including domains that never send mail.** Apply SPF, DKIM and DMARC across the whole portfolio, as the [M3AAWG Email Authentication BCP](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp) recommends.
- Consider **removing MX records** from domains on which you never receive or send mail.

### Protective DNS records for non-sending and parked domains

The kit refers to the M3AAWG Protecting Parked Domains BCP for the form of these records (see also the [document index](https://emailmarketing.net/learn/industry-best-practices/m3aawg-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, so receivers hard-fail forgeries. |
| DKIM | `*._domainkey.example.com. TXT "v=DKIM1; p="` | A wildcard key record with an **empty public key**. It 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"` | Tells receivers to reject anything that uses the domain in the From: header. The `rua` address still shows you attempted abuse. Subdomains inherit `p=reject` by default (when `sp` is not set). See [DMARC deployment](https://emailmarketing.net/learn/authentication/dmarc-deployment). |
| Null MX | `example.com. MX 0 .` | RFC 7505. It declares explicitly that the domain receives no mail, so senders fail immediately instead of retrying, and the lack of an MX record cannot fall back to the A record. |

Apply these records to defensive registrations on the day you buy them. A cousin domain that was registered defensively but left unprotected is exactly what a phisher wants to spoof. When a parked domain is later brought into use for sending, remove these records as part of normal [authentication setup](https://emailmarketing.net/learn/industry-best-practices/m3aawg-email-authentication-bcp) and domain warm-up ([sending-infrastructure practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices)).

### Account takeover (ATO) of the registrar account

A single credential that is guessed, phished or obtained by social engineering can give an attacker the **entire domain portfolio**, and make it harder for you to access it yourself. Specific points:

- **Email is often the only channel registrars use to tell registrants about account activity.** An attacker who controls the account can change DNS so that those notifications never arrive, for example when the registrant's administrative and technical contact addresses are hosted in the compromised domain. **Register a contact address outside your own domain**, so that notifications of a takeover still reach you.
- Phishers also impersonate registrars and DNS providers to collect registrants' credentials. The usual goal is to change your **nameserver IPs**. Control of name resolution gives access to your inbound mail, a real-time copy of your website, captured credentials, and use of the domain for spam or crime.
- **Domain shadowing** is a stealthier variant. The attacker leaves your site and mail untouched, and quietly creates new subdomains under their own control (or entirely new domains, billed to your stored payment method), for example `login.yourcompany.com` or `email.yourcompany.com`, pointed at the attacker's infrastructure. It is very hard to detect, because few registrars offer monitoring for new domains or subdomains added to an account. Countermeasures: use that monitoring where the registrar offers it, 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, monitoring for unusual behavior (such as unusual logins), monitoring for look-alike domains, a complaint to the registrar when you identify abuse (following the takedown process above), and documented mitigation processes shared with security teams.

### Software vulnerability

Attackers scan registrar and administration portals for vulnerabilities in the web application (e.g., SQL injection). One successful exploit can reveal the credentials of 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 and return-path domains, tracking domains, and subdomains delegated by each customer are all assets that attackers can shadow, squat or spoof. [Sending-infrastructure practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices) covers how the reputation of cousin domains spills over and how customer domain delegation is organized, and [blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) covers domain strategy for ESP customers. [DMARC](https://emailmarketing.net/learn/authentication/dmarc) explicitly does not protect against look-alike 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", for more thorough 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