Security
Two-factor authentication, passkeys, and sessions.
Everything here lives under Settings > Security and concerns signing in to SendSets. For authenticating the domains you send from (SPF, DKIM, DMARC), see Deliverability.
How signing in works
| Method | Steps |
|---|---|
| Password | Email, password, a 6-digit emailed code, then your authenticator code if 2FA is on |
| Passkey | Pick the passkey and unlock with Touch ID, Face ID, Windows Hello, or a security key. No password, no emailed code |
| Google / Apple | One tap, natively in the iOS app. No emailed code, since the provider already verified you |
A first sign-in with a new address via Google or Apple creates your account, workspace, and free trial automatically.
Accounts created through an external sign-in provider have no password initially. Trying password sign-in returns the same invalid-credentials response as an incorrect password. Continue with your provider, or use Forgot password to set a password before signing in with it.
Passwordless by design
A passkey is tied to your device and unlocked with biometrics or a PIN, so it already proves both something you have and something you are or know. That is why it skips the emailed code.
Two-factor authentication
2FA (TOTP) adds a rotating 6-digit code to every password sign-in, so a stolen password alone is not enough. Any standard authenticator works: Google Authenticator, 1Password, Authy.
Enable 2FA runs three steps: copy the setup secret into your authenticator, enter a code to confirm it works (it verifies as soon as the sixth digit lands), and save your one-time recovery codes.
Recovery codes are shown only once
They are displayed a single time during setup, each works once, and they are your way back in if you lose your authenticator. Store them in a password manager before closing the wizard; Copy all grabs them at once.
At sign-in, the code submits automatically once six digits are in. Without your authenticator, choose Use a recovery code.
Disabling asks for a current code or a recovery code first. With 2FA off you are protected only by your password plus the emailed code, and setting it up again issues a fresh secret and new recovery codes, invalidating the old ones.
Passkeys
A passkey signs you in with whatever unlocks your device. Nothing is phishable, because the credential never leaves the device. Current Chrome, Safari, Edge, and Firefox all support them; if yours does not, the Security page says so and you keep using your password.
Add a passkey prompts your device to confirm, then asks you to name it ("MacBook Touch ID", "YubiKey"). Add one per device you sign in from. A passkey syncing through iCloud Keychain or Google Password Manager is marked Synced and works on your other signed-in devices.
Each entry shows when it was added and last used, and can be renamed or removed.
No passkey on this device?
Unsynced passkeys live only on the device that created them. On a device without one, SendSets says none was found and you sign in with your password, then add a passkey there.
Sessions
Every signed-in device appears under Sessions with its device (Chrome on macOS), location where known, sign-in method (Email, Google, Apple, or Passkey), and last activity. Your current device is tagged This device.
Sign out ends one session; Sign out other sessions clears everything except where you are now.
If something looks wrong
Sign out the session, change your password, and make sure 2FA is on. Signing out other sessions is the fastest way to cut off access.
Password and alerts
Change your password under Password: current password, then a new one of at least 12 characters with upper and lower case and a number. Changing it signs out every other device automatically, while the device you change it on stays in. Accounts that only use Google, Apple, or a passkey have no password to change.
Sign-in alerts notify you when your account is accessed from a new browser and OS combination, naming the device and location with a reminder to act if it was not you. They appear in your in-app feed by default; enable email under Settings > Notifications, Security section, Email channel. Your first sign-in is never alerted, as there is nothing to compare against.
What is recorded when you sign up
Creating an account records the address it was created from, the browser's user-agent string, and a score for how the email address itself reads. This is anti-abuse evidence: it is what lets the platform notice one person opening many accounts, or a wave of signups from one place, without which every account looks unrelated to every other.
- The email address is also stored in a normalized form, with plus-tags and Gmail dots collapsed, so
ada.lovelace+trial@gmail.comandadalovelace@gmail.comare recognisable as the same person. This form is used only for correlation and never for signing in. - It is recorded for every signup, not only suspicious ones. Keeping it only for accounts that already look risky would leave exactly the patterns it exists to find half-empty.
- It stays on the instance the account was created on. Workspace archives do not carry it.
Nothing here refuses a signup on its own. A single weak signal is wrong too often, and turning a false positive into a rejected account leaves a real customer with no way through.
Sign-ins from an impossible place
A hijacked workspace owns warmed mailboxes and decryptable sending credentials, so it is worth more to an attacker than an ordinary account. Sign-in alerts tell you after the fact; this stops the sign-in.
SendSets keeps a short window of where your account was recently used and compares each new sign-in against the last. When the two could not physically be the same person travelling, faster than about 1000 km/h, the sign-in has to pass an emailed code even from a browser you have used before. That is exactly the case a remembered device cannot catch, because an attacker holding your cookie looks like a familiar device.
What it deliberately does not do:
- It does not judge your first sign-in. There is nothing to compare against, and challenging it would challenge every new account.
- It ignores short hops. Locations come from a city database, so two sign-ins from opposite sides of one city are not a journey.
- It ignores intervals under two minutes. Two sign-ins seconds apart from different cities are far more likely a proxy than travel, and dividing by that interval makes any distance look impossible.
- A real flight passes. London to New York in nine hours is ordinary and is never challenged.
- It respects your login-code setting. Where an operator has turned emailed codes off entirely, anomalies are recorded for review but no code is demanded, since that deployment may have no working mail.
Repeated anomalies inside a fortnight are recorded against the workspace's posture. One unusual trip is not a pattern.
Needs a location database
This uses the optional MaxMind city database. Without it configured, sign-ins are recorded but never judged, which is the safe direction: a false challenge locks a real person out of their own account.
Cross-account patterns
Individually, every abuse control watches one thing: a rate limit watches one account, warmup health one mailbox, verification one address. Someone spreading the same behaviour across several accounts stays under all of them.
A nightly sweep looks at the group instead. It groups workspaces that were opened from the same address, or by the same email identity once plus-tags and Gmail dots are collapsed, and notices a workspace that connects an unusual number of mailboxes at once.
Findings are recorded as evidence on the workspace posture, never acted on alone:
- Three workspaces is the floor. Two sharing an address is a coincidence.
- Private and loopback addresses are ignored, since every self-hosted install signs up over a LAN.
- Sharing an address carries little weight on its own. Offices, co-working spaces and VPNs all produce it honestly.
- Only the last 30 days count. Two workspaces opened from one office a year apart are not related.
Strongest setup
- Add a passkey so daily sign-in is fast and phishing-resistant.
- Turn on 2FA and store the recovery codes safely, so password sign-ins keep a second factor.
- Review sessions periodically and sign out anything unfamiliar.