SlipperySign Mail
Sending
It leaves your mailbox, not our relay
The Gmail API, from the user's own account, under a revocable gmail.send grant. Your domain, your SPF and DKIM, your reputation, and a copy in her Sent folder.
SlipperySign Mail
SlipperySign Mail is a drag-and-drop editor for internal company email. You build the message here; your own Gmail account sends it. So it lands where your daily mail lands, it carries your own domain's authentication, and there is no list of your staff on our side for anyone to ask for.
Built in SlipperySign. Delivered by Anna's own mailbox. This is what her colleagues open.
No relay address, and no “via” line beside her name. It is her mailbox, so it is simply her email.
Into her inbox, in the same thread. A Reply-To can point them at a shared mailbox on your own domain instead, unless your distribution list sets its own reply behaviour, which wins.
It travels the same path as every other internal mail, so it arrives where internal mail arrives.
Because she sent it. There is no separate system of record to reconcile at audit time.
All six follow from one decision: the mail leaves your mailbox instead of ours. A vendor who relays your mail cannot copy a single one of them without rebuilding their product from the delivery layer up.
Sending
The Gmail API, from the user's own account, under a revocable gmail.send grant. Your domain, your SPF and DKIM, your reputation, and a copy in her Sent folder.
Recipients
No upload, no import, no directory sync. Campaigns are addressed to the distribution lists and group aliases you already run, and your mail provider expands them at send time. We never see who is on them.
Measurement
Opens are one counter per campaign, clicks one counter per link, plus a daily total. Nothing is recorded against a person, so the report a manager asks for cannot be produced, by us either.
Custody
It is held in the browser for the duration of the send, then discarded. There is no password field and no password store anywhere in the product. Google authenticates and hands us a verified address.
Residency
Files are written to an EU-jurisdiction bucket, so the bytes are held there rather than merely described that way. If they need to be somewhere else, that is a reason to run your own copy: it is one Worker, one database and one bucket, deployed to your Cloudflare account, in the jurisdiction you pick.
Delivery
Every change goes out through the same pipeline: the full test suite, a build, then a deployment that verifies itself against the live site before it is called done. Fixes reach you the day they are written rather than in a quarterly release, and there is no version for you to install.
Every other tool in this category begins by asking you to hand over your people, one row at a time. This one begins from the list you already have. You send to [email protected], one address, and your mail provider opens it at delivery and fans it out to everyone your directory says belongs there.
Membership stays where it belongs: in your directory, maintained by the people whose actual job that is. We hold one address. We never see who is behind it.
The zero is a property of how the product is built, not a promise. There is nothing a per-person report could be assembled from. Underneath it, every kind of address the system does hold, listed. Ask any other vendor in this category for the same page.
recipients we can name Across every campaign, every open, every click, for every customer.
Opens are one counter per campaign. Clicks are one counter per link. There is a per-day total, and that is all. There is nowhere a per-person report could be assembled from.
Campaigns are addressed to the distribution lists and group aliases you already have. Your mail provider expands them at send time, we never see the membership.
There is no password field and no password store. Google authenticates the person and hands us a verified email address.
The only addresses in the system belong to people who use SlipperySign, the ones who write, send, approve and share the campaign. Everyone it is sent to stays in your directory.
Whose address we hold
What the analytics hold
Counters, and nothing beside them. No recipient, no device, no IP address, no per-person history, so a report naming who opened your email or clicked your link cannot be produced, by us or by anyone who compels us. That is a property of how it is built, not a setting somebody could turn back on.
The architecture is why you would move. This is why you would stay. Drag-and-drop components, brand regions you can freeze, approval that blocks the send, and MJML underneath so Outlook renders what you actually built.
Everything on this page works today and is what you get. Beta here means the shape can still change, not that anything on it is a promise waiting to be built.
Sending, recipients, measurement, token custody and residency are answered above. Here are the last four.
The foundation under your internal communications is audited against the standards your security team is going to ask about, the same bar as the rest of your stack.
These certificates belong to the infrastructure provider we run on, not to SlipperySign. We name the foundation. We do not borrow its badges.
Written for the person who has to sign this off, not for the person who wants it.
Through the Gmail API, from the signed-in person's own account, under a revocable gmail.send grant. Your tenant does the work. There is no relay in the path, no shared IP pool, and no sending domain to warm up.
Your campaign takes the same route as every other message that person sends: your domain, your SPF, your DKIM, your reputation. It arrives where your internal mail already arrives.
A vendor sending from their own IP pool is asking your filter to trust a stranger, and to keep trusting it while every other company on that pool behaves however they like. We are not asking it to trust anyone new.
To the sender, in the same thread, because it is the sender's mailbox. If you would rather they collected somewhere shared, set a Reply-To on the campaign, at an address on your own domains, which is the only kind it will accept.
One thing worth knowing before the first send rather than after it. Check it by reading the headers, not by pressing Reply. Send a test, then use Show original on the copy that arrives: if the Reply-To is in there, it survived.
Pressing Reply cannot tell you that. Replying to a message you sent yourself addresses its recipients rather than the Reply-To, so the obvious self-test fails even when the header is perfect, and separately, a distribution list can set its own reply behaviour, which wins over any header. The raw message distinguishes the two in about a minute.
In the sender's Sent folder, because she sent it. Your mail system stays the single source of truth, so when somebody asks what was sent and when, the answer is already where your retention and eDiscovery rules can see it.
None from us. Campaigns, recipients and opens are all unlimited. Your own Gmail limits still apply, because your own account is doing the sending. That is the trade that makes everything else on this page possible.
No. Nothing to upload, nothing to import, nothing to keep in sync. You address a campaign to the distribution lists and group aliases you already run, [email protected], and your mail provider expands them at delivery.
We store the alias. We never see who is behind it.
Nothing, on your side. Membership lives in your directory, maintained by the people whose job that is. The next campaign is simply correct.
No, and neither can anyone who compels us. Opens are one counter per campaign, clicks one counter per link, plus a daily total. Nothing is recorded against a person, so there is nothing for a per-person report to be assembled from.
The full contents of the analytics are listed under what we store.
Yes, and in a place we do not control. Because SlipperySign asks your own tenant for permission to send, your Google Workspace administrator decides whether it may be granted that permission at all, under API controls in the Admin console. Blocked there, nobody in your tenant can connect it, whatever we would prefer.
The grant is one scope, gmail.send, and your administrator can revoke it at any time from your own console without asking us. A relay-based tool cannot offer that: once your list is on their servers, turning them off does not take it back.
No. Reply-To and BCC are held to your own registered domains and refused otherwise.
That restriction exists because of what this product is good at: the message carries a real colleague's real address, so it is the most trusted mail your staff get. Pointing its replies at an outside mailbox would be business email compromise with the difficult part already done, and a BCC is invisible, so nobody reviewing the campaign, including the approver, would ever see it.
If replies genuinely need to reach an outside helpdesk, an administrator adds that domain. A deliberate act with a name against it, rather than a text field anyone can type into.
The addresses of the people who use SlipperySign, whoever writes, sends, approves or is shared into a campaign, plus your administrators, the group aliases you save, and an audit log of administrative actions. All of it is listed under what we store.
That is what an account needs in order to work. The people you send to are not in it.
Nowhere. There is no password field and no password store in the product. Google authenticates the person and hands us a verified address.
The send token is held in the browser for the duration of the send and then discarded. It never reaches our servers.
EU customers are pinned to EU jurisdiction at the storage layer. The bytes are held there, not merely described that way. Residency sits on your company record rather than on the region we happen to run in, so it is a setting rather than a migration.
As long as you say. Retention is set per customer for campaign content and for tracking detail, and applied on a nightly schedule. Zero means keep it. Any other number means delete after that many days.
SOC 2 Type II, ISO 27001:2022, ISO 27701:2019, ISO 27018:2019 and PCI DSS.
Those certificates belong to the infrastructure provider we run on, not to SlipperySign. We name the foundation. We do not borrow its badges.
Continuously. Every change runs the full test suite, builds, deploys and then verifies itself against the live site before it counts as done, so there is no release to wait for and no version for you to install.
In practice that means something reported in the morning is often live the same afternoon. It also means the answer to "can it do X" is worth asking rather than assuming, because the distance between asking and having it is short.
That the product works and is used, and that it is early enough for screens and features to still move. Every feature described on this page is built, tested and running, beta is not a word for unfinished, it is a word for young.
What is not beta is your data. Campaigns are backed up, exportable and deletable by your own admin, and the privacy commitments on this page apply now, not later.
The Google account you already use. Your company's domain is registered to your account, so colleagues on it can sign in and share campaigns, and nobody outside it can.
Nothing to install, no DNS to change, no contact list to prepare.
It sends internal email and it does nothing else. No intranet, no chat, no employee app, no survey suite. If you want one vendor for all of that, this is the wrong product, and the reasons page explains why that is on purpose rather than a gap.
The Google account you already have. Nothing to install, no contact list to upload, no sending domain to warm up.
Start sendingSlipperySign Mail, first of a family. Tools for learning experiences follow.
