Security

Last updated September 18, 2026

phish.co ("phish.co," "we," "us," or "our") runs simulated phishing assessments on your organization's behalf — email today, with SMS (smishing) and voice (vishing) on the roadmap. Because the product's whole purpose is to send messages designed to look suspicious, the security model is built around one non-negotiable guarantee: a campaign can never reach anyone outside a domain your organization has actually verified ownership of.

Domain verification

Before an account can run its first campaign, it must verify ownership of a company domain. We support two levels: a one-time code sent to a role address at the domain (such as admin@ or security@), and — for higher usage limits (and, in future, the SMS and voice channels) — a DNS TXT record proving control of the domain itself. Public webmail domains cannot be verified or used to create an account.

Tenant isolation

Every record in our database is scoped to your organization, enforced at the database level rather than left to application code alone. One organization's target lists, campaigns, and results are never visible to, or reachable by, another. The application connects to the database as a least-privilege role that cannot alter schema or reach another tenant's rows outside its own scoped queries.

Sending-domain separation

Assessment traffic (simulated messages — email today, with SMS and voice on the roadmap) is sent from infrastructure kept entirely separate from the domain we use for your account's real, trusted mail — receipts, sign-in codes, and account notices. This is deliberate: it's expected and fine for assessment-sending infrastructure to accumulate a poor reputation with spam and security vendors over time, since that's a byproduct of doing its job. Keeping it on separate infrastructure means that reputation can never affect the mail you actually rely on from us, and it gives your own IT or security team one clean domain to allowlist for assessment traffic without touching your configuration for anything else.

What we don't keep

If a simulated landing page captures a submission — for example, someone enters a username and password into a fake login form — we record only that a submission occurred, never the values typed. This is enforced in the product itself, not a setting a customer or an admin can turn on or off.

Authentication

Sign-in is passwordless: you receive a one-time code and link by email that expire quickly. There are no passwords for an attacker to steal or reuse.

Data in transit and at rest

All traffic is served over HTTPS. Secrets (database credentials, API keys) are kept out of source control and configuration files; the application reads them through Azure Key Vault, fed from our deployment pipeline, and refuses to start if a required secret is missing.

Reporting a concern

Found a security issue or have a question about this model? Email hello@phish.co and we'll respond promptly.