# Domain Verification for Random-Looking Sender Domains

The triage collector (`imap_triage.py`) flags sender domains as suspicious when the `@domain` part matches the `RANDOM_LABEL_RE` pattern (e.g. letter-digit mixes, long lowercase strings). This produces false positives when a legit company owns a domain that happens to look like a random label.

## UDRP-transferred domains

A domain that looks like `statefarmservice.com` (brand+service+generic TLD) was registered by a cybersquatter, but may now be legitimately owned by the brand after a successful UDRP proceeding.

### Verification checklist

When a triage job flags `"random_looking_sender_domain"`:

1. **WHOIS registrar:** If the registrar is **MarkMonitor** (or CSC, CSC Corporate Domains), the domain is likely owned by a large brand — MarkMonitor is a brand-protection registrar, not a consumer registrar.
2. **DNS inspection:**
   - Check SPF record (`dig +short TXT domain`): does it include `amazonses.com` or other enterprise ESPs? Legit corporate sending often goes through Amazon SES, Salesforce, etc.
   - Check MX record: enterprise-grade inbound providers confirm corporate ownership.
2. **UDRP search:** Search `"<domain>" + "UDRP" + "Forum"` or `"<domain>" + "ADR"` to find prior UDRP decisions. The Forum (adrforum.com) is a common UDRP provider.
3. **Content cross-check:** Does the email reference specific policy numbers, agent names, or account details that match the recipient's real accounts? State Farm email with policy `1151329-SFP-11` and agent Chris Looney (GA license) in Roswell, GA is internally consistent — a scammer wouldn't have the policy number/agent combo right.
4. **MarkMonitor hint:** If whois shows `MarkMonitor Inc.` as the registrar, the domain is almost certainly brand-protected and legitimate. MarkMonitor is not a domainer registrar.

### No-data calls

If `whois` is unavailable or the TLD doesn't support whois freely, use web search for UDRP decisions as the primary verification path.

### Pitfall: don't over-correct

The `RANDOM_LABEL_RE` heuristic is intentionally broad — it catches genuine phishing domains. Only override it after positive verification (UDRP decision + MarkMonitor registrar + matching policy details).

## Example: statefarmservice.com

| Check | Result | Signal |
|-------|--------|--------|
| Registrar | MarkMonitor Inc. | ✅ Brand-protection registrar |
| SPF | `include:amazonses.com` | ✅ Enterprise ESP |
| UDRP decision | FA1904001840173 — transferred to State Farm, May 2019 | ✅ Won by brand |
| Content | Policy 1151329-SFP-11, 2022 KIA RIO, Agent Chris Looney GA-3191967 | ✅ Real agent matches real policy |
| **Verdict** | **Legitimate** | |

### How to investigate UDRP decisions

- Web search: `"statefarmservice.com" UDRP` or `site:adrforum.com "statefarmservice.com"`
- The Forum (adrforum.com) publishes all UDRP decisions
- Look for "TRANSFERRED from Respondent to Complainant" in the decision

## When to update the triage script

Do NOT add UDRP-verified domains to `KNOWN_LEGIT_DOMAINS` — that list is for domains that are *obviously* the company's primary domain (e.g. `statefarm.com`, not `statefarmservice.com`). The triage script's `random_looking_sender_domain` heuristic is intentionally conservative; override it on a per-message basis via `--mark UID legit "reason"` rather than whitelisting.