Privacy Policy

This policy describes what Email Risk Radar collects when you use our website, dashboard, and API, and why. We built the underlying pipeline to minimize what we retain by default — most notably, a single email check is never stored with the address attached. Where that isn't the case (bulk jobs, described below), it's called out explicitly.

Account information. When you register, we store your email address and a securely hashed password. We never store your password in plain text.

Single email checks (POST /v1/email/check). The address you submit is processed in real time to produce a result and is not stored afterward. What we do retain against your account is usage metadata only — timestamp, processing time, HTTP status, decision (allow/review/block), and risk level. The submitted email address itself is never written to that usage record.

Bulk checks (POST /v1/email/bulk). This is the one place addresses are stored with an attached result: each submitted address is saved per row so you can retrieve results by job afterward. These records are tied to your account and are retained until you request deletion (see "Your rights" below) or your account is closed.

Domain and mailbox intelligence caches. To avoid redundant lookups, we cache DNS/MX/SPF/DMARC results and domain registration age by domain — this contains no personal data, only domain-level facts. SMTP verification results are cached keyed by a one-way cryptographic hash of the normalized email address, never the address itself, and this cache is shared infrastructure rather than tied to any individual account.

Payment information. Payments are processed by Stripe. We store a Stripe customer/subscription reference to manage your plan, but we never receive or store your card details ourselves.

Anonymous demo usage. The public "try it free" demo on our marketing site tracks your IP address and a single-use token, temporarily, solely to enforce rate limits and prevent abuse. This is not written to our primary database and expires automatically.

Webhook delivery logs. If you register a webhook endpoint, we log delivery attempts (event type, status code, success/failure, timestamp) so you can debug delivery issues. Webhook payloads for bulk job events contain job-level counts (how many addresses were allowed/reviewed/blocked), not the individual addresses themselves.

• To operate the account, API keys, and dashboard you're using
• To process email checks and return a result
• To enforce plan quotas, rate limits, and billing
• To detect and prevent abuse of the free demo and the wider API
• To communicate with you about your account (billing issues, service notices)

We do not sell personal data, and we do not use it for advertising.

If you're in the UK or EEA, we rely on the following legal bases under the GDPR for each category of processing above:

• Contract. Account, API key, billing, and email-check processing is necessary to provide the service you signed up for.
• Legitimate interests. Anti-abuse measures on the free demo, rate limiting, and domain/mailbox intelligence caching are processed under our legitimate interest in operating a reliable, abuse-resistant service — balanced against your rights, and never involving anything beyond domain-level facts or a one-way hash of an email address (see "What we collect" above).
• Consent. We don't currently run any consent-based processing (no marketing emails, no analytics or advertising cookies). If that changes, we'll ask for consent before it starts, not after.

• Stripe — payment processing for subscriptions and one-time purchases. Stripe's own privacy policy governs the card data it handles directly.
• Public DNS resolvers and RDAP registries — used to look up MX/SPF/DMARC records and domain registration dates. These lookups query the domain of an email address, not the address itself.
• The recipient mail server itself — when you request "full" mode verification, we briefly connect to the target domain's mail server to ask (without sending any message) whether it will accept mail for the address being checked. That mail server sees a connection from our infrastructure as part of this process.

• Single-check addresses: not retained at all after the response is returned
• Bulk-check addresses and results: retained until you request deletion or close your account
• Domain-level DNS/age caches: retained on a rolling expiry (they refresh automatically; not tied to any user)
• SMTP verification hash cache: retained on a rolling expiry, never reversible back to an email address
• Account and billing records: retained for as long as your account is active, and as required afterward for legitimate accounting/legal purposes

Under the GDPR (if you're in the UK or EEA) and similar data-protection laws elsewhere, you have the right to:

• Access — request a copy of the personal data we hold about you
• Rectification — correct inaccurate or incomplete data
• Erasure — request deletion of your account, bulk-check history, or other personal data ("right to be forgotten")
• Restriction — ask us to limit how we process your data in certain circumstances
• Portability — receive your data in a structured, commonly-used format
• Objection — object to processing based on legitimate interests (see "Legal basis for processing" above)
• Withdraw consent — for any future processing that relies on consent, at any time
• Lodge a complaint — with your local data-protection supervisory authority (in the UK, the ICO) if you believe we've mishandled your data

To exercise any of these rights, email support@emailriskradar.com. [VERIFY] Self-service data export and account deletion are not yet available directly in the dashboard — requests are currently handled manually via support, and we aim to respond within the timeframe required by applicable law (one month under the GDPR, extendable in complex cases).

• Passwords are hashed, never stored in plain text
• API keys are hashed at rest — only a short lookup prefix and the hash are stored, never the full key after creation
• Webhook payloads are signed with HMAC-SHA256 so you can verify a delivery genuinely came from us
• Bulk email addresses and account data are stored in an access-controlled database, not exposed publicly

We don't set any cookies. The dashboard stores your session token in your browser's local storage, solely to keep you signed in — this is strictly necessary to provide the service you've asked for, so it doesn't require consent under GDPR/ePrivacy rules. We don't use any third-party analytics, advertising, or tracking cookies or scripts on the marketing site or dashboard, and nothing here is used to track you across other sites.

If that ever changes — for example, if we add analytics — we'll ask for your consent via a cookie banner before any non-essential cookie or tracking script runs, not after, and update this section to describe exactly what's used and why.

This service is intended for business and developer use and is not directed at, marketed to, or designed for children of any age. Creating an account requires the ability to enter into a binding agreement, which by itself excludes children in most jurisdictions.

United States (COPPA). We do not knowingly collect personal information from children under 13. If we learn that we've collected personal information from a child under 13 without verifiable parental consent, we'll delete it promptly. A parent or guardian who believes their child has provided us personal information can contact support@emailriskradar.com to request its removal.

UK/EEA (GDPR). We do not knowingly collect personal data from anyone under 16, the digital age of consent in most EEA member states (some set it as low as 13 — the same contact above applies regardless of the exact age in your country).

[VERIFY] Specify your actual hosting region(s) once production infrastructure is finalized. If your data is processed in a country outside the UK/EEA that the UK/European Commission hasn't recognized as providing adequate protection, an appropriate safeguard — such as Standard Contractual Clauses (SCCs) or the UK International Data Transfer Addendum — needs to be in place for that transfer, and this section should name the specific mechanism used rather than describe it generically.

We may update this policy as the product changes. Material changes will be reflected by updating the effective date above.

Questions about this policy or your data: support@emailriskradar.com