Release ledger · Vol. I

What changed in the inbox,
and why it matters.

The changelog is the public ledger for Emcognito WebMail. It records product changes, reliability work, and setup guidance in the language an operator can act on: what changed, who it helps, and what to try next.

Latest

12 May 2026

Entries

4

Scope

Product · Reliability · Manual

I · Release notes

No. 004

Android availability is now part of the public product story.

The homepage now treats the Android app as proof that the same multi-domain inbox works on the phone operators already use.

  • New

    Android app link on the homepage

    The landing page now links to the Emcognito WebMail Android app on Google Play while keeping web signup as the primary action.

  • Improved

    Mobile release panel

    A new mobile section explains that Android is live, iPhone is coming next, and the same account, identities, passkey sign-in, and auto-From behavior carry across devices.

  • Improved

    App-aware structured data

    Homepage SoftwareApplication metadata now reflects Web and Android availability and points crawlers to the Google Play listing.

No. 003

Clearer setup, safer billing, better sending identity control.

Today's work focused on reducing setup uncertainty and making account state changes more dependable behind the scenes.

  • New

    Native From selector in compose

    Compose now exposes a first-class From dropdown so multi-domain operators can choose the exact sending identity before a letter leaves the desk.

  • Improved

    Expected-vs-found DNS checks

    Domain setup now shows clearer DNS verification differences, making it easier to spot a copied value, stale record, or registrar formatting issue.

  • Fixed

    Tighter DKIM and DMARC verification

    Verification now handles DKIM and DMARC edge cases more carefully, so a domain is less likely to sit in an unclear partially verified state.

  • Reliability

    More resilient subscription handling

    Stripe subscription webhooks now handle duplicate and thin events more defensively, keeping billing status aligned when providers retry or send compact payloads.

  • Improved

    DMARC reporting documentation

    The Manual now explains DMARC aggregate reporting authorization so operators understand why the wizard asks for the records it does.

No. 002

No-card preview and a cleaner Workspace migration path.

This release made the first trial safer and gave Google Workspace switchers a concrete DNS plan before they move mail.

  • New

    No-card preview

    New accounts can start with one domain and 25 sends before adding a card. The card-required trial begins only when the operator chooses to lift those caps.

  • New

    Google Workspace migration wizard

    A public cutover guide now walks Workspace users through a no-downtime MX transition, including overlap, verification, and when to cancel the old tenant.

  • Improved

    Preview-cap follow-ups

    Upgrade prompts and account state copy now match the new preview model, removing stale wording from CTAs and billing explanations.

  • Improved

    Push notification groundwork

    Native push notification plumbing and iOS APNs configuration were wired so the mobile app can notify operators about new correspondence.

No. 001

Public pages received a conversion and clarity pass.

The earliest changelog entry covers the visible product-market surfaces: how the site explains the product, handles capture, and routes readers.

  • Improved

    Landing-page QA fixes

    Tap targets, analytics consent placement, and public-page wiring were tightened so prospects can evaluate and start without small layout snags.

  • Improved

    Newsletter capture polish

    The newsletter flow now gives a clearer success state and avoids pointing readers at a direct email CTA that was no longer part of the public surface.

  • Improved

    Founder and editorial polish

    The public story gained stronger founder framing and magazine-style details that better match the single-reader, many-identities positioning.

II · How to read this page

Not every commit belongs in the ledger.

User-facing changes are written here when they alter setup, sending, billing, deliverability, or the public manual. Internal infrastructure work appears only when it changes the reliability or safety a customer would actually feel.

The success metric is simple: fewer support questions that begin with "what changed?" and more operators completing domain setup, first send, and billing upgrades without asking for context.

Read the manualStart free

Sources