SpoofWard
Trust Center
How SpoofWard is built, what it holds, who else touches it, and what to do if you find a problem.
This page describes controls that exist in the product today. Where the implementation is weaker than you might hope, it says so on the same line rather than leaving it out. Last reviewed August 25, 2026.
Certifications, audits and uptime
Stated first because these are the claims most often inflated. All four are negative.
- SOC 2 Not held
- SpoofWard has not completed a SOC 2 Type I or Type II examination and holds no SOC 2 report. No audit is currently under way. If a SOC 2 report is required for your procurement process, we cannot satisfy it today and will say so rather than point you at a roadmap.
- ISO/IEC 27001 Not held
- SpoofWard is not ISO/IEC 27001 certified and is not in a certification process.
- Independent penetration test None completed
- No third-party penetration test of the SpoofWard platform has been completed, so there is no report or attestation letter to share. Security work to date has been internal: code review, the controls described below, and the fixes recorded in the product changelog.
- Uptime and status page Not published
- We do not publish an uptime percentage, because we do not currently measure availability from outside the platform and will not quote a number we cannot evidence. There is no public status page yet. Internally, a scheduled health command checks queue depth, failed jobs and whether each scheduled task has run recently; that is operational tooling, not a customer-facing availability measurement or an SLA. If you need to know whether an incident is in progress, email us and we will tell you what we know.
Security architecture
SpoofWard is a multi-tenant Laravel application. Everything below describes controls that are in the code today.
- Workspace isolation
- Every tenant-scoped request passes middleware that resolves the active workspace from the session, confirms the signed-in user is a member of it, and — for any route addressed by domain — confirms the domain belongs to that workspace before the controller runs. Controllers that handle sensitive data repeat the ownership check themselves, so a routing mistake alone cannot expose another workspace's data.
- Roles
- Workspace membership carries one of four roles — owner, admin, analyst, viewer — and routes declare which roles may reach them. Actions that write live DNS, change billing, create API tokens or delete a workspace additionally require recent authentication (password confirmation) and, where configured, a second factor.
- Authentication
- Passwords must be at least 10 characters with mixed case, a number and a symbol, and are checked against the Have I Been Pwned breached-password corpus at the time they are set. Passwords are stored with bcrypt (cost 12 in production). Time-based one-time-password two-factor authentication is available to everyone and is required before a privileged user can perform a sensitive action — the request is redirected to enrolment rather than allowed through. Once a user confirms an authenticator, the session must pass the 2FA challenge before any application route is served. Sign-in history is recorded, and passwords expire after 90 days.
- Browser hardening
- Responses carry X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin, a Permissions-Policy that denies camera, microphone and geolocation, Cross-Origin-Resource-Policy: same-origin, a Content-Security-Policy with a per-request nonce for inline scripts, and — outside local development — HSTS with a one-year max-age, includeSubDomains and preload. Session cookies are encrypted, HTTP-only, Secure and SameSite=Lax in the shipped configuration.
- Audit trail
- Privileged and security-relevant actions are written to an activity log that stores a per-row hash, so a row that is altered in the database afterwards no longer verifies. Audit rows cannot set their own timestamps.
Limits you should know about
- The Content-Security-Policy allows 'unsafe-eval' for scripts (required by the Alpine.js runtime the UI uses) and 'unsafe-inline' for styles. Both weaken CSP as an XSS mitigation.
- The same policy allow-lists several third-party script hosts used for analytics, marketing measurement and rich-text editing. Those hosts can execute script in the application origin, so they are trust dependencies, not merely network destinations.
- The single public exception to frame protection is the partner scan widget, which is designed to be embedded on partner websites and therefore ships without X-Frame-Options and with frame-ancestors *.
Encryption and secrets handling
What is encrypted, with what, and — importantly — what that does and does not protect against.
- In transit
- The application is served over HTTPS and sends HSTS with preload outside local development; the CSP also sets upgrade-insecure-requests. Mailbox connections for Mail Shield and DMARC report collection default to IMAP over TLS on port 993 with certificate validation enabled.
- Credentials we hold for you
- Mailbox passwords, DNS-provider API credentials, SIEM and chat-integration tokens, and managed DKIM private keys are encrypted at the application layer with the deployment's APP_KEY (Laravel's authenticated AES encryption) before they are written to the database, and are decrypted only when a job needs them. Sessions are encrypted at rest in the session store.
- API tokens
- SpoofWard API tokens are stored only as SHA-256 hashes. The plaintext token is shown once at creation and cannot be recovered afterwards — if it is lost the token must be revoked and reissued.
- Secrets in configuration
- All provider credentials, signing secrets and API keys are read from environment variables; none are committed to the repository.
Limits you should know about
- Application-layer encryption uses a key held in the environment of the same host that runs the application. It protects credentials against disclosure of a database backup or a SQL-injection read; it does not protect them against compromise of the application server itself.
- SpoofWard does not currently use a managed key-management service or HSM, and there is no automated key-rotation process for APP_KEY.
- Whether the underlying database and its backups are encrypted at rest depends on the hosting configuration of the deployment and is not enforced by the application.
Data retention and deletion
Retention is enforced by scheduled commands. The four data classes below are held separately and have separate windows — audit retention and product-data retention are not the same thing, and a plan that grants a longer product window does not extend the others.
- The four data classes
- DMARC aggregate reports (rua) — Per-source pass/fail counts sent by receivers. Statistics only — no message content. DMARC failure reports (ruf) — Per-message failure samples. Message-derived: header From, envelope addresses, a truncated subject and selected headers. DNS snapshots and scan history — Point-in-time records of your published SPF, DKIM, DMARC, MTA-STS and BIMI records. Security audit events — Who did what in this workspace: sign-ins, role changes, DNS publication, token and export activity.
- DMARC reports and DNS scan history
- A daily command deletes DMARC aggregate reports (and their per-source records) and DNS health scan rows older than the retention window your plan grants. Workspaces on an unlimited-retention plan are skipped, and nothing is deleted inside a workspace's paid retention window.
- Logs
- Audit/activity rows are kept for 400 days, sign-in history for 180 days, application error records for 90 days and scheduled-job run records for 30 days. These are floors: a workspace whose plan grants longer retention keeps its audit and sign-in rows for that longer period.
- Export your data
- Any signed-in user can download a JSON export covering their account, workspace memberships, domains, subscriptions, API token names and webhook configurations from the privacy settings page.
- Delete your data
- A workspace owner can delete the workspace after re-entering their password and typing a confirmation; the delete cascades to domains, reports, subscriptions and invoices. A user can delete their own account the same way. Both are immediate and irreversible.
Limits you should know about
- Mail Shield scan records (scanned message metadata and findings) are not covered by the retention pruner today. They are deleted when the mailbox, workspace or account they belong to is deleted, but they are not aged out on a schedule.
- Deletion removes rows from the live database. Any backups the deployment operator retains are governed by that operator's backup schedule, not by these windows.
- Trial expiry deletes history for the affected workspace; that is a product behaviour, not a retention window, and it is irreversible.
Subprocessors and third parties
Derived from the application's configuration and its content-security policy — that is, from what the code can actually talk to. Which of these are active depends on your plan and on what your workspace has configured.
- Billing — Lemon Squeezy
- The sole payment provider. Checkout and the customer billing portal are hosted by Lemon Squeezy; SpoofWard stores subscription and invoice metadata, not card details.
- DNS and delivery — Cloudflare
- Used for the hosted-DNS delegation zone and DMARC report-authorisation records, and (where the deployment is fronted by it) for edge delivery and analytics.
- Email delivery — the deployment's SMTP provider
- Outbound notifications, reports and alerts are sent through the SMTP provider configured for the deployment.
- AI weekly insight — OpenAI (optional)
- Only active when an OpenAI API key is configured. It receives a structured weekly summary: the domain name, aggregate message counts, alignment and rejection totals, recent DNS changes and discovered sending-service names. It does not receive message content, recipients, mailbox credentials or forensic samples. When no key is configured, the same briefing is generated by rules with no network call.
- Marketing and product analytics
- The public marketing pages load Google Analytics / Tag Manager, Microsoft Clarity, and Meta and LinkedIn measurement pixels, subject to the cookie consent banner. Signed-in application pages also load scripts from public CDNs (jsDelivr, unpkg, d3, TinyMCE) and web fonts from Google Fonts and Bunny Fonts.
- Malware and spam engines — local
- ClamAV and SpamAssassin run on the SpoofWard host and are addressed on the loopback interface by default. Attachments and message bodies are not sent to a third-party scanning cloud.
Limits you should know about
- SpoofWard does not currently publish signed data-processing agreements, a formal subprocessor register with effective dates, or an advance-notice process for adding a subprocessor. This list is maintained by hand against the code and is accurate as of the review date at the top of this page.
- Hosting, backups and infrastructure operations are performed by the operator of the deployment you are using.
DMARC forensic (RUF) handling
Forensic reports are failure samples of real messages, so they are the most sensitive data the platform can receive. The ingestor is built to keep as little of them as possible.
- What is kept
- The reporting MTA, source IP, envelope and header From domains, DKIM selector/domain/result, SPF domain/result, the DMARC verdict and disposition, a truncated Authentication-Results header, and a redacted subset of message headers.
- What is redacted
- The subject line is reduced to its first six characters plus a length. Recipient addresses are masked to the first character of the local part plus the domain. The message body is never stored, in any form.
- Attribution
- A forensic report is filed only against a verified domain. If a report cannot be attributed, it is discarded; if more than one workspace has verified the same name and no workspace context is available, it is attributed to neither, so a sample can never land in the wrong workspace.
- Availability
- Forensic reporting is a plan-gated feature and is off unless your workspace both has it and publishes a DMARC ruf= address pointing at SpoofWard. Most mailbox providers do not send forensic reports at all.
- Who can read it
- Being a member of a workspace is not enough. Reading forensic samples requires a separate permission that only the Owner and Admin roles hold by default; an Owner can grant it to a named member, and doing so requires them to re-authenticate. Recipient and header-derived fields are masked even for someone who holds the permission, and revealing them is a deliberate per-report action. Every view, search, reveal, export and permission change is recorded as an audit event naming the actor.
- Export
- Bulk export of forensic data is disabled by default. Where it is enabled it requires step-up authentication and a stated reason, produces a short-lived signed link rather than a file the browser keeps, and raises a high-severity security alert to the workspace owners.
- At rest
- The message-derived columns are encrypted at rest with the application key, which is held separately from database backups. Retention is enforced by the same daily command that prunes aggregate data, and a workspace may shorten its forensic retention below the plan maximum but never extend it.
Limits you should know about
- A six-character subject prefix and a masked local part are reduced identifiers, not anonymised data. Treat forensic rows as personal data.
Mail Shield data boundaries
Mail Shield connects to a mailbox you nominate and scans inbound messages. This is the part of the product with the broadest access, so the boundary matters.
- What access it needs
- IMAP credentials for the mailbox you connect. That grants read access to that mailbox and, when auto-quarantine is enabled, the ability to move messages into a quarantine folder inside the same mailbox.
- What is stored
- Per message: sender name and address, recipient address, subject, Message-ID, received time, the verdict and risk score, authentication results, attachment count, which engines ran, and one row per finding. Message bodies are not stored. Attachments are not stored.
- Where content goes
- The raw message is passed to SpamAssassin and each attachment to ClamAV, both addressed on the loopback interface of the SpoofWard host by default, and is then discarded. Attachments above the configured size limit (25 MB by default) are skipped rather than uploaded anywhere.
- What it does not do
- Mail Shield does not sit in your mail flow, does not accept or relay mail, and does not delete messages. Quarantine is a move within your own mailbox and is reversible by you.
Limits you should know about
- Subject lines and recipient addresses are stored in the clear in the SpoofWard database. Subjects frequently contain personal or commercially sensitive information — connect a mailbox only where that is acceptable.
- Mail Shield scan records are not aged out on a schedule today (see Data retention).
- Scanning is best-effort detection. SpoofWard does not block mail and cannot prevent a message from reaching a mailbox.
Incident response
What exists, and what does not.
- Detection
- High-risk audit events raise security notifications to workspace owners and admins, coalesced to at most one notification per workspace per event family every 15 minutes and capped at 12 per hour so a burst cannot be used to bury or spam. Repeated authentication failures are alerted on a threshold of five failures in 15 minutes. Unhandled application errors raise a notification to the operator. A scheduled health command reports queue depth, failed jobs and stalled scheduled tasks.
- Investigation
- The activity log is the primary evidence source, with per-row hashes that make silent tampering detectable, and it is exportable on plans that include audit export.
- Notification
- If we identify a security incident affecting your workspace, our intent is to notify the workspace owner by email at the address on the account, with what we know, what we do not yet know, and what we are doing about it.
Limits you should know about
- That notification intent is not a contractual commitment: SpoofWard does not publish a breach-notification deadline or an incident-response SLA today, and none is implied here.
- There is no published 24/7 on-call rotation and no guaranteed response time outside business hours.
- Recovery actions are deliberately manual — the health tooling reports problems and never retries or deletes a failed job on its own.
Vulnerability disclosure
If you have found a security problem in SpoofWard, we want to hear about it, and we will not pursue you for telling us.
- How to report
- Email [email protected] with enough detail to reproduce the issue: the URL or endpoint, the steps, and what you observed. If you do not get an acknowledgement, follow up to [email protected]. The same details are published at /.well-known/security.txt in the format defined by RFC 9116.
- Safe harbour
- We will not initiate or support legal action against anyone who, in good faith, tests SpoofWard within the boundaries below, reports what they find privately to us, and gives us a reasonable opportunity to fix it before disclosing publicly.
- Boundaries
- Test only against accounts and domains you control. Do not access, modify or retain another customer's data — if you can reach it, stop and tell us. No denial-of-service, no load or stress testing, no social engineering of staff or customers, no physical testing, and no spam or mass automated scanning of the public endpoints.
- What to expect
- We aim to acknowledge a report within five business days and to tell you our assessment and intended fix timeline within fifteen. These are targets we work to, not guarantees, and we will tell you if we are going to miss them. We are happy to credit you publicly when a fix ships, if you would like that.
Limits you should know about
- The full policy, including scope and the safe-harbour wording, is maintained in SECURITY.md in the product repository. Where that document and this page differ, this page is the version maintained for customers.
- SpoofWard does not run a paid bug-bounty programme and does not pay for reports.
- We do not currently publish a PGP key for encrypted reports. If you need to send something sensitive, email us first and we will arrange a channel.
Contact
- Security reports: [email protected] — machine-readable at /.well-known/security.txt (RFC 9116).
- Everything else: [email protected]
- Your own data: export and deletion are self-serve from privacy settings inside the app.
SpoofWard monitors and reports on email authentication. It does not sit in your mail flow: it cannot block, quarantine or deliver a message. Enforcement is applied by receiving mailbox providers according to the DMARC policy you publish.