Heir addresses are never verified, and a typo only surfaces at claim time

[Jolah1]

What's wrong

There is no heir equivalent of owner_contact_verified_at. No column, no flow, nothing anywhere in the codebase. heir_contact_ciphertext is sealed at setup and never tested.

So a mistyped heir address is discovered the day the claim link fires. That is the one moment it matters and the one moment the owner is not around to fix it. The whole product does exactly one thing, and this is the way it silently fails to do it.

Mainnet has 16 vaults, all with an email heir channel, none confirmed reachable.

The constraint

We cannot just copy the owner flow. The heir usually should not learn the vault exists until the owner chooses to tell them. A "confirm your address" email is a disclosure.

That constraint only blocks half the problem though. There are two questions and they separate cleanly:

1. Is this address deliverable? Answerable without the heir doing anything.
2. Does it belong to the intended person? Needs the heir to act, and therefore needs the owner's consent to disclose.

Proposed design

Tier 1 — syntax and domain check at setup. No email, no disclosure.

Most real typos are gmial.com, gmail.con, yaho.com, a missing TLD. An MX lookup on the domain plus strict address parsing catches nearly all of them at the moment the owner types it, while they can still fix it. Zero heir involvement. This is the cheapest large win and should land first.

Tier 2 — the practice drill is already the verification mechanism.

drill::start_drill is owner-initiated and already emails the heir. With delivery feedback now landing (#322), an email.delivered verdict on that invite proves the mailbox exists. Set heir_contact_verified_at on delivery, not on completion. Nothing new is sent, no new disclosure decision, and the owner already controls when it happens.

This means reframing the drill in the UI from "practice" to "confirm your heir can be reached" so owners actually run it.

Tier 3 — identity. Drill completion already proves the right person holds the address. That part exists.

Also needed

• Alarm the owner when a heir-directed message gets a negative verdict, which fix(server): don't let a retried callback alarm twice or bury a bounce #324 now does generically, but the owner-facing copy should name what it means: your heir cannot be reached, fix this now.
• Surface heir reachability on the dashboard. Right now the owner has no way to know.
• Consider blocking timelock_started on an unverified heir, though that interacts with Owner email verification is a flag nobody enforces #326 and should be decided together.

Related

#326 is the owner-side half. Found together while investigating mistyped addresses on the Resend suppression list.

[Jolah1]

Tier 1 is up as #329, minus the DNS half. Recording why here so it isn't relearned.

An MX check was written and removed. Two reasons:

1. It cannot catch the case that matters. gmial.com is a registered domain with real MX records, so DNS reports it deliverable. Every address on our bounce and suppression list was a well-formed misspelling of a real domain. Only the edit-distance suggestion catches those, and that is what feat: question a mistyped address before it becomes an heir's problem #329 ships.
2. It could not be verified. Against a systemd-resolved stub listener, hickory-resolver returned Unknown for known-good and known-bad domains alike, intermittently, taking 4-15s. Unknown passes, so the check would have looked present and done nothing.

Two findings worth keeping for whoever wires DNS up properly:

• RFC 7505 null MX. MX 0 . is how a domain states it accepts no mail, and example.com publishes exactly that. It is a non-empty answer, so counting answers reads it backwards — the first implementation called example.com deliverable. Worse, treating it as merely "no MX" then falls through to the implicit-MX rule and lets an A record override an explicit refusal.
• RFC 5321 §5.1 implicit MX. A domain with address records and no MX is still deliverable. A missing MX is not grounds for rejection, so the fallback chain has to be MX → A → AAAA, with only NXDOMAIN and null-MX as refusals.

Anything built on this needs verifying against Fly's resolver, not a laptop, and must treat resolver failure as a pass. Blocking vault creation on a network round trip is not acceptable either way; the advisory endpoint POST /contact/check is the right home for it.

Still open on this issue: Tier 2, where an email.delivered verdict on a practice-drill invite becomes heir verification (now possible since #325), and Tier 3.