Privacy
Never the body. Never a full IP address. Never a third party.
This page is written for the person running an instance, who is the data controller for everything it records. Every statement was checked against the code on 2026-09-08. The last section covers this website itself.
The short version
MailSignals records that a message was fetched, when, and roughly by what kind of client. It never stores the body of your email, never stores anyone's full IP address, and sends nothing to a third party.
One qualification, and it is the only one: if you set up an agent key so a program can send tracked mail without a browser, that program sends the message body to your own deployment to have the pixel and links put in. It is rewritten in memory, handed straight back, and not stored.
About you
| Data | Why |
|---|---|
| Your email address, name and profile photo | Identifies your account; comes from Google sign-in and is refreshed from the verified token, never from client input |
| Your Gmail addresses (linked, pending or ignored) and send-as aliases seen in the compose window | Decides which accounts may be tracked, and lets the extension tell your own opens apart from real ones |
| Your settings, and when they last changed | Tracking defaults, alerts, notifications, timezone; the timestamp lets the extension pick up dashboard changes |
| A per-user HMAC key | Signs your tracked links so the redirect endpoint cannot be abused |
| A salted hash of the network each message was registered from | Recognises your own Gmail rendering the Sent copy; never the address itself |
| Agent keys, if you create any | Only a salted hash of the secret, a name you chose, its first few characters, and when it was created, last used and revoked |
| How many times you have said "that open was me" | Drives a one-line nudge towards Gmail's image setting |
Sign-in requests openid, email and profile and nothing else. MailSignals has no access to your mailbox.
About the messages you send
| Data | Why |
|---|---|
| Subject line | So you can recognise the message in the dashboard |
| Recipient addresses and names | So you know who you sent it to |
| Gmail thread and message ids | Links the record back to the conversation |
| Send time, reply and forward flags | Timing analysis and status |
| The URLs and anchor text of links you chose to track | Click reporting |
| Delivery-failure notices Gmail sent you: the address that bounced, Gmail's one-line reason, the notice's id | So a bad address is visible and follow-ups stop |
| Whether you archived or trashed the thread, and when | So follow-ups stop; never inferred from the recipient's side |
For mail you send from Gmail in your browser, the body is never read, transmitted or stored. The extension appends a pixel and rewrites eligible links in the page; it does not send the content anywhere. The one exception to "never read" is a bounce notice: the extension reads the visible text of Gmail's own delivery-failure message to find the address that failed and Gmail's reason, and sends only those.
If you use an agent key, that changes for the mail the agent sends. To put a pixel in a message it never sees, MailSignals has to be given the message: the agent posts the HTML body to your own deployment, which rewrites it and sends it straight back. The body is processed in memory and not stored; what is kept is the same as for any other message. It stays inside your Firebase project throughout. If you would rather that never happen, do not create an agent key; mail you send from Gmail in a browser is unaffected.
About the people who open your email
This is the part that deserves scrutiny, because these people did not install anything and did not agree to anything.
| Data | Kept? | Notes |
|---|---|---|
| Timestamp of the fetch | Yes | The core signal |
| User-Agent string | Yes | Needed to tell a proxy from a person from a scanner |
| Full IP address | No | Exists only as a local variable in the request handler; never written |
| IP truncated to /24 (IPv4) or /48 (IPv6) | Yes | Coarse enough not to identify a household |
| Salted hash of the IP | Yes | De-duplication and same-network checks only; not reversible without the salt |
| Referrer and HTTP method | Yes | Distinguish Gmail's indexing fetch from a reader |
| Country and region | No | A "store approximate location" setting exists in both settings screens, but no code path records location today. Turning it on changes nothing. |
| Email content | Never | Not available to the tracker at all |
Behind Gmail, Outlook.com, Yahoo and Apple Mail Privacy Protection the request comes from the provider's proxy, so even the truncated IP describes a data centre rather than a person. MailSignals says so in the interface rather than implying precision it does not have, and labels a proxied open as "the recipient, or you".
Retention
Raw events are kept forever by default. Set a retention window in Settings and a daily job deletes events older than it; the per-message counters survive. Sender view signals and unmatched pixel hits are pruned after seven days regardless. "Delete everything" removes every message, event, link, contact, statistic and alert and keeps only the account, its settings and its linked-mailbox list.
The legal position
Tracking pixels are regulated, and the regulation is tightening.
- EU and UK. The ePrivacy Directive treats a tracking pixel as access to information on the recipient's device, which needs consent. It is not covered by the legitimate interest that may justify sending the email itself. France's CNIL published a recommendation in April 2026 requiring prior consent for marketing pixels, with narrow exceptions for security and deliverability. Other EU regulators routinely follow CNIL's lead.
- One-to-one professional email sits in murkier territory than bulk marketing, but "murkier" is not "exempt".
- United States. Open tracking is lawful and CAN-SPAM does not prohibit it.
MailSignals gives you the controls to comply rather than deciding for you:
- Do-not-track domains. Recipients at these domains are never tracked. Use it for EU domains if you want a blunt instrument.
- Disclosure footer. An optional one-line notice appended to tracked mail.
- Per-message off switch. Tracking is a toggle on every compose window.
- Emails to yourself are never tracked, with no way to override it.
- Minimal retention, and no location recorded.
If you send marketing email into the EU, get consent at the point you collect the address, and record it. That is outside what this tool can do for you. The guide on pixels and the law goes into more detail; none of it is legal advice.
What MailSignals will not do
- It will not store your email bodies. For mail sent from Gmail in a browser it never sees them at all; for mail an agent sends, the body passes through your own deployment to be rewritten and is discarded immediately.
- It will not store anyone's full IP address, yours or a recipient's.
- It will not sell, share, or send your data anywhere. There is no vendor: the data is in your Firebase project.
- It will not claim a read when all it saw was a proxy prefetch, and it will not claim a bounce undoes a read by someone else.
Where your data travels
- Your Firebase project. Everything above.
- Google. Gmail itself (the extension runs inside it), Firebase Auth for sign-in, and InboxSDK's in-page contact lookup against Google's own endpoint using your existing Gmail session.
- Your digest email, if enabled, is written to a collection for the Firestore Trigger Email extension, which the operator installs and points at an SMTP provider of their choice. That provider sees the digest: subject lines and recipient labels of the period's messages.
- Web Push. The server can fan alerts out to browser push services, but no client currently registers a subscription, so nothing is sent.
- An agent you configure. If you create an agent key, the program you give it to sends message bodies to your own deployment to have them prepared. The MCP server in the repository talks only to the address you configure and to nothing else.
Third-party library telemetry
The extension embeds InboxSDK (by Streak) to integrate with Gmail's interface. By default that library reports crashes to its authors and publishes usage events, including a hash of the Gmail address, the extension id and a session id, to Streak's own Pub/Sub topic. MailSignals loads it with globalErrorLogging: false and eventTracking: false, so neither channel is active. The library also calls Google's own contact-lookup endpoint from inside Gmail using the user's existing session; that traffic stays with Google. This was established by reading the shipped bundle of @inboxsdk/core 2.2.21, and the project's rules require re-checking it before upgrading.
This website
mailsignals.io sets no cookies, runs no scripts, loads no fonts, images or stylesheets from anywhere but itself, and includes no analytics of any kind. There is nothing to consent to, which is why there is no banner. It is served by Firebase Hosting, part of Google Cloud, which handles each request the way any web server does; this site adds nothing to that. Pages carry structured data (JSON-LD) so search engines and language models can describe the product accurately; that is data in the page, not a request the page makes.
If you follow a link to the repository or to Google's documentation, that site's own policy applies from there.
Reporting a problem
Open an issue in the repository, or use the contact on the security page. If it is a security issue, please say so in the subject and do not include exploit detail in a public issue.
Effective 2026-09-08. This page is regenerated from the same source as the product documentation whenever the code changes.
Run it in your own project.
One Firebase project, two subdomains, one deploy script. About an hour the first time, and no subscription afterwards.