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).

Scores map to three states with hard override rules:

• CONFIABLE (70–100)All hard rules pass. At least SPF or DKIM pass. Registered in SecureStamp.
• SOSPECHOSO (30–69)Some signals degraded. Recipient warned but not blocked.
• BLOQUEADO (0–29)Critical signals fail. Hard-blocked by admin or compliance list override.

The SecureStamp audit ledger runs on Hyperledger Besu with IBFT 2.0 (Istanbul BFT) consensus. This provides Byzantine-fault tolerance with deterministic finality — no forks, no probabilistic confirmation delays.

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.

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.