Privacy policy

Who is responsible for what

5dayemail.com is operated from the Netherlands. Anything on this page can be raised by writing to tan.gravam@gravam.com.

There are two different relationships here and they are not interchangeable. For a course list, the creator is the data controller and we are their processor. They decided to collect the address, they wrote what is sent to it, and a request about that data is theirs to answer. We store and deliver it on their instructions and use it for nothing else, with one exception described under how long it is kept: an address that bounces, complains, asks to leave the whole platform or is erased goes onto the platform-wide suppression list, which stops any course here mailing it again and protects the sending domain every creator shares. For a creator account, we are the controller — the account, the courses written in it and the subscription that pays for it are ours.

If you are subscribed to a course

We store, for as long as you are on that list:

• Your email address, because there is no way to send you an email without it, and a one-way hash of it so that an address that has asked to leave the whole platform can be recognised and refused without keeping the address itself.
• Your time zone, taken from your browser when you signed up, so that each day of the course arrives in the morning where you are rather than in the middle of your night.
• Which day of the course you are on, when you confirmed, when the last email went out, and whether you have paused or finished.
• Which days you have opened on the web. Each email links to a page where you can read that day in a browser, and opening it records that day as read, against your subscription and with the time. Pressing "mark complete" on that page records the same thing. It is how the progress shown on those pages is counted. Nothing records it if you only ever read the email itself.
• When you first clicked the course's next-step link, if the creator added one: the time of that first click, so the creator can count how many finishers followed it.
• What you say when a course ends, if you say anything: whether it helped, the sentence you wrote, and the name you signed it with. The person who wrote the course reads it. It appears on the course's public sign-up page only if you ticked the box allowing it to be quoted and the creator chose to show it, and it comes down if you unsubscribe or change it.
• Whether your address has been passed on when you finished, if the creator set that up. A creator can have the address of a reader who finishes a course sent, once, to a tool of their own choosing, such as the service they send their newsletter from; we record when that happened. It is the same address the creator already holds as the person you signed up with, and it is not sent for anyone who has unsubscribed.
• The record of your consent: the date, the IP address and the browser you used to sign up, and a SHA-256 hash of the exact sentence you agreed to. The hash rather than the sentence, because the point is to prove which wording you saw. This record is append-only and is never edited.

Your name is not asked for and is not stored. The sign-up form asks only for your email address, and there is no column for a name anywhere in the database. We do not track opens and we do not embed tracking pixels — nothing in an email reports back that you looked at it. What we do record is described above: following an email's link to read a day on the web marks that day read, and the next-step link notes your first click. Those are pages you chose to open, not a pixel that fired without you.

The lawful basis is your consent, which you gave by clicking the confirmation link, and which you can withdraw at any time using the unsubscribe link in any email. The consent record itself is kept under our legitimate interest in being able to demonstrate that consent was given, which is what Article 7(1) of the GDPR requires of us.

If you write courses here

Signing in is Google only; there is no password to store. From your Google account we receive and keep your email address and display name. You additionally supply a sender name, a reply-to address, a time zone, and a postal address.

Your postal address is published. It appears in the footer of every course email you send, because a bulk commercial email without a real postal address is one mailbox providers are entitled to treat as spam. Do not use a home address you are not willing to have read by strangers; a registered business address or a PO box is the right thing here.

We also store the courses you write, every saved version of every email in them, and any images you upload. Uploaded images are stored in a bucket that is readable by anyone holding the URL, because they have to be fetchable by a mail client with no session. An image is not deleted when you remove it from an email or archive the course — there is no cleanup pass yet, so treat anything you upload as published from the moment it is uploaded.

A published course can be listed on the public course directory, at /courses, a page search engines index. The listing shows the course's title, your sender name, its length and the subject of its first day. It is off unless you switch it on in the course's settings; switching it off again removes the course from the directory and changes nothing about its delivery.

If you subscribe, the payment is taken by Stripe and we never see your card. The card number is entered on Stripe's own checkout page and never reaches this application, so there is no card field in this database and nothing here to leak. Stripe asks you for a billing address, because the tax on an electronically supplied service depends on where you are, and takes a VAT number if you have one; Stripe holds those, along with the invoices. What we store is the Stripe customer and subscription identifiers, which plan you are on, the status Stripe reports for the subscription, whether it is set to end at the period's close, and the date that period ends.

The lawful basis is the contract between us: we cannot run the account without this, and we cannot take a payment for it without the payment data described above.

If you asked for an account

Until 4 October 2026 accounts here were opened a few at a time rather than by signing up, and a form at the foot of the guides, tools, comparisons and glossary put an address on a waiting list. The form is gone; what follows describes the entries it collected. We are the controller for that list — no creator sees it and it is not part of anybody's course.

We store your email address, a one-way hash of it, which page you submitted the form on, and the dates you joined, were invited and answered. There is a field for a note about what you wanted to use it for; no form on the site ever asked for one. Nothing else is recorded: no name, no IP address and no browser.

Joining sent you nothing. It was a list to invite from, not a list to mail: no message left when the form was submitted, there was no confirmation email, and the only thing ever sent to that address is an invitation, written by hand. The lawful basis is your consent, given by submitting the form.

You can have the entry deleted at any time, by writing to tan.gravam@gravam.com — there is nothing to unsubscribe from, so that is the route. It is also deleted automatically if the address reaches the platform suppression list: choosing to leave the whole platform on an unsubscribe page, a bounce, a complaint or an erasure request each add the address hash there, and a waiting-list entry for that address is removed in the same transaction. That is deliberate — an address that has said stop must not be sitting on a list whose only purpose is to be written to.

Cookies and analytics

This application itself sets one cookie, and only when you sign in: the session cookie that keeps you signed in. It is strictly necessary and it is not used to measure anything. Your light, dark or system colour preference is kept in your browser's local storage; it never leaves your device, and clearing it only resets the theme. If you write courses here, the email editor also keeps an unsaved draft of the email you are editing — its subject, preview text and body — in your browser's local storage, so that a closed tab does not lose it. The course settings page and the sender settings page keep unsaved changes to their own fields the same way, your postal address and reply-to address included. Each of these drafts stays on your device until you save it, discard it or sign out, and none of them measures anything. Two smaller things are kept the same way: the four answers you gave the outline tool, from the moment you choose to start a course from them until that course is made, and a list of which of your account's stamps this browser has already shown you, so that each one is pressed on once. The stamp card on the tools pages is not kept at all: it lasts for the visit and is gone when the tab closes.

Google Analytics runs only if you allow it. On the public pages of this site — the home page, the guides, tools, glossary, comparisons, niche pages, pricing, statistics, the course directory, about, this page and the terms — a banner asks whether Google Analytics may count your visit. Until you press Allow nothing is loaded from Google and no analytics cookie is set, and pressing No thanks keeps it that way. If you allow it, Google Analytics 4 sets two cookies, _ga and _ga_ followed by an identifier, which last up to thirteen months. It records which of these pages you view, the address without anything after a question mark, the site that linked you, your browser and device, and an approximate location that Google works out from your IP address. Google signals and every advertising feature are switched off. Google keeps that data for the retention period set on this property, at most fourteen months. You can change your answer whenever you like with Cookie settings at the foot of every public page; withdrawing deletes the two cookies.

Apart from that, no page is counted, with one exception. Google Analytics never runs on a course's sign-up page, on the page a confirmation link lands on, on a lesson or unsubscribe page, or in the signed-in creator area, and none of them loads a third-party script. The one exception is described immediately below and is a count and nothing more: a course's sign-up page adds one to its own tally of views. If you got here by clicking a link in an email you asked for, you are not being measured — and measuring someone on the page where they are trying to leave would be the worst version of this.

A course's sign-up page counts two things, and they are counts rather than people. When you open a creator's sign-up page, that page adds one to a tally of views for that course for that day, and signing up adds one to a tally of sign-ups. Alongside each tally we keep the domain name of the site that linked you here, if your browser sent one — example.com, never the rest of the address, because a full link can itself be private — and the short label a creator may have put on their own link, such as ?ref=newsletter. 5dayemail.com tags its own links the same way, with fixed labels that name the page the link was on — ?ref=certificate, ?ref=done, ?ref=more-by-creator, ?ref=forwarded, ?ref=confirm — and are the same for every reader, so they never say who followed them. Nothing else is recorded: no address, no identifier, no cookie and nothing written to your device, so these numbers cannot be joined to you, to your sign-up, or to any other page you have looked at. A creator can see that eight people arrived from a newsletter; they cannot see which eight.

Submitting that sign-up form is rate-limited separately, against floods of fake sign-ups, and that counter does hold the IP address the form was sent from — whether or not the sign-up is accepted — for at most about a day. It is described under how long it is kept.

The banner asks about Google Analytics and nothing else, because that is the only thing on this site that stores something on your device to measure anything. Your answer is kept in your browser's local storage so that the question is not asked on every page; it never leaves your device. Nothing on the site depends on the measurement working, and a content blocker will stop it with no effect on anything.

Who else touches the data

These are the only processors involved:

• Supabase — the Postgres database that holds everything described above, plus authentication and file storage. Hosted in the United States (region us-east-1, Northern Virginia).
• Resend — the email provider that delivers every message. They necessarily see the recipient address and the content of the email, and they keep their own delivery, bounce and complaint logs under their own policy.
• Hetzner Online — the server that runs the application and the send loop, in Germany.
• Stripe — the payment processor for creator subscriptions, and only for those. They see the billing name, address and card of a creator who subscribes, and issue the invoices; nothing about a course subscriber ever reaches them, because nobody pays to read a course. For an account in the European Economic Area the contracting entity is Stripe's Irish company, which transfers some of that data to its United States parent under the standard contractual clauses in its own data processing agreement.
• Google — sign-in for creators (Google account holders only), and Google Analytics on the public pages for a visitor who allows it, as described under cookies and analytics. Nothing about a course subscriber is ever sent to Google.
• Anthropic — only when somebody asks for a course to be drafted from text they paste: a creator on the new-course form, or a visitor on the email course outline tool. That text and the working title are sent to Anthropic's Claude to write the draft; we do not store the pasted text, and nothing about a course subscriber is sent. A visitor's draft is handed back to their own browser and kept there until they sign in. Anthropic keeps what it receives under its own policy.

Some of these place personal data outside the European Economic Area. The database that holds your subscriber record and the consent ledger is hosted in the United States, and mail delivery runs through Resend, which is established there. Both transfers rely on the standard contractual clauses in those providers' data processing agreements. The application server runs in Germany, inside the European Economic Area. Google, for creators' sign-in and for the analytics a visitor allows, is a United States company too; it is certified under the EU–US Data Privacy Framework, which is what that transfer relies on. Anthropic, for a draft a creator asks for, is a United States company as well, and that transfer relies on the standard contractual clauses in its data processing agreement.

How long it is kept

• Subscriber records and the consent ledger: for as long as the list exists. Neither is on any automatic deletion schedule, because the consent ledger is the evidence that the mail was wanted. Both are removed by an erasure request.
• A sign-up that was never confirmed — a typo, or an address somebody else typed — is kept the same way, with the IP address and browser it was submitted from. While it is waiting to be confirmed and its link is still valid, that record is what stops the same course sending the address a second confirmation email when the address is submitted again. Once the link has expired, 30 days after it was sent, the same course can send one more — if the address is submitted to it again, or its creator resends it. The record does not stop a different creator adding the address to their own course, which sends that course's own confirmation. Its owner can have it erased by writing to us; erasing it also puts the address on the suppression list, so no course here can send it anything again and it can never be added to a list here again.
• Waiting-list entries: until you ask for the entry to be deleted, or until the address reaches the suppression list, which deletes it in the same transaction. There is no automatic schedule beyond that, because the list exists to be worked through by hand and an entry deleted on a timer is a person who asked for an account and was quietly dropped.
• The sign-up page tallies described above: for as long as the course exists, and deleted with it. There is no schedule, because there is nothing personal in them to age out — they are counts per day per referring domain, and an erasure request has nothing to remove from them.
• The page-view tally this site kept until September 2026: the counts already made are kept, with no schedule, for the same reason — each is a count per page per day per kind of source, with nobody in it. Nothing is added to it.
• Rate-limit counters: at most about a day, deleted hourly. The sign-up form on a course's page keeps the IP address it was submitted from in one, to refuse floods of fake sign-ups — whether or not the sign-up is accepted. The page-view counter keeps only the scrambled daily value described under cookies and analytics.
• The subscription record: for as long as the creator account exists. When an account is deleted, its link to the subscription goes with it; Stripe's identifiers and status for the subscription itself are kept until the subscription has ended, because they are what lets a subscription that is still running be found and stopped, and are then deleted. The invoices themselves are Stripe's and are kept under their policy and for as long as Dutch tax law requires a trader to keep them, which is why closing an account cannot delete an invoice already issued.
• Delivery and bounce records: 180 days, then deleted nightly.
• Operational health and dispatch logs: 30 days, then deleted nightly. They refer to readers, creators and waiting-list entries by internal id, never by address. A record of an action the operator took also names which operator took it and the IP address they took it from.
• The suppression list: forever, and this is deliberate. It holds a SHA-256 hash of an address that has asked to leave the whole platform, bounced, complained or been erased, and nothing else. Leaving a single course does not put an address here; it ends that one subscription and touches nothing else. It is never pruned and no cascade can remove it, because the whole point of it is that an address which has said stop can never be added back to any list here by anyone, including by the person who erased it.

Your rights, and how to use them

Under the GDPR you can ask for a copy of your data, ask for it to be corrected or erased, ask us to restrict or stop processing it, ask for it in a portable form, and withdraw consent at any time.

If you are on a course list, the fastest route is the unsubscribe link in any email you have received: one click stops every remaining email of that course immediately, with no confirmation page and nothing to fill in. No creator can put you back on it afterwards — importing or adding the address again sends nothing — and any other course you are taking is unaffected. The page that link opens also offers the wider option: stopping mail from the whole platform, permanently, including courses by other creators, which cannot be undone by anyone, including by us. For anything more than stopping the mail, write to the creator whose course you joined — they are the controller, and every email from them carries their reply-to address. You can also write to us at tan.gravam@gravam.com and we will act on it.

If somebody else put your address on a list and you never confirmed it, that course has sent it one confirmation email. While it is waiting for you to confirm and the link in that email is still valid, submitting the address to that course again sends nothing more; once the link has expired, 30 days after it was sent, the course can send one more, if the address is submitted to it again or its creator resends it. A different creator could still add the address to their own course, which sends that course's own confirmation. The creator who added it cannot erase it on your behalf — otherwise anybody could have any address blocked across the platform — so write to us at tan.gravam@gravam.com and we will erase it, wherever it appears, and put it on the suppression list, after which no course here can send it anything again.

If you write courses here, write to tan.gravam@gravam.com. Deleting a creator account deletes the courses, the subscribers, the send history and the delivery records that belong to it. Any running subscription is cancelled at Stripe before the account is deleted, so nothing further is charged; an invoice already issued is a tax record and is kept.

You have the right to complain to a supervisory authority. In the Netherlands that is the Autoriteit Persoonsgegevens.

What erasure actually does

Erasing a subscriber is one transaction and it removes the subscriber record, the consent ledger entries, every queued and sent message, every link token, every progress record, every delivery event for the course emails that creator sent them, and every operational log entry recorded against that subscriber. Not marked deleted — deleted. Operational logs refer to people only by internal id, so an entry about them anywhere else — a record of an invitation, say — names nobody once their record is gone.

The delivery records that are kept are those for the confirmation email — one for each thing the mail provider reported about it, such as its delivery, a bounce or a complaint, and more if it was sent again — because they were never tied to a subscriber record in the first place. Like the bounce records described below, they cannot point back to a person: before anything the mail provider reports is stored, the address is taken out of it, and so are the message's headers, the links in it and any IP address or browser the provider saw. What is left is which course the confirmation was for, whether it was delivered, bounced or drew a complaint, what the receiving mail server said about it, and when.

It also removes any waiting-list entry for the same address. Erasure writes the address hash to the suppression list first, and a new suppression row deletes the waiting-list entry that matches it — so somebody who joined the waiting list, later subscribed to a course and then asked to be erased does not keep an entry here that nobody thought to look for.

If the same address was also on a different creator's list here, the bounce and complaint records from that list are kept, with the address hash and the provider's message stripped out of them. What is left is that a message bounced or drew a complaint, on whose course, and when — with nothing that points back to a person. That record is what stops a sender whose mail is being rejected from carrying on, and one creator's erasure request is not allowed to delete another creator's evidence.

One thing survives, and you should know about it before you ask. A SHA-256 hash of the address is written to the suppression list first, and that row is never removed. The hash cannot be turned back into the address, and it is not used to contact anyone — it exists so that the address can never be re-added to a list here, by import or by anybody typing it in. It is the only way to make "erase me and never mail me again" mean both halves of the sentence at once.

Security

Application data lives in a database schema that is not exposed to the public API at all, so it can only be read by the server. Confirmation and unsubscribe links are opaque random tokens and only a keyed hash of each one is stored, so a copy of the database does not yield a working link. There are no creator passwords to leak.

Changes

If this policy changes in a way that affects what is collected or who it is shared with, the date at the top of this page changes with it. The wording a subscriber agreed to at sign-up is stored as it was and is not rewritten by a later version of this page.