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

Not specified by the original author.

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.

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

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

Thread query: fraud agent used stale email risk signal after domain change and failed

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.