How we handle your email.

01 · Summary

We protect your inbox. To do that, we look at your mail — carefully.

InboxGuard connects to your mailbox with the smallest scope that lets it do its job. Concretely: Gmail’s gmail.modify scope (which lets us read messages and add/remove labels, but never send or permanently delete), Microsoft Graph’s Mail.ReadWrite scope for Microsoft 365 / Outlook (same shape), or read-only IMAP credentials for other providers. For each incoming email we run a set of analysers — phishing, credential theft, impersonation, typosquatting, social engineering, and financial scams — and show you a verdict in the dashboard. We never send mail as you, and we never permanently delete messages. Flags are advisory: every action on a flagged email is yours.

This policy covers the InboxGuard product (inboxguard.app) and the dashboard features available today: connecting a Gmail, Microsoft 365 / Outlook, or IMAP-compatible mailbox; scanning incoming messages; and the Report / Ignore / Trust sender actions.

02 · What we collect

Only what we need to do the job.

Account information

When you sign up, we store the minimum needed to run your account: your email address, display name (if provided), chosen plan, billing status, and preferences like notification settings and rule configurations.

Email metadata

For each message we scan, we keep a small record: sender address, sender display name, subject, received timestamp, and the message ID provided by your mailbox. This is what powers your inbox view, your history, and your rules.

Scan verdicts

The outcome of every scan: a risk score, the set of detection signals that contributed, the plain-language explanation, and any follow-up action you took (Report, Trust, Block). These are stored against the metadata above so you can audit decisions later.

Reported messages

When you click Report on a verdict you disagree with (a false positive or a miss), we keep the full message and the verdict together, so a reviewer can look at what we got wrong and improve detection. See §05 for the detail on this.

Usage & device data

Standard product analytics — pages visited, features used, referring URL, browser fingerprint (UA + major version), and approximate region (country & region, not city). We use this to improve the product. It is stored separately from your email metadata and is not joined for marketing.

03 · What we don’t collect

The short list is important.

Some services are careful about what they collect. We’re careful about what we don’t. Here’s the split:

04 · How a scan works

A message in, a verdict out — and nothing lingering.

Here’s what happens every time a new email arrives in a connected mailbox. Each step is labeled with what we keep and what we discard:

05 · Report, Trust sender & Block domain

The four buttons that create the most data.

From an email’s detail view, you have four user actions: This looks suspicious / I trust this sender (opens the feedback dialog), plus Trust Domain and Block Domain (one-click sender preferences). Each one produces a different kind of record.

Report — “you got this wrong”

Reporting tells us a verdict was wrong, in either direction (a scam we missed, or a safe email we flagged). When you open the Report dialog, you have two ways to submit:

• Report Issue & Help Improve — sends an anonymized snapshot of the message to us so we can correct the model. Before submitting you can open Preview data sent to InboxGuard to see exactly what will be shared.
• Just update for me — silently reclassifies the email in your dashboard and (optionally) adds the sender to your always-trust or always-block list. Nothing about the message is sent to us.

What “anonymized” means, precisely

When you choose Report Issue & Help Improve, we assemble an anonymized packet in your browser before it leaves your device. It contains:

• The subject line with personal information redacted (e.g. names replaced with placeholder tokens)
• The sender’s domain only — never the full email address
• The email body with personal information redacted
• Technical signals about the message — authentication results, URL and domain reputation indicators, and our internal risk scores. We don’t enumerate the individual signals here, because the list is part of how detection works.
• Your free-text reasoning, if you wrote any (optional, 1,000 char max)

Trust Domain / Block Domain — “apply to everyone at @domain”

These add the sender’s domain to your personal allow- or block-list. Future messages from that domain are automatically classified accordingly. We store the domain, the rule, and the date — nothing about the original message is kept as part of this action.

Trust this sender — “this person is fine” (via feedback dialog)

In the feedback dialog you can tick Always trust emails from @domain before you submit. Like the domain buttons above, this adds a rule to your allow-list. It does not retain the message body on its own — the only way body content is shared is via the Report Issue & Help Improve primary action described earlier.

06 · How we use data

A short list of purposes, each one tied to something you asked for.

• To deliver the service. Scanning incoming mail, producing verdicts, and running the dashboard you use every day.
• To meter your plan. Count each analysed message against your plan’s monthly limit (3,000 Starter / 8,500 Individual / 15,000 Family).
• To improve accuracy. Aggregate patterns (e.g. how often certain signal types co-occur) help us tune detection. Reported messages feed human review; regular scans do not.
• To build aggregated threat intelligence. We combine signals across the whole user base — domain reputation, observed attack patterns, risk scores for common senders — into de-identified datasets that improve detection for every customer. We may also offer this aggregated intelligence to other security products as a separate service. These datasets never contain your identity, your email address, the contents of your mail, or anything that can be tied back to you or the people you correspond with.
• To keep the service secure. Rate limiting, anomaly detection, fraud checks, and incident forensics.
• To communicate with you. Transactional email — receipts, alerts, password resets. Marketing email only if you opted in, and always unsubscribable in one click.
• To comply with law. Billing records retained for tax purposes, and responses to valid legal process (see §09).

Legal bases (GDPR)

If you’re in the EEA or UK: we rely on contractual necessity (to provide the service you signed up for), legitimate interest (security, service improvement), and consent (for marketing). You can withdraw consent at any time without affecting service delivery.

07 · AI & models

How we use AI, and what it’s allowed to do with your mail.

Our classifier includes a large language model. That model isn’t ours — we call it via an API from a commercial provider. A few things are non-negotiable in how we use it:

• Your mail isn’t training data. Not for us, not for any third-party provider, not for anyone. We only work with providers that contractually commit to this.
• Content is used for the scan, not stored. The provider needs the relevant parts of the message to produce the verdict; we choose providers whose API terms don’t retain that content for model improvement.
• Model choices can change. Which provider we use may evolve (for quality, cost, or availability). Material changes are notified in advance (see §14).
• We keep a local audit trail. For each scan we record which model version produced the verdict, so we can explain and re-score later.

08 · How long we keep it

Each type of data has a purpose — and a lifespan that matches.

Different data has different jobs, so it has different retention. This is a qualitative summary; precise windows live in our data-retention policy, which is updated alongside this one.

When you delete your account, verdicts, metadata, rules, and preferences are purged promptly. Billing records are retained separately as long as tax and accounting rules require, and aren’t linked back to your active profile.

09 · Who we share with

A short list of service providers — and no one else.

To run InboxGuard we rely on a small number of sub-processors. Each one is bound by a data processing agreement (DPA), processes only what’s needed for its role, and is subject to the same privacy commitments we make to you.

The table above is the canonical list. When we add, remove, or change a sub-processor, this page is updated and material changes are notified in advance (see §14).

Mobile in-app subscriptions (Apple App Store / Google Play)

If you subscribe to InboxGuard through the iOS App Store or Google Play Store, the subscription is sold to you by Apple or Google as the merchant of record — not by us. They process the payment, hold your card details, and handle refunds under their own terms. We receive a receipt and entitlement status from them so we can activate your plan, but we never receive or store your card information. Apple and Google are not InboxGuard’s sub-processors; their privacy policies and consumer terms govern the payment transaction itself.

Legal process & law enforcement

We disclose user data to law enforcement only in response to valid legal process (subpoena, warrant, court order) after careful legal review. Where permitted by law, we notify affected users before disclosure.

Aggregated threat-intelligence partners

As described in §06, we may share aggregated, de-identified threat-intelligence datasets (domain reputation, observed attack patterns, benchmark risk scores) with other security products — either through a paid API or under partnership agreements. These shares are governed by contracts that prohibit re-identification and secondary use.

They never include: your identity, your email address, the contents of any message you received, information about your correspondents, or anything that could be tied back to an individual or organisation. If we ever expand this to a product that would use personal data, we will ask you first.

Business transfers

If InboxGuard is acquired or merged, user data may transfer to the successor entity under the same privacy commitments. You’ll receive notice in advance and can export or delete your data before any transfer takes effect.

10 · Your rights & choices

Everything here is a button in Settings — not a form to fill out.

You don’t need to email us. Every right below is available directly from your account settings, with a response time measured in milliseconds, not days:

For California residents (CCPA/CPRA)

You have the right to know, delete, correct, and opt out of “sale” or “sharing” of personal information. We don’t sell or share personal information as those terms are defined under the CPRA, but the rights above are yours regardless. We don’t discriminate against users who exercise privacy rights.

For EU / UK residents (GDPR)

You additionally have the right to lodge a complaint with your data protection authority. Our EU and UK representatives (where required) will be named on the contact page before paid plans go live publicly; in the meantime, reach us via the contact page and select the Privacy category.

11 · Security

The boring stuff that matters most.

No amount of policy replaces good engineering. Some of the controls in place:

• Encryption in transit. All connections — mailbox provider, dashboard, and internal services — use modern TLS.
• Encryption at rest. Verdicts, metadata, and account data are stored encrypted.
• Least privilege. Production access is restricted to a single authorised operator (currently the founder), MFA-required, and audited.
• Monitoring. Continuous vulnerability scanning and dependency auditing.
• Incident response. If a personal-data breach affects you, we notify you and the relevant authorities in line with applicable law (e.g. GDPR Article 33 — within 72 hours).

These are the frameworks we’re building to. External certifications (e.g. SOC 2) are on the roadmap for later phases and will be reflected here once obtained — we don’t claim certifications we haven’t earned.

12 · International transfers

Protected when data moves across borders.

InboxGuard is a global service and personal data may be processed in countries other than your own, including to reach one of the sub-processors in §09. Where that happens, we rely on the Standard Contractual Clauses adopted by the European Commission (plus the UK International Data Transfer Addendum where relevant), together with supplementary measures such as encryption and access restrictions.

We monitor adequacy decisions and emerging frameworks (EU-US Data Privacy Framework, UK Extension, Swiss DPF) and update our transfer mechanisms as they evolve.

13 · Children

InboxGuard isn’t offered directly to children.

InboxGuard is aimed at adult users managing their own email. We do not offer the service directly to children, and we do not knowingly collect data from children below the minimum age required by applicable law in their country. If you believe a minor has independently created an account, get in touch via our contact page and we’ll delete it promptly.

We do offer a Family plan that allows an adult guardian to connect a minor’s inbox to the service — for example, a parent connecting their teenager’s mailbox to receive phishing, bullying, and inappropriate-content alerts. Processing a child’s data under the Family plan is governed by separate, stricter terms. See our Family Plan Addendum for the lawful basis, consent requirements, rights of child members, retention, safeguarding procedures, and the coming-of-age process.

14 · Changes to this policy

When we change it, we’ll tell you. No quiet edits.

We update this policy when our practices change — for example, when we add a sub-processor, adjust retention, or expand what we collect. Every change is versioned. When a change is material (i.e. it meaningfully expands what we collect, how we use it, or who we share with), we notify active users by email before it takes effect.

Every version of this policy and a short note on what changed is listed below. Material changes are also emailed to active users before they take effect.

Revision history

15 · Contact us

Real humans answer these.

If something on this page is unclear, wrong, or you want to exercise a right that isn’t obvious in Settings, please use our contact page. All privacy correspondence runs through there so we can track, respond to, and resolve requests properly — we don’t rely on direct email for privacy matters.

The data controller for InboxGuard, our registered business address, and (where required) our EU and UK representatives are listed in full on the contact page.