Adlerwacht

Processes

Member verification, explained

Three different things in this app are called "verification" — here's what each one actually proves.

"Verification" shows up in three different, unrelated places in this app. They're easy to conflate because they share a word, but they prove different things to different people. This page is here to keep them straight.

1. Onboarding verification — proves a sender's relay is real

This is what the onboarding process walks through: it gates whether a member's outgoing relay is allowed to route mail at all. A founding admin proves it via a send/reply round trip; an invited member proves it simply by accepting their invitation link, since only they could have received it.

An admin can force this back to an unverified state for a specific member — for example, after a suspected compromise — which immediately stops that member's relay from routing mail until they complete verification again.

2. Invitation-acceptance-as-proof — not a separate step, just how #1 works for members

There's no separate model or screen for this — it's the mechanism described above. Possessing a unique, time-limited invitation link emailed only to one address stands in for the send/reply round trip a founding admin has to do. It's mentioned separately here only because it's easy to go looking for a distinct "member verification" step that doesn't actually exist as its own thing.

3. Recipient verification — a completely different, SMS-based check

This one has nothing to do with senders or members. It only applies to organizations with the hardened (Plus) delivery option enabled, and it protects a recipient the first time they ever receive an attachment from that organization:

  1. The sending member confirms the recipient's phone number, from the pending deliveries screen (a page still to be documented here).
  2. The recipient registers a passkey — same as a normal registration — but their account stays locked until they also confirm a one-time SMS code sent to that phone number.
  3. Once confirmed, the originally held email is delivered, and that recipient is fully verified going forward — this is a one-time check per recipient, not something that repeats on every attachment.
If you're trying to figure out why an account can't do something yet, it's worth checking which of these three actually applies — a sender's relay being unverified, a recipient's phone still being unconfirmed, and an invitation not yet accepted all look similar from the outside but are fixed in completely different places.