What we hold, and who else sees it.

Signet at emailsecurity.pro is built and operated by eSec Forte Technologies, Gurugram, India. Under the Digital Personal Data Protection Act 2023 we act as a Data Processor: we process personal data on behalf of the organisations that use Signet, and on their instructions. Each such organisation is the Data Fiduciary, the party that decides why its data is processed — for its members’ accounts and for the DMARC, TLS and forensic reports about its domains.

This notice tells you, the Data Principal (the person the data is about), what that processing involves, so that you and your organisation can both see it. Questions about why your organisation uses Signet are best put to your organisation; anything about how we handle the data, to us.

Grievance Officer. Questions about this notice, requests to use your rights, and complaints go to our Grievance Officer at [email protected]. For anything else, write to [email protected].

We do not read your mailbox. We hold no passwords. The free tools work without an account. If you sign up, we ask for your consent to use your email address and name to run the account, and you can withdraw it by deleting the account. The DMARC reports we process for your organisation contain counts, IP addresses and authentication results, not messages. Forensic reports, which can contain parts of individual messages, are redacted before they are stored, and the message body is never stored.

Our servers are in Mumbai. Some providers handle data for us, and each one is named below with what it receives and where.

Backups hold copies of all of this for a further period; see “Backups” below.

The domain scan reads public DNS records for the domain you enter and fetches the domain’s public MTA-STS policy over HTTPS. The result is stored and can be shown at a public report address, because it describes records the domain already publishes to the world. The scan does not store who asked for it. Your IP address is used to count requests for rate limiting, in a counter that expires with its window.

If you ask for a scan report by email, we use the address you give to send that one message. It is not stored and is not subscribed to anything.

The message check works by you sending an email to a one-time address we generate. We record the sending server’s address and name, the envelope sender, the From domain, the subject line and the SPF, DKIM and DMARC results, and show them to you. The body of the message is not stored. A check expires 24 hours after it was created and stops accepting mail; its stored data is deleted by the nightly cleanup that follows.

Forms that can be scripted, such as the scan and sign-up forms, show a Cloudflare Turnstile check, which Cloudflare runs in your browser to tell people from scripts.

Every account is asked once, including one created when you first sign in through your organisation’s single sign-on. Before the account exists we show you what we will do with your details and ask you to confirm you are 18 or older and agree, by ticking a box that is not ticked for you. We record that you agreed, when, where, and to which version of this notice. Without that agreement no account is created. On a first single sign-on, we hold the name and address your provider confirms for at most 15 minutes while we ask; if you do not agree, or do not answer, it is deleted and nothing is created.

Accounts created before we recorded this agreement have no record of it, and we have not written one for them. They are asked at their next sign-in, and see nothing of their organisation until they answer.

Sign-in is by a link sent to your email address, or through your organisation’s own single sign-on where your organisation has set it up. There is no password and therefore no password database. A sign-in link is valid for 10 minutes. A session lasts at most 14 days, and ends sooner after 7 days without use. An invitation to join an organisation expires after 7 days if unused.

We store your email address and name, the organisation you belong to and your role in it, the domains you monitor, and the alert channels you configure. We keep an audit record of significant actions in your organisation, including who took them, when, and from which IP address.

Report digests can be sent to people outside your organisation’s membership. We store such an address and send it one confirmation request; it receives no digest until its owner confirms, and every digest carries a link that unsubscribes it.

We use your address to send sign-in links, the digests and alerts you enable, and notices about the service itself. We do not send marketing email, and we do not sell your address or share it beyond the providers named in this notice. Inside the app we may show an offer for one of eSec Forte’s own services. Which offer appears is chosen from the state of your domains’ mail authentication, never from a profile of you.

Withdrawing consent. You can withdraw your consent as easily as you gave it: an owner of your organisation can delete it from Settings in the app, or you can write to [email protected]. Withdrawing ends the account, because we cannot run it without your details. It does not affect what was done lawfully before.

When your organisation publishes a DMARC or TLS-RPT record pointing reports at us, mailbox providers send us aggregate reports about mail claiming to be from its domain. These contain sending IP addresses, message counts, and the SPF, DKIM and DMARC results. They do not contain message content, subjects or recipient addresses. We store them, classify each source, and show them to your organisation.

If your organisation also publishes a forensic (failure) report address, those reports can contain the headers and parts of individual messages sent by other people. We redact them before writing anything to storage, not merely before displaying them, at a level your organisation chooses:

• Minimal: the sending source, the authentication failure, the reporting server and the time. No addresses and no subject.
• Headers (the default): the above, plus the sender addresses and a fixed set of headers such as Date, Message-ID and the authentication results. The subject is withheld.
• Full: the above, plus the subject line.

At every level the message body is discarded, and recipient addresses are replaced by a one-way pseudonym so that repeated targeting stays visible without the address being kept.

Report mail is received by Cloudflare Email Routing and passed straight to our servers; there is no mailbox in which a second copy accumulates. If our servers cannot take a message, an aggregate or TLS report is forwarded to a mailbox at eSec Forte so that it is not lost and can be replayed from there. Mail in that mailbox is deleted after three months. Forensic reports and message-check mail are never forwarded: the sender is asked to retry later instead.

Report data is kept for the period your organisation’s plan provides and then deleted by a nightly job. On the free plan that is 30 days for aggregate reports and 7 days for forensic reports. Other plans state their periods when they are arranged.

These are optional, and only an administrator of your organisation can switch them on, using credentials your organisation creates in its own tenant and gives us.

Microsoft 365 and Google Workspace. To find applications that can send mail as your people, we read your directory with read-only permissions: on Microsoft 365, the permission grants in your tenant and the applications they belong to; on Google Workspace, your user list and the third-party tokens each user has granted. We store, per application, its name and publisher, the permissions it holds, how they were granted and how many people granted them. We do not store the list of users, and the permissions we use give no access to anybody’s mail.

Google Postmaster Tools. With the same Google connection, if your organisation has verified a domain in Postmaster Tools and given the connection access to it, we read Gmail’s daily statistics for that domain: complaint rate, domain reputation and authentication pass rates. These are statistics about your organisation’s mail, not about individual people.

The credentials you give us for a directory connection are stored encrypted. An administrator can switch the connection off; deleting the organisation deletes the credentials, and you can also write to us to have them deleted on their own.

Some organisations have an assistant that answers questions about a domain’s configuration. It is switched on per organisation by us, never by default. When you ask it something, we send the model vendor your question, the domain’s public DNS configuration and our findings about it, whether DMARC reports are arriving for it, and any screenshots you attach. The app redraws a screenshot before uploading it, which removes location and camera details embedded in the file.

We never send the vendor the contents of your DMARC or forensic reports, your account details, or any key we hold for you. We record that a question was asked, by whom, and how large it was; we do not store the question or the answer.

The vendor is Google, through its Gemini API, which Google may run outside India. We use it only under terms that do not allow Google to train its models on what we send, and the assistant will not run with a vendor we have not recorded as meeting that condition.

If you use Signet to host an MTA-STS policy, a DKIM key or a DMARC reporting address, we serve those records on your behalf. Hosted DKIM private keys are stored encrypted. Serving the records involves our web and DNS servers and Cloudflare; their logs are used for operating the service and for nothing else.

We have no access to your mailbox. We do not read, store or scan your email; the directory connections above read who has granted what, not what anybody has sent or received. We do not track you across other websites, we set no advertising cookies, and we do not use third-party analytics on this site.

The cookies we set are the session cookie after you sign in, and a short-lived cookie that holds sign-in state while you are away at your single sign-on provider.

Cloudflare, which protects this site from automated abuse, sets its own security cookies: __cf_bm, which lasts 30 minutes, and, if you are shown a challenge, cf_clearance. They are used only to tell people from automated traffic, not to track you, and the site does not work without them.

Our database and application servers are hosted by Linode (Akamai) in Mumbai, India, on encrypted disks. These providers handle data for us, on our instructions:

• Linode (Akamai), Mumbai: hosts our servers, and so everything we store.
• Cloudflare: DNS, the network edge in front of our site and app, and the receiving of report and message-check mail. Sees all traffic to us and report mail in transit, at the Cloudflare data centre nearest the sender.
• Amazon Web Services, Asia Pacific (Mumbai) region, under its data processing agreement: sends our email, so receives recipient addresses and message contents including sign-in links; and stores our encrypted nightly backups.
• Google, for organisations that have the assistant, as described under “The assistant”.
• Sentry, United States: error reports from our servers, the app and this site. We filter them before they are sent to leave out request bodies, cookies, tokens and keys.
• New Relic, United States: a copy of our servers’ operational logs, described under “Backups and logs”, so that problems raise an alert. New Relic keeps them for 30 days.

Some of this processing can take place outside India: Sentry and New Relic in the United States, Google’s Gemini API wherever Google runs it, and Cloudflare at its data centre nearest the sender. The Act permits these transfers, and we will update this section before adding a provider that receives personal data.

To do its job the product also looks things up in public sources, which see the query but receive nothing else from us: public DNS resolvers and DNS blocklists (the domains and sending IP addresses being checked) and the crt.sh certificate log search (domain names). We also download AbuseIPDB’s published list of abusive IP addresses; we send AbuseIPDB nothing.

The database is backed up nightly. Backups are kept on our server for 14 days and copied, encrypted, to Amazon Web Services in Mumbai, where they are kept for 180 days and a replaced copy for 90 days after that. Data that is deleted therefore remains in backups for up to 270 days, and is not restored from them except to recover the service.

Our servers keep operational logs, which include IP addresses and the pages and API addresses requested, for 365 days, as the DPDP Rules require for investigating security incidents, and then delete them. Tokens and secrets are removed from them before they are written. A copy is sent to New Relic, which keeps it for 30 days, so that errors and failures raise an alert.

As a Data Principal, the person the data is about, you can:

• Ask what we hold about you, what we do with it, and who else we have shared it with.
• Have it corrected, completed or updated. You can change your name in the app; write to us for anything else.
• Have it erased. An owner of your organisation can delete it from Settings in the app. From that moment its data is no longer shown to anyone, new reports are discarded unread, and members are signed out; owners can still sign in for 7 days to cancel, in case of a mistake. Records we host for you keep being served until then, so your mail is not disrupted. After the 7 days, the organisation and everything it holds are permanently deleted, together with the accounts of members who belong to no other organisation. Copies in backups are removed as the backups expire, within 270 days.
• Withdraw your consent, as described under “Accounts, and your consent”.
• Nominate someone to use these rights for you if you die or become unable to act. Write to us with their name and contact details.
• Raise a grievance with our Grievance Officer at [email protected].

We answer every request and grievance within 45 days. If you are not satisfied with our answer, you can complain to the Data Protection Board of India.

Data in your organisation’s reports. Your organisation decides what happens to the DMARC, TLS and forensic reports we process for it, so we act on a request about them with its agreement. If your mail appears in a forensic report sent to us about someone else’s domain, you can still write to us: we will tell you what we can find, and pass your request to the organisation concerned.

Signet is a service for organisations. You may sign up only if you are 18 or older, and you confirm that you are when you create an account. We do not knowingly create accounts for anyone younger. If you believe someone under 18 has an account, write to [email protected] and we will delete it.

Traffic between you and us, and between us and the providers above, is encrypted. Our servers’ disks are encrypted, hosted DKIM keys and the credentials you give us are encrypted again in our database, and backups are encrypted where they are stored off our server. Access to production systems is limited to the people who operate the service. Because there are no passwords, there is no password database to be stolen. Our own domain’s posture is published hourly at /security, whether or not the result flatters us. If you find a vulnerability, please read the contact page for how to report it.

If a breach affects your personal data, we will tell you without delay, from [email protected]: what happened, what it means for you, what we are doing about it and what you can do. We will report it to the Data Protection Board of India as the Act requires, with a full report within 72 hours.

This notice is available in English. When it changes we update the effective date above and, for changes that affect how your data is handled, tell account holders by email before the change takes effect. Where a change needs your consent again, we will ask for it.