
The practical answer is to treat cousin-domain phishing as a brand-abuse incident, not only an email-authentication problem. Lock down every domain you own with DMARC, SPF, and DKIM, then add fast detection, evidence collection, registrar abuse reports, hosting takedown requests, blacklist and blocklist submissions, public warnings, and employee or customer education.
DMARC stops direct spoofing of your real domain. It does not stop an attacker registering a similar domain such as example-careers.com, examplejobs.com, or examp1e.com and sending authenticated email from that domain. That means I start with authentication, but I do not stop there.
- Protect owned domains: Move all legitimate sending domains toward DMARC enforcement and monitor failures daily.
- Find lookalikes early: Watch for newly registered domains that copy your brand, hiring terms, product names, and executive names.
- Disrupt delivery: Submit malicious URLs and domains to relevant blocklist (blacklist) intake channels and mail security feeds.
- Warn targets: Publish a clear notice on the page attackers imitate, especially careers, payroll, billing, and support pages.
The hard limit
You cannot publish a DNS record that prevents criminals from registering every similar name. The goal is to reduce credibility, shorten the life of each attack domain, and make repeat attacks easier to spot.
Why cousin domains bypass normal checks
A cousin domain is a separate domain that looks related to your real brand. The attacker is not sending as your exact domain. They control a different domain, publish their own SPF and DKIM records, and pass authentication for that domain. The defense needs an operational plan because the fake domain is technically separate from yours.
Direct domain spoofing
- Domain used: The visible From domain is your real domain.
- DMARC impact: A reject policy tells receivers to reject mail that fails the domain match.
- Main fix: Authenticate legitimate senders and move the policy to enforcement.
Cousin-domain abuse
- Domain used: The visible From domain is a similar domain the attacker owns.
- DMARC impact: Their mail can pass DMARC for their own deceptive domain.
- Main fix: Detect, report, block, warn, and keep your real domains clean.
That difference matters. If the attacker sends from careers@example.com and fails DMARC, your DNS policy gives receivers a clear instruction. If the attacker sends from careers@example-hiring.com and passes checks for that domain, receivers need brand, reputation, content, URL, and user-reporting signals to make the right decision.

Flowchart showing the response path for a lookalike-domain email abuse case.
Start with the domains you own
The first job is to remove easy impersonation paths. Every real sending domain, subdomain, and parked domain needs a clear owner, a known sending purpose, and a DMARC plan. For domains that send mail, the visible From domain should match either SPF or DKIM. For domains that do not send mail, publish records that make that intent clear.
This is where DMARC monitoring matters. Aggregate reports tell you who is sending as your domains, which sources pass, and which senders need fixing before enforcement.
Example no-mail DMARC recorddns
_dmarc.example.com TXT "v=DMARC1; p=reject; pct=100;" _dmarc.example.com TXT "rua=mailto:dmarc@example.com; aspf=s; adkim=s"
Use a DMARC checker to confirm the record parses correctly before relying on it. For teams that cannot keep editing DNS for every policy change, Hosted DMARC gives a controlled way to stage policy without repeated DNS handoffs.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad domain health checker is useful after the first cleanup pass because cousin-domain incidents usually expose neglected subdomains, old vendors, and parked domains that were never set to reject.

Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Practical DMARC baseline
- Sending domains: Use monitored DMARC, DKIM signing, SPF hygiene, and gradual policy enforcement.
- Parked domains: Publish reject policies and no-mail SPF records where the domain sends nothing.
- New domains: Require authentication review before marketing, recruiting, or product teams use them.
- Suped workflow: Suped's product combines DMARC, SPF, DKIM, alerts, and issue steps in one place.
Build a cousin-domain watchlist
The next layer is discovery. I build a watchlist around the exact words attackers reuse: brand names, product names, hiring language, executive names, support terms, invoice terms, and country-specific spelling variants. Recruiting scams deserve special attention because candidates expect unfamiliar domains, calendar links, document requests, and fast-moving conversations.
Detection does not need to be perfect to help. The useful signal is a domain that appears soon after registration, uses a name close to the brand, has mail records, hosts a form, or appears inside user reports. Capture enough evidence to make an abuse desk act quickly.
|
|
|
|---|---|---|
Domain | Name and variants | Shows brand similarity |
DNS | Mail and web records | Shows active use |
Message | Headers and body | Shows abuse pattern |
Website | Screens and forms | Supports takedown |
Targets | Audience and lure | Guides public warning |
Signals to collect before reporting a cousin domain.
The watchlist should include domains that do not send email yet. A newly registered name with MX records and a careers-themed landing page is actionable even before a customer forwards a message.
Evidence bundle
- Timestamp: Record when the domain, message, URL, and web page were observed.
- Headers: Save full email headers, not only screenshots of the message body.
- Screenshots: Capture the page, form fields, logo use, and any payment or document request.
- Impact: State who is targeted and what the attacker asks the recipient to do.
Disrupt domains, hosts, and blacklist listings
Once you have evidence, move in parallel. Report to the domain registrar, the hosting provider, the mail provider, the upstream network, and the brand-abuse or security contact listed by the provider. If there is a web form, credential collection page, or hosted document, the hosting provider often acts faster than the registrar.
Also submit the domain and URLs to blacklist and blocklist intake paths. A blocklist (blacklist) listing is not the same as a legal takedown, but it can reduce delivery, trigger browser warnings, and give mail filters another signal while the domain remains live.
- Registrar report: Ask for suspension based on impersonation, fraud, and abuse of a protected brand.
- Host report: Send the URL, screenshots, timestamps, and the specific form or file used.
- Mail report: Include headers so the provider can identify the sending account or infrastructure.
- Blacklist report: Submit concise evidence to domain and URL blocklist feeds that accept abuse reports.
- Legal report: Use trademark or UDRP action for persistent domains, not as the only first response.
Blocklist checker
Check your domain or IP against 144 blocklists.















A quick blocklist checker is useful after submission because it tells the incident team whether the domain or IP has started appearing in common blacklist data. It also creates a practical checkpoint for customer support and security teams.
Reporter privacy
Use a role-based abuse mailbox and avoid sending personal details in reports. Some providers forward complaints to customers or resellers. Keep reports factual and assume the recipient can see every field.
Government guidance can help with internal response wording. The UK NCSC's phishing guidance gives plain advice on reporting, user education, and reducing harm.
Protect people while takedowns lag
Takedowns can be fast, but they are never guaranteed. Attackers rotate cousin domains cheaply. The human layer matters because it buys time when DNS, registrar, and blacklist processes lag behind the campaign.
Place warnings where targets already look for trust. For recruiting scams, update the careers page, job listings, application confirmation email, and recruiter signatures. For invoice scams, update payment pages and supplier onboarding material. For customer support scams, update the contact page and help center.
Public warning copy
We are aware of messages using similar domain names to impersonate our recruiting team. Our recruiters only use addresses ending in example.com. We do not ask candidates to buy equipment, send bank details over chat, or pay application fees.
|
|
|
|---|---|---|
Candidates | Careers page | Approved recruiter domains |
Customers | Help center | Safe contact channels |
Finance | Payment page | Invoice verification steps |
Employees | Security notice | Reporting mailbox |
Where to place warnings during an active cousin-domain campaign.
The warning should name the safe domain, the unsafe behavior, and the reporting address. Avoid vague warnings that say only "watch out for scams". People need a short verification rule they can apply under pressure.
If the attack also uses exact-domain spoofing, follow a spoofed domain response plan at the same time. Cousin-domain abuse and direct spoofing often appear together in the same campaign.
Tighten signals attackers try to copy
The strongest defense is layered. A clean DMARC program makes your real domain easier for receivers and users to trust. Brand monitoring finds domains that pretend to be you. Abuse reporting and blocklist submissions shorten the useful life of the fake domains. Clear public guidance reduces successful clicks.
DMARC policy stages
A simple way to stage enforcement on legitimate domains before pushing to reject.
Monitor
p=none
Collect reports and map real senders.
Quarantine
p=quarantine
Apply pressure after major sources pass.
Reject
p=reject
Block unauthenticated use of the real domain.
I also review message design and domain naming. If legitimate recruiting messages come from several domains, use a consistent sender pattern and explain it on the careers page. If legitimate invoices use many reply-to addresses, reduce that list. Attackers benefit when real communication already looks inconsistent.
Some messages pass SPF and DKIM while still being harmful. That is why authentication results need context, especially when forwarding, shared sending platforms, or compromised accounts are involved. The same logic applies when reviewing authenticated phishing that appears technically valid.

Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Suped's product fits this operational layer well. It brings DMARC, SPF, DKIM monitoring, hosted policy management, SPF flattening, MTA-STS, blocklist monitoring, real-time alerts, and fix steps into one workflow. For most teams, that is the most practical way to keep the owned-domain side clean while the security team handles cousin-domain abuse.
What to automate
- DMARC drift: Alert when pass rates drop, sources change, or policy weakens.
- Source changes: Flag new senders before they become deliverability or abuse problems.
- Blocklist status: Track domain and IP listings so response teams can see changes.
- MSP oversight: Use multi-tenant views when agencies manage many client domains.
Views from the trenches
Best practices
Publish a warning on the exact page attackers imitate, not only on a hidden security page.
Package headers, screenshots, DNS, and URLs before asking providers for fast action.
Keep a blacklist and blocklist submission log so repeat domains do not get lost.
Common pitfalls
Relying only on UDRP leaves active domains online while attackers rotate new names.
Submitting weak evidence slows abuse desks and leads to repeated clarification requests.
Using personal mailboxes for reports exposes staff and makes follow-up ownership unclear.
Expert tips
Create role-based abuse mailboxes and templates before the next lookalike campaign.
Watch recruiting and support terms because those lures make unfamiliar domains seem normal.
Treat messenger apps and email together when the same fake brand domain appears in both.
Expert from Email Geeks says legal action can work, but cost and jurisdiction make it a poor first response to routine phishing.
2023-09-14 - Email Geeks
Marketer from Email Geeks says submitting cousin domains to URL blacklists is often the main practical action after evidence is collected.
2023-09-14 - Email Geeks
What I would do next
The right sequence is simple: enforce DMARC on owned domains, monitor every legitimate sender, create a cousin-domain watchlist, prepare abuse evidence, report to registrars and hosts, submit to blacklist and blocklist channels, and warn the people being targeted.
Legal action has a place when the domain is persistent, high-impact, or tied to a clear trademark case. It is too slow as the only defense for routine cousin-domain phishing. The fastest wins usually come from making the fake domain less deliverable, less trusted, and less useful.
Suped's product is useful for the part teams can control every day: authentication visibility, hosted DMARC, SPF flattening, hosted MTA-STS, blocklist monitoring, alerts, and clear fix steps. That keeps the real domain trustworthy while the incident team works on the fake domains.

