## TL;DR
Email risk scores go stale when domains change hands or age out, and the agent keeps trusting a cached verdict. Treat email signals as perishable: timestamp every signal, expire them on a schedule, and re-verify on domain events like registrar changes. A stale signal should read as unknown, never as safe, because unknown triggers caution and safe triggers nothing.

```text
fraud agent used stale email risk signal after domain change and failed
```

## Use this when
- Fraud rises from aged or repurposed domains the scorer calls clean.
- Email risk data is cached with no expiry.
- Domain ownership changed and the old reputation stuck.

## Not for this skill when
- The email signal was wrong at fetch time. That is a provider quality problem.
- The agent never fetched the signal at all. That is a wiring problem.

## Steps
1. Timestamp every email risk signal and set a TTL: high-risk domains expire faster. Verify: a cached signal older than its TTL is never used in scoring.
2. Re-verify on domain events: registrar change, new mail records, or age threshold crossing. Verify: a domain that changed hands gets a fresh lookup before the next score.
3. Default stale to unknown: expired signals contribute nothing, and the model knows they are missing. Verify: scoring with an expired signal matches scoring with no signal.
4. Monitor signal age in production: alert when the share of expired signals in scoring rises. Verify: a dashboard shows signal freshness over time and pages on decay.

## Variant phrasings
### email reputation stale after domain transfer
Domain-event phrasing.
### cached email risk score outdated
Cache phrasing.
### domain age signal not refreshed
Freshness phrasing.

Compatibility: Works with any email-risk provider. The TTL pattern lives in the agent's signal layer, not the provider.

## Why it happens
Reputation is cached for performance and nobody sets an expiry, so a domain that was clean two years ago stays clean forever in the cache. Attackers buy aged domains precisely because the reputation sticks.

## Edge cases / pitfalls
- Re-verification costs API calls. Budget the refresh rate against the provider quota.
- Some domains change hands without a visible registrar event. Age-based expiry is the backstop.
- Unknown signals shift model behavior. Validate the model with missing-signal inputs.
- Log every expiry-driven re-fetch, or debugging the refresh loop gets circular.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KacHjBZugjzBbuc7-GVddg