The technical ledger, not the announcement reel
This is the record of what changed in the sending platform, the API and the authentication stack — written for the engineer who needs to know whether a change touches their integration before it surprises them in production. Keep a Changelog format, ISO-dated, with breaking changes and security fixes always on their own line. No "thrilled to announce." Just what moved, when, and whether it affects you.
What changed, when, and whether it affects you
This is the record of changes to the sending platform, the API, the authentication stack and the operational tooling. It exists for a specific reader: the engineer or operations lead who needs to know whether a change touches their integration before it surprises them in production. We keep it in the Keep a Changelog format, dated in ISO 8601, with each entry sorted into the category that tells you how much attention it deserves: a security fix and a copy tweak look different here because they are different. Breaking changes and security patches always get their own line, never folded into a general "improvements" note, because burying a breaking change is how you lose a customer's trust in a single deploy.
A note on what this is not. It isn't marketing release notes — there's no "we're thrilled to announce" here, and benefit-led feature descriptions live elsewhere. This is the technical ledger. If a change has no effect on how you integrate or what you can rely on, it generally doesn't appear; if it changes behaviour you might depend on, it does, even when the change is small. Dates are the release date in UTC. Where a change carries migration work, the entry says so plainly.
2026
2026-04-22 · Security
Enforced MTA-STS in enforce mode across all shared sending domains, with TLS-RPT reporting endpoints published. Connections that cannot negotiate TLS to a supporting receiver now fail closed rather than falling back to plaintext. No customer action required; managed customers on custom domains were migrated individually in the preceding two weeks with notice.
2026-03-30 · Added
DANE/TLSA record provisioning is now available for customers whose receiving partners run DNSSEC, offered alongside MTA-STS rather than as a replacement. Relevant primarily to senders with German, Dutch and other DNSSEC-heavy correspondent networks. Opt-in per domain through the dashboard or by request to the operator team.
2026-02-18 · Changed
The aggregate DMARC report ingestion pipeline was rewritten to process reports on a four-hour cycle rather than daily. Placement and authentication anomalies now surface to the operations team the same business day in most cases. No API surface changed; the only visible effect is faster anomaly alerts for managed customers.
2026-01-12 · Fixed
Resolved an edge case in SPF flattening where a correspondent domain publishing more than ten nested includes could intermittently push a flattened record past the 255-character TXT segment limit. The flattener now segments correctly and warns when a source record is pathologically large. Affected a small number of customers with unusually complex upstream SPF.
2025
2025-11-03 · Added
BIMI support with Verified Mark Certificate validation, including a self-service validator that checks the four gates (DNS record, DMARC enforcement, SVG Tiny P/S conformance, and certificate chain) before you commit. Available to any customer at DMARC p=quarantine or stricter.
2025-09-15 · Changed
Default minimum TLS version for outbound delivery raised to 1.2, with 1.3 negotiated wherever the receiver supports it. Receivers still offering only TLS 1.0/1.1 — an increasingly rare and security-relevant case — now require an explicit per-domain exception rather than silent downgrade. A handful of legacy correspondents were flagged to affected customers ahead of the change.
2025-07-21 · Deprecated
The legacy v1 webhook payload format is deprecated in favour of v2, which carries structured authentication-result fields and a stable event schema. v1 continues to function through at least 2026-12-31; the deprecation notice exists so integrations can migrate on their own schedule rather than under pressure. Migration is a field-mapping exercise, documented in the API reference.
2025-05-08 · Added
Per-stream isolation on Managed PowerMTA, allowing transactional and bulk traffic to run on separate virtual MTAs with independent reputation, queues and throttling under a single account. This was the most-requested capability from high-volume customers and lets a marketing send stop poisoning a password-reset stream's reputation.
2025-02-26 · Security
Rotated and re-issued DKIM signing keys to 2048-bit across all managed domains still on 1024-bit, with the older selectors retained for a 30-day overlap so in-flight mail validated against either. Routine hygiene rather than a response to any incident, but logged here because key rotation is the kind of change an auditor will ask about.
2024
2024-10-09 · Changed
Migrated the customer dashboard to a rebuilt backend with sub-second load on the deliverability views that previously took several seconds at high log volume. No data model change; bookmarked URLs and API tokens continued working unchanged.
2024-06-17 · Added
Region selection for Custom-tier customers, adding a German data-centre option alongside the Swedish default, both inside the EU. EU-only residency remains the default for every plan; this change made the specific location selectable rather than introducing any non-EU routing.
2024-03-04 · Fixed
Corrected a bounce-classification bug where certain soft bounces from one major mailbox provider were being categorised as hard bounces, causing premature suppression of recoverable addresses. Affected suppression entries from the preceding window were reviewed and the incorrectly suppressed addresses restored for affected customers.
Earlier
The platform has run continuously since 2003. The entries above cover the period since we began publishing a structured public changelog; the deeper history — the move to dedicated-IP-by-default, the original PowerMTA tooling, two decades of incremental hardening — predates this format and lives in the operational records rather than here. If you need to understand a change from before this log for a compliance or audit reason, the operator team can pull the relevant history.
How to track changes that matter to you
Breaking changes and security entries are the ones worth subscribing to. Registered API consumers receive notice of any breaking change well ahead of the effective date, and security-category entries are communicated directly rather than left for you to discover here. For the developer-facing detail behind any entry — endpoint schemas, payload shapes, migration steps — see the API reference, and for anything ambiguous, ask the operator team directly.
How we version, and why it looks like this
We version this log by date rather than by a semantic version number, and that's a deliberate choice for the audience. A semantic version like 4.7.2 communicates magnitude to a developer consuming a library, but for email infrastructure the meaningful question is almost always "what changed and when," not "which numbered release am I on." Dates answer that directly: you can scroll to a month and see everything that moved. Where a change does carry a breaking API implication, the category label and the entry text carry that signal explicitly, which is more reliable than asking a reader to decode a version increment. The API itself is versioned separately at the endpoint level, so an integration pinned to a given API version keeps working regardless of what appears here.