SecureStamp Trust Protocol

SPF verifies that an IP is authorized to send on behalf of a domain. DKIM verifies message integrity and domain association. DMARC ties them together with a policy. But none of these standards carry context about the sender's intent, reputation, or behavior over time.

A domain can pass all three checks and still be a newly registered phishing domain, a compromised legitimate domain, or a domain spoofing a brand through lookalike registration.

Recipients have no reliable, visible indicator of sender legitimacy. Lock icons and green checkmarks are easy to fake visually. The cognitive load of evaluating an email's authenticity falls entirely on the user.

A sender registers their domain or email at securestamp.online and completes domain ownership verification. Registration creates a stamp record anchored on the audit ledger.

DNS TXT record — the domain publishes a TXT record at _securestamp.example.com containing the stamp ID and verify URL. This is the most robust channel as it is controlled by the domain owner and queried independently of the email body.

HTTP header — mail servers add an X-SecureStamp SMTP header to outgoing messages. This requires mail server configuration but provides per-message verification with a signed JWT payload.

API registration — senders register with the SecureStamp API directly, enabling real-time verification lookups by receiving clients without DNS propagation delays.

When a recipient's plugin encounters an email, it queries POST /api/trust/check with the sender's email or domain. The API aggregates signals from all three channels plus historical reputation data and returns a structured trust response within 200ms (p95).

Signals and the notarial layer resolve to a five-level scale. Levels L1–L4 are a function of technical signals and behavior; L5 requires a notarial match plus an approved identity. Hard override rules can force a message down regardless of score.

• L5 — Certified · Notarial match + KYBThe message envelope matches a notarial record issued by the sender, and the sender holds an approved business-identity (KYB) check. Certifies origin + envelope integrity.
• L4 — Probably legitimate · Technical floorDomain is technically sound (SPF/DKIM/DMARC, reputation) but carries no notarial seal. The most a commodity check can assert.
• L3 — Neutral · MixedSome signals degraded; no strong positive or negative.
• L2 — Suspicious · DegradedMultiple weak or failing signals. Recipient is warned, not blocked.
• L1 — High risk · Failing / blockedCritical signals fail, or a hard rule (admin/compliance override) blocks the message.

A sender registers a notarial record at issue time. The record is an ES256-signed attestation over a canonical hash of the message envelope — sender, ordered recipients, and subject — never the body. The recipient's client recomputes the same canonical hash and asks POST /api/verify/email to compare it against the signed record, yielding one of certified_match, token_valid_hash_mismatch, token_invalid or not_registered.

Forgery resistance rests entirely on the signing key, not on secrecy of the scheme: without the issuer's private key an attacker cannot mint a valid record, and altering any covered field changes the hash and breaks the match. Signing keys are rotated and the corresponding public keys are published as a JWKS set (key-id pinned), so any party can verify a signature — current or recently rotated — without trusting SecureStamp at run time.

L5 certifies that a message genuinely originated from the registered sender and that its envelope is intact. It makes no claim about whether the content is true. This boundary is a deliberate, non-negotiable property of the protocol.

A notarial match alone reaches the certified band only when the issuing organization has passed a business-identity (KYB) review. Until identity is approved, an otherwise-perfect notarial match is capped at L4. This binds the cryptographic claim (“this sender issued this message”) to a vetted real-world identity (“and we verified who that sender is”).

The SecureStamp audit ledger is append-only and records signed transparency entries for stamp issuance, revocation, score changes and abuse events. The production storage model is designed for deterministic reads, tamper-evident hashes and independent verification without exposing private message content.

Every stamp issuance, revocation, and score change is written to the ledger as an immutable transaction. Ledger entries contain only stamp IDs and cryptographic hashes — never personal data or message content.

Any party can independently verify a stamp's authenticity and history by querying the public ledger endpoint at GET /v1/ledger/tx/:txHash.

The default suite is SSCM-1: ECDH P-256 key agreement, HKDF-SHA256 derivation, and AES-256-GCM content encryption. A per-message key encrypts the body and is wrapped for each recipient via an ephemeral ECDH agreement, so recipient key identifiers stay opaque (Bcc is not leaked). All key generation and encryption happen on the client; private keys are non-extractable and never leave the device.

Senders publish only their public keys to a directory. Directory and preflight responses are themselves ES256-signed (verifiable via the same JWKS as the notarial layer), so a client can confirm it is encrypting to the genuine recipient key and not a substituted one. First-seen keys are pinned (TOFU).

Each message carries a sender signature (proof-of-possession) the recipient verifies against the directory, distinguishing a genuine sender from a replay. Users hold an individual recovery file, and organizations may hold a recovery key — both are client-side secrets SecureStamp cannot read. The mode is strict by design: if any recipient lacks an active key the client blocks the send rather than silently downgrading to plaintext. The suite is crypto-agile (SSCM-2 X25519, SSCM-3 post- quantum hybrid are reserved).

Each stamp contains an ES256-signed JWT payload anchored to the ledger. Copying a stamp image provides no benefit — the plugin verifies the signature at verification time, not the visual.

Plugins operate with minimal permissions. Chrome MV3 restricts background page access. Office.js sandboxes the plugin within the Outlook renderer. No plugin has access to the full email body in production mode.

All API keys are prefixed and hashed before storage. The system supports key rotation without service interruption. All mutation endpoints require valid JWT or API key authentication. Rate limiting is enforced at the Vercel WAF edge before reaching application code.