Anyone can send email in your name
Spoofed senders, look-alike domains and compromised partner mailboxes all reach your customers. SPF, DKIM and DMARC help, but customers never see them. Telling a real email from a fake is left to them.
Signed announcements for companies
Reach your customers without email
Keryx delivers signed announcements from your company to your customers' phones. Customers subscribe by scanning a QR code. They give you no email address, no phone number and no account, so there is no customer list to leak. A message without your company's signature never reaches them.
Email puts your customers at risk
Phishers do not need to break into your systems. They only need to look like you, and email makes that easy. In finance and crypto, one convincing email can empty a customer's wallet.
Every customer list is a phishing list
To send email you have to store addresses, and usually names and order history too. When that database leaks, it becomes the target list for the next phishing campaign.
Your email provider holds a copy
Most companies outsource sending. The provider needs your addresses and segments, so your customer data also sits on systems you do not control. Breaches at email providers are a recurring source of leaked lists.
How it works
-
Your team publishes
An author writes an announcement in the web console and signs it with their passkey. The service publishes it as signed static files.
-
Customers scan once
A customer scans your QR code, confirms your domain in the Keryx app, and picks the channels they want, such as offers or security alerts.
-
The app checks every message
The app verifies each announcement against keys your company authorized. If the check fails, the message is not shown. There is no warning to click through and nothing for the customer to judge.
Announcements are one way. Customers cannot reply, and the app removes forms and scripts from every message, so a message cannot collect a password. Unsubscribing happens on the customer's phone, and you are never told.
What your company does
We run the publishing infrastructure. You keep control of who may publish in your name.
1
The owner gets a Trezor
One person holds your company's master key on a Trezor hardware wallet. The device confirms every change to who may publish. The Trezor recovery seed is the backup. If both the device and the seed are lost, you start over with a new identity and every subscriber has to scan again.
2
Your web admin uploads the join kit
You download a zip with two small files for /.well-known/keryx/ and a /join page. Uploading them makes your domain the anchor customers confirm. The console tells you when the setup is live.
3
You share the QR code
Put the join link or QR code in your newsletter, on receipts and packaging, or on your website. The console generates the QR code and a snippet for your newsletter.
Authors join with an invite link and a passkey. Nobody on your team needs a command line or a server. For your customers there is a plain explanation at /subscribers that you can link from your newsletter.
The security model, in plain words
Keys are split by job, so no single party can publish in your name.
| Key | Where it lives | What it controls |
|---|---|---|
| Master key | Nowhere. Your Trezor derives it for each change and asks you to confirm on the device. | Who may publish, your company name and logo. |
| Author keys | One per author. The service stores it encrypted with the author's passkey. It is decrypted only in the author's browser, for one signature. | The content of each announcement. |
| Channel and publishing keys | On the service, encrypted at rest. | Which signed announcements are published, and keeping the published data fresh. |
What the service can do
It can delay, hold back or unpublish announcements, and it can go offline. It cannot write an announcement your customers' apps accept, because that takes an author key. It cannot add authors, because that takes your Trezor.
The caveat you should know
The console runs in your browser, and the service sends it its JavaScript. If an attacker took over the service, they could send modified code that captures an author key or your master key the next time someone signs. We accept this risk for the pilot. Each console release publishes the hash of its code, so a changed version can be detected.
Your domain is the anchor
Customers trust your domain once, when they pair. If an attacker controls your website at that moment, or a customer confirms a look-alike address, that customer pairs with the attacker. Print QR codes only on surfaces you control.
No customer data
There are no subscriber accounts, and the service does not know who your subscribers are. Like any web server, the hosts see connection data such as IP addresses when apps download updates. The subscriber app is open source and hosted separately from this service.
Request a pilot
We are taking on a small number of pilot companies. Tell us who you are and what you want to announce, and we will get back to you.
We use these details only to reply to your request.
Thanks, we have your request
We will reply to the email address you gave us.