What steps can be taken to combat phishing attacks using cousin domains?
Published 3 Aug 2025
Updated 20 Oct 2026
12 min read
Summarize with
Updated on 20 Oct 2026: We added inbound lookalike filtering and clarified DMARC reporting limits, no-mail records, and incident response.
Combat cousin-domain phishing with brand-abuse response and email authentication. Protect every domain you own, then detect lookalikes, collect evidence, report abuse, and warn people being targeted.
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 DMARC does not stop cousin domains
A cousin domain, also called a lookalike 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 requests rejection when neither SPF nor DKIM produces a passing result with the required 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.
Cousin-domain phishing response: collect evidence, report abuse, submit to blacklists, and warn targets.
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. DMARC requires a passing SPF or DKIM result whose domain matches the visible From domain under the policy's strict or relaxed matching rules. For domains that do not send mail, publish records that make that intent clear.
Suped's DMARC monitoring helps teams review sending sources and authentication failures before enforcement. These reports cover mail using your domains in the visible From address; they do not reveal all messages sent under an attacker's separate cousin domain.
Example records for a domain that sends and receives no maildns
example.com MX 0 . example.com TXT "v=spf1 -all" _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.net; 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 working report mailbox on a separate domain and authorize external reporting. The null MX (0 .), defined in RFC 7505, declares that the domain receives no mail; do not publish it on a domain with legitimate recipients or alongside other MX records.
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: Use Suped's product to review authentication failures and track sender fixes before enforcing DMARC.
Filter cousin-domain email before it reaches users
Configure your inbound mail provider or secure email gateway to detect domain impersonation even when authentication passes. Protect your own domains and important supplier domains.
- Enable lookalike and display-name detection. Compare the full From and Reply-To domains with approved domains, and quarantine suspicious matches for review.
- Block confirmed malicious domains and URLs locally, then search delivery logs to find and remove copies that already reached mailboxes.
- Keep URL inspection and attachment scanning active. Use DNS or web filtering to block known phishing sites after delivery.
- Review false positives against legitimate suppliers. A passing SPF, DKIM, or DMARC result must not bypass impersonation checks.
The UK NCSC's phishing guidance recommends server-side filtering and blocking access to known malicious websites, with rules tuned to avoid losing legitimate email.
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 brand-related words (combosquatting), 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. In example.com.login.example.org, the registered domain is example.org; the familiar name at the left does not make it an example.com site.
Prioritise a domain that closely matches the brand and has copied web content, a login form, or user reports. Recent registration is a useful signal, but older domains can also be repurposed for phishing. MX records indicate mail reception setup; a domain without MX records can still send email. 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 new lookalike with a copied careers page warrants investigation before a customer forwards a message.
Evidence bundle
- Timestamp: Record when the domain, message, URL, and web page were observed.
- Headers: Save the original .eml message with full headers so investigators can trace the sending infrastructure.
- 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. Send website abuse to the host and sending abuse to the mail provider while the registrar reviews the domain.
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 prompt mitigation of documented phishing. Explain the impersonation and include the attack evidence.
- 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.
Use Suped's embedded blocklist checker to check the blacklist data it supports after submission. A clean result does not prove that a cousin domain is safe, and a listing does not confirm that email or web access is blocked everywhere.
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.
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 send email from addresses ending in @example.com. We do not ask candidates to buy equipment, send bank details over chat, or pay application fees. Report suspicious recruiting messages to security@example.com.
|
|
|
|---|---|---|
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". Train staff to expand the full sender address and inspect the actual link destination. Use a saved bookmark or known website for sign-in.
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. Keep browsers and devices patched, and use unique passwords to limit the impact of credential theft.
- 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: After credential exposure, revoke active sessions, reset the affected password, and review sign-in logs, mailbox rules, and app permissions. If a file ran, isolate the device. If money moved, contact the bank immediately and request a transfer recall.
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 clean DMARC program helps receivers detect unauthorized use of your real domain. Pair authentication with domain monitoring and incident response.
DMARC policy options
Use reports to decide when to change policy on legitimate sending domains.
Monitor
p=none
Collect reports; request no DMARC-based delivery action.
Quarantine
p=quarantine
Request spam-folder treatment for messages that fail DMARC.
Reject
p=reject
Request rejection for messages that fail DMARC.
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 review DMARC reports, monitor authentication and blocklist status, manage hosted policies, and hand findings to the incident team. DMARC visibility depends on receiving providers' report schedules, so use gateway alerts and user reports for immediate cousin-domain response.
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 view
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 view
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
Track response and takedown outcomes
Assign an incident owner and track detection, internal blocking, provider responses, and confirmed takedowns. Recheck message delivery logs and related domain variants after each action. A removed website or a blacklist listing alone does not prove the campaign has ended.
Legal action has a place when the domain is persistent, high-impact, or tied to a clear trademark case. Continue technical abuse reports, local blocking, and target warnings while any legal action proceeds.
Frequently asked questions
DMARC helps participating receivers reject messages that fail authentication with the required domain match for your real domain. It does not stop a separate lookalike domain that the attacker owns and authenticates. Your DMARC reports do not show all mail sent under those unrelated domains.
Buy the obvious high-risk names when the cost makes sense, but do not rely on defensive registration alone. Attackers can create too many variants.
Include the domain, URLs, full headers, screenshots, timestamps, brand evidence, and a short description of the harm.
Yes. They do not replace takedowns, but they can reduce reach while registrar and hosting reports are pending.
Use legal action for repeat, high-impact, or trademark-heavy cases. For active campaigns, report and warn first.
Report it immediately, revoke active sessions, reset the affected password, review sign-in logs, mailbox rules, and app permissions, and change the password anywhere it was reused. Contact the bank immediately if a fraudulent payment was made.
