Reference

Security

What happens to your keys and your messages, and what separates your account from everyone else's. Written so you can decide whether to trust it, not to describe how it is built.

Your DKIM private key

Each domain you add gets its own 2048-bit key pair — not a shared one. The private half is encrypted before it is written and decrypted only in memory, at the moment a message is signed.

It is never returned by any endpoint, including to you.
It never touches a filesystem, so it cannot be read from a backup of one.
The mail server never holds it. Signing happens before a message reaches the MTA, which is why adding a domain requires no mail-server change.

The practical consequence is that your signature cannot be produced by another account, and a compromise of one domain's key does not affect any other domain — yours or anyone else's.

Every message you receive is encrypted before it is written: the plain-text body, the HTML body, each attachment, and the original bytes of the message as it arrived. The cipher is AES-256-GCM, which is authenticated — a row altered in the database fails to decrypt rather than handing you changed mail.

The key lives on the host, never in the database. A copy of the database alone does not read your mail.
It is a different key from the one protecting DKIM private keys, so neither depends on the other.
Decryption happens in memory when you open a message, download an attachment, or fetch the raw source.

What is not encrypted, and why

Two things are deliberately left readable: the subject line and the sender address. Those are what the mailbox list shows and what its search matches, and searching an encrypted column would mean either decrypting every message in your account on each keystroke, or keeping a plain copy of the same text under a different name. The bodies and attachments — where the content actually is — are encrypted. It is a real tradeoff, and worth knowing rather than assuming.

On the wire, mail arrives over TLS whenever the sending server offers it, and everything between you and the API is HTTPS. Encryption at rest is about what a copy of the disk would reveal, which is a different question.

Your API keys

Stored as a SHA-256 hash. The secret is shown once at creation and cannot be recovered afterwards — if you lose it, you create a new one, because there is no copy to send you.

A key cannot mint another key

Creating or revoking keys needs a dashboard session, not a key. So a leaked key has a bounded blast radius: it could not have created others, and revoking it is genuinely the end of it.

Each key records when it was last used, so an unfamiliar timestamp is visible rather than silent. Revocation takes effect immediately.

Isolation between accounts

Every record that belongs to you carries your account id, and every query filters on it — domains, messages, inbound mail, attachments, suppression lists, webhooks, keys. There is no shared customer data.

Asking for a resource that is not yours returns 404 rather than 403. That is deliberate: a 403 would confirm the thing exists.

Passwords

Hashed with scrypt and a per-user salt. Sessions are short-lived JSON Web Tokens rather than long-lived cookies. Login attempts are rate-limited per IP, which is what makes guessing impractical rather than merely slow.

Transport

Where	What is used
You to the API	HTTPS with TLS 1.2 or better. HTTP redirects; it does not serve.
Us to a receiving server	Opportunistic TLS — encrypted whenever the far end offers STARTTLS.
Webhooks to you	HTTPS only. An `http://` endpoint is refused at creation.

Outbound TLS is opportunistic rather than required because a mail server that does not offer STARTTLS still needs to receive your mail. Requiring it everywhere would silently drop legitimate messages.

Mail you receive

Inbound content is written by strangers, and it is handled that way. HTML is stored exactly as it arrived rather than sanitised — sanitising it would be a claim about your rendering context that cannot be made from here — and returned as-is so you can decide.

Attachment filenames are stripped of path separators before storage, so a malicious name cannot escape a directory.
Attachments download with Content-Disposition: attachment and X-Content-Type-Options: nosniff, so a browser will not render one as a page.
SPF, DKIM and DMARC results are reported rather than enforced, so you can require them where it matters instead of having legitimate mail dropped before you see it.

Not an open relay

The mail server accepts submission only from the application, never from the internet. Mail addressed to anything other than a bounce host or an inbound host you configured is refused with 554 Relay access denied.

You can only send from a domain you have added and verified. Verification is what makes it your domain rather than one you typed.

What is never exposed

DKIM private keys, in any form, to anyone.
Password hashes or API key hashes.
Another account's existence, data or identifiers.
Stack traces, database errors or connection strings — an unexpected failure returns a generic message and is logged internally.

Logs redact secrets before writing. An Authorization header does not appear in them.

Reporting a vulnerability

Email security@scanmypass.com with enough detail to reproduce it. Please do not open a public issue first.

Testing against your own account is welcome. Testing that degrades the service for others — load testing, attempts at other accounts' data, sending abusive mail to prove a point — is not, and will get the account suspended.