Changelog

What shipped, and what it changed

Every change customers can see, in the order it happened. Where something altered behaviour you were relying on, it says so — and where it changed nothing for existing keys, it says that too, because that is usually the first question.

25 entries  ·  July–October 2026  ·  updated 2026-10-30

October 2026

Your own headers, on the message and back on the webhook

Send up to ten headers of your own with a message — a survey id, an invoice number, a case reference — and they travel on the message and come back on every webhook event for it. Names are checked against a published reserved list, and anything that would overwrite one of ours, or carry a line break, fails the send with a 422 naming the header rather than being quietly stripped. If nothing at the receiving end needs to read the value, tags still does the same job and keeps it private.

One-click unsubscribe headers are now signed

List-Unsubscribe and List-Unsubscribe-Post are now inside the DKIM signature on both sending paths, not merely present on the message. RFC 8058 asks for that, and a receiver who checks will see them covered by the h= list. Nothing changes on your side, and nothing already sent was affected.

A public FAQ, in both languages

A public FAQ at /faq, answered in English and French: what we hold and what we do not, where the data lives, what happens to a suspended account, how suppression works, and which stream a key should be on. Written from questions customers actually asked, which is why some of the answers are less flattering than a sales page would allow. It grows as questions arrive rather than being finished.

New keys can diagnose, not just send

A new API key is created as Send and diagnose: it can send, and it can read back what happened — delivery status, bounces, suppressions, which DNS record a domain is missing. It still cannot suppress an address, create a webhook endpoint, add a sending domain or touch your team. Existing keys keep the scope they were made with; rotate one to pick up the new default.

Retries that can't send twice

Pass an idempotency_key of your own on a send and a retry stops being a risk. An identical retry within 24 hours returns the first response again, with HTTP 200 and an Idempotent-Replay: true header, and no second message goes out. A retry while the first is still running answers 409; the same key with a different message is refused with 422 rather than quietly handing back the first message's id. A send we reject releases its key, so a bad address is something you fix and retry with the same key. Without a key, nothing changes.

A webhook endpoint per API key

An endpoint can be bound to a single key, so staging events reach your staging receiver and production reaches production. Leave it on All keys and it behaves as it always has — every endpoint that existed before this is unbound. Every event we can attribute to a key now carries api_key_id as well, so one shared endpoint can route on it instead.

Seven more tools for AI assistants

Zedmail's MCP server gained the diagnostic tools: check a domain's DNS, find out why an address is not receiving, read bounce and complaint rates, list and test webhook endpoints. An assistant can now answer “why did that bounce” without anyone opening a ticket. A key only ever sees the tools its own scopes permit.

90 days' notice if we ever shut down

Section 7 of the terms now commits to at least 90 days' written notice, with the service running normally throughout, nothing billed past the stop date, unused prepaid credit refunded, and your sending data, delivery logs and suppression lists exportable the whole time. A municipal customer asked for it in writing, which was a fair thing to want and something we should have stated already.

An opt-out can be scoped to one key

Somebody declining your newsletter should not thereby decline their own password resets. On a transactional key the unsubscribe can be narrowed to that key alone, instead of the whole account. Spam complaints and hard bounces stay account-wide, deliberately: a complaint is a statement about you and that recipient, and a dead mailbox is dead for every key you own.

You hear it from us, not from a 401

If sending is ever held on your account — a bounce or complaint rate over threshold, say — you are emailed at once with the reason. Until this, the only notice an account got was its own next API call failing.

A public authentication checker

/email-check reads any domain's SPF, DKIM and DMARC the way a receiver does and says what is wrong with it. Free, no account, and it works for domains that have nothing to do with us.

Suppression lists hashed at rest

The service-wide suppression list is stored hashed rather than in the clear. Service-wide entries persist while any account still suppresses the address, on a three-year clock, and legal holds are permanent.

A published data processing agreement

Drafted with counsel and published at /dpa.php rather than produced on request. It forms part of the terms and is accepted with them; we will execute a signed copy if your process needs one on file.

September – early October 2026

Attachments

Up to ten files and 10 MB per message. We do not keep them — the bytes are deleted as the message leaves us, and only the filename, type and size stay on the record.

Choose your own retention, 7 to 365 days

Set per stream, so your transactional logs and your campaign logs need not keep the same schedule. When the window passes the whole record goes together: recipient, subject, body and delivery status. Seven days is the floor.

Transactional and broadcast streams

Every API key you create is now one or the other, and the choice changes behaviour rather than labelling it. Transactional sends no unsubscribe footer — nobody should be able to opt out of their own password reset. Broadcast always adds one, in your recipient's language. The two also keep their reputation apart, so a campaign having a bad week does not follow your receipts into the spam folder. Existing keys are unchanged.

A second and third sending address

Separate IP pools, warmed deliberately over months, so that one sender's list problem stops being everyone's deliverability problem. The warming moves a measured fraction of real traffic rather than moving a sender, because receivers judge a new address on the shape of its volume.

Verified TLS you can require

Per key, you can demand that a message is encrypted to a server that proves its identity. If the receiver cannot, the message is held rather than sent in the clear, and we tell you which recipients were affected — and they are not unsubscribed for it. For the major consumer providers it is enforced regardless, because they publish policies saying their servers should never accept unencrypted mail.

August 2026

Erasure that is distinct from suspension

A user-initiated GDPR or Law 25 erasure is now its own terminal state rather than a suspension that looks like one, so reporting, support and every access gate can tell the two apart.

Encrypted off-site backups, verified nightly

Nightly encrypted backups to Québec object storage, with the decryption key held offline so a compromised server cannot read them. Freshness, size and checksum are verified every night, and a full decrypt-and-restore is tested on a schedule. A backup nobody has restored is a hope, not a control.

Pause sending, without suspending an account

A reversible, send-only hold. An account under review stops sending but keeps its dashboard, its keys and its data — which is the difference between a question and a punishment.

July 2026

A plain guide to the DNS

/domain-setup, written for the person who has been handed a registrar login and a list of records, and linked from the dashboard where that person actually is.

Dates in your timezone

Every timestamp in the dashboard renders in the timezone on your account. It had been collected, validated and stored for years while every date on screen was still UTC.

French, properly

The dashboard, the public pages, the account emails and the unsubscribe and feedback pages your recipients see. Subscriber-facing pages negotiate the language from the browser, because a recipient has no account with us to carry a preference.

Billing in your own currency

Canadian dollars, pounds, euros or US dollars, chosen at signup, with their own price points rather than a conversion. Invoices keep the currency they were issued in.

Smaller fixes are not listed. Deliverability work mostly is not either, because it is continuous rather than datable — but when it changes something you can observe, like a sending address or a bounce you would otherwise have seen, it appears here.