Privacy policy — Posthaste

Two different roles

This distinction runs through everything below, so it comes first.

For your personal data — the account holder’s name, email, billing details — we are the controller. We decide why and how it is processed, and this policy governs it.

For the personal data inside the messages you send — your recipients’ addresses and message content — we are a processor acting on your instructions. You are the controller. That relationship is governed by the data processing addendum rather than by this policy — with one exception, below, where what we do with those messages is unusual enough that burying it in an addendum would be a way of not saying it.

Who we are

Md Shaiyad and Hardil Singh, trading as Posthaste. For data protection enquiries, including any request to access, correct or delete your data: [email protected].

What we collect about you

Account data — name, email address, password hash, and the organisation name if you give one.
Billing data — plan, the name and country you give at checkout, and a tax identifier if you supply one. Card details are entered with our payment processor and never reach our servers.
Invoices — every payment produces an invoice carrying the name and country you gave us, the amount and the date. It is a tax record, so it cannot be edited afterwards and it is not on a deletion clock. This is set out again under your rights below, because it is the main thing we cannot simply erase on request.
Sign-in sessions — for each session, the IP address and browser it started from, so that a session you do not recognise is one you can find and end.
Usage data — API requests, sending volumes and error rates.
Enquiries — if you write to us through the form on this site we keep your name, email address, what you wrote, and the IP address, browser and referring page it came from. The last three are there so that a form being abused can be dealt with.
Support correspondence — what you write to us and what we write back.

There are no advertising or analytics trackers on this site — no Google Analytics, no product analytics, nothing counting you. The one third-party script anywhere on it is Cloudflare Turnstile, which loads only on the contact page and only when you reach it, to establish that a form submission came from a person. Checking that sends your IP address to Cloudflare, and Cloudflare’s widget may set cookies of its own that we do not control.

In the mail you send there is no tracking pixel and no rewritten link unless you put one there yourself. We do not measure whether your recipients opened or clicked anything, which also means we hold no record of it — there is no such feature to switch off.

Signing in with Google

Google sign-in is optional — you can use an email address and a password, or a passkey, instead. If you do use it, Google asks you to approve three scopes and we receive only what those cover:

openid — a stable identifier for your Google account, which we store so that signing in again recognises you as the same person.
email — your email address, which becomes the address on your Posthaste account and the one we contact you at.
profile — your name, used to address you in the dashboard and in our mail to you.

That is the entire list. We do not request and cannot obtain access to your Gmail, Drive, Calendar, Contacts or any other Google service — Posthaste sends mail through our own mail servers and never through your Google account.

Data received from Google is used only to create and authenticate your account. It is not sold, not shared with anyone else, and not used for advertising or to train any model. It is held for as long as your account exists and is deleted with it, on the same clock as the rest of your account data set out below.

You can disconnect Posthaste at any time from your Google account permissions. Doing so stops the sign-in method working; set a password first, or your account will still exist but you will have no way into it.

Why, and on what legal basis

To provide the service: Performance of our contract with you.
To bill you: Performance of our contract, and our legal obligation to keep tax records.
To protect the platform: Our legitimate interest in preventing abuse and in maintaining the deliverability of infrastructure shared by every customer.
To send service notices: Our legitimate interest in telling you about outages, security issues and changes that affect your sending. These are not marketing and you cannot unsubscribe from them while holding an account.
To record what our own staff do: Our legitimate interest in being accountable for access to your data — which is equally the interest of the person whose data it is. It is why the audit log described below cannot be deleted, including by us.
To answer an enquiry you send us: Steps taken at your request before entering a contract, and our legitimate interest in keeping the form from being used to send mail to strangers.

The messages you send

This is the part of the policy that is about your recipients rather than about you, and it is here rather than only in the data processing addendumbecause two of the commitments in it are unusual enough to be worth reading before you sign up.

The bodies are encrypted while we hold them

The text and HTML body of every message — and the composed, signed copy of it exactly as it went out — are encrypted with AES-256-GCM before being written to our database, under a key held outside it.

What that protects against is the database being read without the application: a stolen dump, a leaked backup, somebody with a database password. It does not protect against our own servers being compromised, because the key has to be present in the process that composes and signs your mail. And it covers the body, not the envelope: the subject line, the sender and recipient addresses and any custom headers are stored as ordinary columns, because those are what the delivery record is searched by. If something must never be readable, it does not belong in a subject line.

We cannot read one without telling you

Sometimes we have to open a stored message — an abuse report naming one of your sends, a support ticket where the content is the question. The promise worth making is not that we never look, because that promise would not survive the first spam complaint. It is that looking cannot be silent.

A member of our staff opening a message body must give a written reason of at least ten characters; the requirement is enforced by the database, not by the screen. The reason, their identity, the message and the time are written to an audit log in the same transaction that reads the message, so there is no sequence of events in which the body is read and the record is not. And the account owner is emailed — told which message, sent to whom, opened when, by whom, and the reason verbatim. Not a summary of the reason: the sentence that was typed. It cannot be turned off, and the fact that you will read it is what keeps those sentences honest.

The limits, stated rather than buried: the notice is sent immediately after the read rather than as part of it, so that our own mail being down cannot roll back an abuse investigation — the audit record is written either way. The notice goes to the account owner, so an account with nobody holding that role is a case where the read is recorded and no one is written to. And this covers stored messages; it is not a claim about the sending machinery, which necessarily handles your mail in order to send it.

How long we keep it

Account details: For as long as the account is open. You can delete it yourself from the dashboard; deletion is scheduled 30 days out, is cancellable in that window, and erases everything when it runs.
Message bodies: Thirty days, on every plan, including the signed copy of the message as it was actually sent. This window is fixed: it is not extended by a larger plan and cannot be raised by agreement, because the shortest honest answer is the one worth having.
Delivery records: By plan: 30 days on Free, 90 days on Starter, 1 year on Growth, 2 years on Scale and Enterprise. These are what outlive the body — they carry the recipient address, the subject line and the receiving server’s side of the conversation. Moving to a smaller plan does not delete history on the spot: the old, longer window is honoured for a further 30 days.
Suppression list: Retained while the account is open, and never expired. Deleting a suppression entry would mean sending again to an address that bounced or complained, which is the harm the list exists to prevent.
Invoices: Kept for as long as Indian tax law requires us to keep our books — currently six years from the end of the relevant assessment year — because an invoice is a tax record and cannot be altered once issued. After that the figures may be kept while the buyer name and tax id are redacted.
Monthly sending totals: Two years. Counts and dates, with no recipient in them — this is what a billing question is answered from.
The operator audit log: Permanent. It records every action our staff take on an account, including every occasion one of your message bodies was opened and the reason given. It has no deletion path at all, which is the point of it.
Sign-in sessions: A session record carries the IP address and browser it was created from so you can recognise one that is not yours. It is deleted when it expires or when you sign out.
Enquiries you send us: What you write on the contact form is stored with the IP address and browser it came from, so that abuse of the form can be dealt with. There is no automatic expiry on it yet, and saying so is more useful than inventing a number we do not enforce.
Backups: The database is dumped nightly and dumps are kept for fourteen days. Anything deleted from the live database is gone from it at once, and gone from the backups as those roll off.

Who else sees it

Only the providers we need to run the service — hosting, payments and the like. They are listed individually, with what each one processes and where, on the sub-processors page.

There is one unavoidable disclosure inherent to email: to deliver a message we transmit it to the recipient’s mail server, which is operated by whoever the recipient chose. That is what sending an email is. We encrypt that hop whenever the receiving server offers it, which is the overwhelming majority of mail — but it is opportunistic, and where a server offers no encryption the choice is to deliver in the clear or not to deliver at all. We deliver, and record exactly what happened, because a password reset that never arrives is also a harm. No email provider can honestly promise you more than this.

We do not sell personal data, and we have never been asked to.

Where it is processed

Our infrastructure is hosted in the European Union. Where a provider processes data outside the UK or EEA, that transfer is covered by the appropriate safeguards — standard contractual clauses or an adequacy decision — as noted per provider on the sub-processors page.

The service is operated from India, so the administration of that infrastructure — support, and the audited access to stored messages described above — happens from there. India has no adequacy decision from the European Commission. Where you are in the UK or the EEA, that access is a transfer to a third country, and we will enter into the standard contractual clauses with you on request; email [email protected]. We would rather say this plainly than leave you to infer it from a company address.

Reaching us in the EEA and the UK

We do not currently offer the service to people in the EEA or the UK as a matter of routine targeting, so we have not yet appointed the representative that GDPR and UK GDPR Article 27 require of a company outside those regions. Before we begin offering it to people there, we will appoint one and name them here. Until then, the address above reaches us directly for any data-protection matter, wherever you are.

If you are in India

For account holders in India we are a Data Fiduciary under the Digital Personal Data Protection Act 2023. We collect your data to provide the service and on the legal bases set out above, and you have the right to access, correct and erase it, and to nominate someone to exercise those rights if you cannot. Our grievance officer answers complaints about how your data is handled: email [email protected]. We acknowledge a grievance within 48 hours and aim to resolve it within 30 days. If it is not resolved to your satisfaction you may complain to the Data Protection Board of India.

The service is a developer tool and is not directed at children; we do not knowingly create accounts for anyone under 18. There is no restriction today on where your data may be processed under the Act.

Your rights

You can ask us to give you a copy of your data, correct it, delete it, restrict how we use it, or object to processing based on legitimate interests. You can also ask for it in a portable format.

Email [email protected] and we will respond within one month. There is no charge. If you are unhappy with how we have handled a request you can complain to your local data protection authority.

You can delete your account yourself, from the danger zone on the settings page. The account owner asks for it and confirms with their password and, where two-factor is enabled, a code — deleting an account is at least as hard as signing in. Deletion is then scheduled 30 days out and can be cancelled at any point in that window; when it runs, everything below is erased in a single step and the owner is emailed to confirm. If you sign in only with Google or a passkey, set a password first, since the confirmation needs one.

What erasure does not reach

Four things survive a deletion request, and a policy that did not say so would be describing a different product.

Invoices: Kept as a tax record. They carry the name and country you gave at checkout, and an invoice cannot be altered once it is issued — the database refuses the change rather than trusting us not to make it.
The operator audit log: Every action our staff take is written to a log that has no deletion path — not restricted, not discouraged: absent. That is what makes the notice you get when somebody reads one of your messages worth anything, and the cost of it is that the record of the read outlives the message.
Suppression entries: We cannot remove one at the account holder’s request, because doing so would cause us to send again to an address that bounced or complained. On erasure an unsubscribe or complaint entry is kept and made platform-wide — the address itself is replaced with a marker and only a keyed hash remains, which is the minimum needed to honour the objection. For those platform-wide entries we are the controller, not your processor. If you are a recipient asking about your own address, get in touch and we will deal with it directly.
The erasure record: A small tombstone is kept so a later question about a vanished account has an answer: its identifier, the dates, and a count of what was destroyed. It holds no message content and no personal data beyond the account name you chose.

Delivery records sit slightly differently. They are append-only and hash-linked so that nothing can be quietly rewritten, which is the feature — but they do expire, on the schedule above, through the one path in the database that is permitted to remove them, and that path records what it removed. Tamper-evident is not the same as undeletable, and we would rather you knew which one this is.

Selling and sharing

We do not sell your personal information and we do not share it for cross-context behavioural advertising — in the specific senses California’s privacy law gives those words, and in the ordinary sense too. We have never done either. That is why you will not find a “Do Not Sell or Share My Personal Information” link here: there is nothing for it to switch off.

Cookies

This site sets no cookies of its own — no analytics, no advertising, nothing to consent to. The one exception to be aware of is the contact page, where the Cloudflare Turnstile widget may set cookies of Cloudflare’s own to tell a person from a script.

One third-party script loads in the signed-in dashboard: Google’s sign-in script, and only if you choose to sign in with Google. It is strictly necessary for the sign-in you asked for, it does not run on the marketing pages, and it is not used for tracking.

There is no payment script. Paying leaves this site entirely — the browser navigates to our payment processor, your card or UPI details are entered on their page, and you come back. Nothing of theirs runs on our origin, so nothing of theirs can read anything here. An earlier version of this page said a checkout script loaded on the billing page, which was true of the processor we used before and is not true now.

The application sets six, all strictly necessary, all first-party, none used for tracking. Naming them is more useful than the usual paragraph about how essential they are:

ph_session: Keeps you signed in to the dashboard. Not readable by JavaScript, which is what stops a script on the page stealing it. Fourteen days, extended while you keep using it.
ph_csrf: Deliberately readable, and the only one that is. The dashboard reads it and echoes it back in a header on anything that changes data; a request that does not carry it is refused. It holds nothing about you.
ph_staff, ph_staff_csrf: The same pair for our own operator panel, signed with a different key, scoped to a different hostname, and expiring after eight hours rather than fourteen days. Staff and customers are separate identities all the way down; nothing is shared between them.
ph_gstate, ph_gnonce: Set only if you sign in with Google, and only for the ten minutes that takes. They tie the sign-in that comes back from Google to the browser that started it, and they are cleared as soon as it lands.

Signing out clears the cookies and revokes the session on our side as well, so a copy of one that was captured earlier stops working at the same moment.

Other things stored on your device

The rule that governs cookie banners is not really about cookies — it covers anything stored on or read from your device. So a page that lists six cookies and stops there has told you most of the truth rather than all of it. There are two other things, both stored by your browser rather than sent to us, and neither is a cookie:

ph-theme: Whether you chose light, dark or system. Written only when you use the theme toggle, which exists only inside the signed-in app. It never leaves your browser and we never receive it.
posthaste.plan-intent: The plan you picked before signing in, so that choosing one and then signing in with Google does not lose it. It lives for the tab and is deleted the moment it is read.

Security

The measures we actually take — database-enforced tenant isolation, message bodies and signing keys encrypted at rest, hashed API secrets, an append-only delivery record, and the audited staff access described above — are described on the security page rather than summarised as “industry-standard” here, including what each one does not cover.

Changes

If we change this policy materially we will email account holders before it takes effect. The date at the top always reflects the current version.