What steps can be taken to combat phishing attacks using cousin domains?
Published 3 Aug 2025
Updated 12 Aug 2026
11 min read
Summarize with
Updated on 12 Aug 2026: We updated this guide for RFC 9989 and added practical safeguards for lookalike-domain clicks.
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 enforcement helps participating receivers block 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. Authentication comes first, but it is only one layer.
- 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 participating 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 participating 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 the SPF identity or the DKIM signing domain. 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 recordsdns
example.com TXT "v=spf1 -all" _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; aspf=s; adkim=s"
Publish one DMARC TXT policy at each _dmarc name. RFC 9989 makes the pct tag historic, so omit pct=100. Multiple DMARC policy records returned for one name are discarded instead of being joined into one policy.
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.
?
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 often 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
Build the watchlist around the 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.
Map typosquatting, homoglyph and internationalized domain name (IDN) variants, letter or number substitutions, added words, swapped top-level domains (TLDs), and deceptive subdomains. Defensive registration can cover a small set of obvious, high-risk variants, but it cannot cover every permutation.
Detection does not need to be perfect to help. Prioritise a recently registered domain that closely matches the brand and also has MX records, active web content, a login form, or user reports. Similarity alone does not prove abuse, so capture evidence that will help 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.
Report and disrupt cousin domains
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 and give mail or web filters another reputation 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.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftA 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 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.
Limit harm when someone clicks
Some cousin-domain messages will reach users before filters or takedowns catch up. Design account and payment controls so one click, password entry, or urgent request does not complete the attack.
- Use phishing-resistant MFA: Prefer FIDO/WebAuthn passkeys or hardware-backed security keys for email, SSO, finance, and administrator accounts. SMS codes and approval prompts provide weaker protection against real-time proxy phishing.
- Keep password managers domain-bound: Autofill should occur only on approved domains. A missing autofill prompt is a useful warning on a lookalike site.
- Verify sensitive requests out of band: Confirm bank-detail changes, payroll updates, gift card requests, and access changes through a known phone number or approved internal channel, not contact details in the message.
- Plan the post-click response: Revoke active sessions, reset credentials, review mailbox rules and sign-in logs, isolate affected devices, and notify exposed partners.
Make reporting safe and fast
Give users a quick way to report a suspicious message or a click, and confirm what the response team did. A blame-free process helps people report mistakes early enough to revoke sessions or stop a payment.
Make legitimate email easier to verify
A layered defense works best. 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.
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 harmful messages pass SPF and DKIM because they authenticate against a domain the attacker controls. Authentication proves control of an identifier and, for DMARC, the required domain match with the visible From address. It does not prove that the sender or request is trustworthy.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Suped's product supports the owned-domain part of this response. Teams can monitor DMARC, SPF, DKIM, and blocklist status, receive real-time alerts, manage hosted policies, and hand clear findings to the incident team handling a cousin domain.
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
Recommended response sequence
The response sequence is straightforward: 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, warn the people being targeted, and contain any successful click.
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.
