Why we don't use cookies¶
Mailexam is a service for testing outbound mail in development, QA, and CI/CD. We deliberately do not use cookies on the website or in the dashboard: not for analytics, not for ads, not to “recognize” you across visits. Below is why we built it this way, what risks cookie-heavy SaaS sites create, and what we do instead.
At a glance¶
| Mailexam | |
|---|---|
| Tracking cookies | No |
| Selling data to third parties | No |
| Retargeting and ad networks | No |
| On-site behavioral profiling | No |
| Purpose of the service | Only receiving and viewing test mail for your projects |
Why most sites set cookies¶
On many products, cookies are not a small technical detail—they are infrastructure for tracking and marketing:
- Visitor ID — the same person is recognized on every visit, even before signing in.
- Cross-session analytics — clicks, time on page, funnel steps, UI A/B tests.
- Ad pixels — data flows to Meta, Google Ads, and dozens of DSPs; then you see “the same” ads everywhere.
- Retargeting — “abandoned cart”, “viewed Pro plan” → ads on third-party sites.
- Affiliate networks — tying a visit to a traffic source for months.
Some of this runs with consent (the “we use cookies” banner); some runs through third-party scripts bundled with chat widgets, maps, or analytics.
Risks of a cookie-first model¶
1. Profiling without clear intent¶
A cookie with a unique ID enables a long-lived profile: which pages you opened, from which device, at what time. Even when policies say “anonymous statistics”, the ID is often linked to the account after signup—and pre-login history is appended to the profile.
Risk: you do not control what entered the profile or who accessed it (staff, vendors, a leaked database).
2. Leaks and compromise via third parties¶
A typical stack: your site + Google Analytics + ad pixel + CRM + support chat. Each recipient is a separate breach surface. Cookie IDs and events are often exported to BI, ad consoles, and “enriched” audiences.
Risk: compromise of an analytics partner, not your server, can still expose user behavior—sometimes tied to email after login.
3. Retargeting and “following” the user¶
Retargeting relies on a cookie (or equivalent) being shared with an ad network. You visit a mail-testing SaaS—days later you see “best SMTP” banners on news sites. That is not random: it is data exchange between platforms.
Risk: a feeling of surveillance; commercial intent (pricing pages, competitor research) leaking into the ad ecosystem.
4. Selling and “enriching” audiences¶
In the data-broker industry, cookie segments and behavioral data are monetized: look-alike audiences, scoring, resale of aggregates. For B2B tools whose customers are developers and companies, this is especially sensitive: corporate visits and IPs can end up in third-party reports.
Risk: your actions on a vendor’s site become the product, although you pay for something else—mail testing.
5. Regulation and audit¶
GDPR, ePrivacy, and local privacy laws require justification for each cookie category, retention, and deletion rights. More cookies and vendors mean higher compliance cost and more ways to slip (pixel left on staging, policy not updated).
Risk: fines and reputational damage not from the core product, but from the “marketing layer” on the site.
6. Mismatch with what the product actually does¶
Mailexam exists to catch test mail over SMTP and show it in the dashboard or via API. Tracking “how you move the mouse on the landing page” does not improve delivery to the sandbox and is not needed for CI.
Risk: users trust the service with message content (tokens, password-reset links, PII in tests)—and get behavioral tracking on top. That erodes trust in a narrow, specialized tool.
Our position¶
We do not track you as a “website audience”:
- we do not build ad profiles;
- we do not sell or hand your data to brokers and ad networks;
- we do not run retargeting or growth pixels;
- we do not link landing-page browsing history to ad campaigns.
The service is built for one job: mail testing in an isolated environment. Messages do not reach real recipients—they land in your Mailexam project, where you inspect them, automate checks, and use the API.
Skipping cookies is not a slogan—it shrinks attack surface and misuse: fewer browser identifiers → fewer ways to “know” you on other sites without your awareness.
What we still process (and why)¶
Without cookies, only data required to run the service remains:
| Data | Why |
|---|---|
| Account and projects | Separate SMTP logins and inboxes |
| Messages sent to your Mailexam over SMTP | That is the product—the test inbox |
| Technical logs (SMTP errors, delivery) | Reliability and support |
| Data when signing into the dashboard | Authentication without lifelong cookie-based tracking across sessions |
We do not collect an activity feed on the site for advertising and do not build “user interests” for third parties.
Test messages
Sandboxes often contain sensitive content: password-reset links, one-time codes, test PII. That is why we avoid expanding data collection around the product with extra browser identifiers.
How you stay signed in without a “forever” tracking cookie¶
Dashboard login is meant to serve the session, not to follow you across the web for years. We do not use cookies for:
- cross-site analytics;
- “reminding” you about Mailexam on other domains;
- sending your ID to ad networks.
If you are not in the dashboard, we do not “remember” your browser via a tracking cookie on mailexam.io.
Compared to typical SaaS¶
| Practice | Often elsewhere | Mailexam |
|---|---|---|
| 20-category cookie banner | Common | Not needed—no tracking cookies |
| Google / Meta pixels | Common | No |
| Visit-based retargeting | Common | No |
| Audience resale | Via data partners | No |
| “Every click” product analytics | Common | Not for surveillance; focus on mail |
FAQ¶
Do you store nothing at all?
We store what mail testing requires: projects, sandbox messages, SMTP settings. We do not store you as an object of ad targeting.
Does skipping cookies hurt security?
No. Session security and account protection do not require marketing cookies. We do not confuse “sign in” with “track the user everywhere”.
How do you improve the product?
Feedback, support, and metrics for SMTP and API operation—within the service, not surveillance on the marketing site. What matters is that a message reaches the sandbox, not how long you viewed a pricing page.
What about API and CI?
Yes. Integrations from the examples and the API do not assume cookie tracking—only project credentials and test messages.
Questions about privacy or data handling: support@mailexam.io.