Skip to content
LapseGuard IN DEVELOPMENTTKOResearch contact
In developmentNot protecting accounts yet

A NEW QUESTION FOR ACCOUNT RECOVERY

The domain expired. The account still trusts the address.

If someone registers that domain and receives mail for an old address, password resets can reach the wrong person. LapseGuard is being built to check registration continuity before your app sends recovery mail.

Discuss LapseGuard with TKOResearch Explore the model
FIG. 01 / RECOVERY BOUNDARY

The continuity gap

CONCEPT / NOT LIVE
01 / DOMAIN CONTINUITYILLUSTRATIVE SEQUENCE
DOMAIN
Earlier registrationPossible new registration
The account persists. The domain may not.SIGNAL TO INVESTIGATE
02 / PROPOSED PRE-DELIVERY PATHBEFORE THE SEND
01 / REQUESTRecovery beginsIn the customer app
02 / CHECKCompare continuityEvidence against account history
03 / IF POLICY REQUIRES HOLDHold before sendIndependent proof or review
Illustration only. No live data, account decisions, or tested delivery control are shown.
01 / THE PROBLEM

The account may be old.
The destination may be new.

A domain can lapse, pass through expiration, and be registered again while accounts tied to addresses at that domain remain. A reset email sent without checking continuity may go somewhere the original account holder never intended.

Domain evidence is a risk signal, not proof of who reads an inbox. The proposed control focuses on the narrow moment before a customer-controlled recovery flow delivers a secret.

02 / PROPOSED APPROACH

Check recovery risk before delivery.

The design is intentionally upstream of email delivery. These are planned capabilities, not features available today.

  1. 01
    OBSERVE

    Establish continuity

    Compare a customer domain's registration history and status to a trusted account baseline, while retaining source and observation time.

  2. 02
    REASON

    Separate signal from noise

    Treat a credible registration break differently from an MX change. Missing or stale evidence remains unknown, not silently safe.

  3. 03
    DECIDE

    Hold the email when policy requires it

    A future customer integration would request a policy outcome before sending recovery mail; a credible discontinuity could hold delivery for independent review.

03 / DESIGN BOUNDARIES

Signals, not certainty.

Good security controls are explicit about what they cannot infer. The proposal leaves these lines intact.

DNS changes are not a takeover verdict. Mail-host or nameserver changes call for context, not automatic denial.

Unknown is not safe. Unavailable or stale evidence needs an explicit customer policy, not a hidden default.

An address is not an identity. Domain observations cannot prove who controls a mailbox or replace independent verification.

THE NEXT STEP / VALIDATE THE BOUNDARY

Help validate
a pre-send check.

If your app sends password resets to customer domains, we want to compare the proposed check against your recovery flow. LapseGuard is not available as a service yet.

Contact TKOResearch