<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Folio — Changelog</title>
    <link>https://folioinbox.com/changelog</link>
    <atom:link href="https://folioinbox.com/changelog.xml" rel="self" type="application/rss+xml" />
    <description>Public release notes for Folio: new features, reliability fixes, and migration tools for one operator running many businesses.</description>
    <language>en-us</language>
    <lastBuildDate>Wed, 16 Sep 2026 15:58:28 GMT</lastBuildDate>
    <item>
      <title>No. 024 — Adding a domain now starts by reading the DNS you already have — and a domain that quietly stops working no longer stays green.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-09-14</guid>
      <pubDate>Mon, 14 Sep 2026 12:00:00 GMT</pubDate>
      <description>Setup used to open with instructions and hope you would follow them. It now looks your domain up first, tells you whether a live mailbox is already receiving mail there, and adapts: an existing SPF record is merged rather than overwritten, and a domain with mail flowing today is migrated in stages instead of being cut over in one step. The other half of this release is the opposite direction. Verification used to be permanent — once a domain went green nothing could ever take it back, so a domain that expired, was put on registry hold, or simply had its records deleted kept reading as verified for as long as seventeen days. Folio now re-checks verified domains against both DNS and Amazon, demotes the ones that stopped resolving, and writes to the person who owns it rather than letting them discover it from a failed send. Alongside those: replies to a no-reply sender now reach the mailbox the sender actually nominated, the free deliverability audit no longer reports working SPF as broken, an active subscriber's sending is no longer held by a screen that the send path itself ignored, inbound mail keeps a real size limit and finishes in-flight deliveries across a restart, and shipping to production now requires a person to say so.

New: Domain setup now reads your DNS before it asks you for anything — Setup opened with the same seven records for everyone, regardless of what the domain was already doing — which was actively wrong for the most common case. A domain with a working mailbox on another host was shown its MX record as step one with a failing health score beside it, while the page simultaneously advised not to publish MX yet. Folio now resolves the domain live before rendering anything and states the verdict plainly: either a live mailbox was detected, in which case a staged migration keeps the existing inbox receiving until you choose to switch, or the domain is clean and can be set up in one pass. An SPF record already published by another provider is merged with Folio's rather than replaced — publishing a second SPF record invalidates both under RFC 7208, which previously either broke the domain's existing mail or silently produced an unusable record. Delegating the work is now a first-class option too: a written brief covering the whole record set can be copied, downloaded, or previewed before you send it to whoever manages your DNS.
Improved: The domain list leads with the domains that need you — The list was alphabetical, so a blocked domain and a fully verified one were equally easy to miss. Domains are now ordered by health score with the worst first — held or blocked domains ahead of everything, then partially configured ones, then the domains that are working — with an alphabetical tie-break inside each band. A search field filters by domain name or DKIM selector with a live match count, the sort can be switched to highest-score-first or plain alphabetical, and a search that matches nothing now says so rather than rendering an empty page.
Fixed: A verified domain that stops working no longer stays green — Verification was permanent in practice. Three gates decided whether a domain could send, and once all three went green the domain left the loop that checked them — so nothing could ever mark it unverified again, no matter what happened to the domain afterwards. The only thing that could eventually notice was Amazon revoking its own verification, which for one domain on registry hold took seventeen days, and for a domain whose Amazon record outlives its mail records would never have happened at all. Folio now re-checks every verified domain on both fronts: DNS records that stop resolving demote the domain, and a separate sweep confirms the sending identity is still verified upstream. A domain that has gone unreachable at the registry is now recognised as unreachable rather than being polled every five minutes forever as though its records were merely late.
New: You now hear it from us when a working domain stops sending — Noticing a domain had broken was only half the problem — nobody told its owner. There was a notice for a domain going green and no counterpart for the other direction, and the one nudge that did exist skipped anyone with an active subscription. A paying customer whose domain stopped being able to send therefore had no notification path at all and found out when a message failed. A domain that has been sending and then loses verification now generates a written notice to the person who owns it, with copy that fits a domain that was working rather than the setup reminder a brand-new domain gets.
Fixed: Replying to a no-reply sender now goes where the sender asked — Many services send from a no-reply address while naming a real mailbox in the message's Reply-To header for responses. Replies to those messages were addressed to the no-reply address instead. The compose screen had always preferred Reply-To, and mail brought in through an import kept the header — but live incoming mail arrives through Folio's own mail server, and that path was dropping the header before the message was stored, so the reply screen never saw it. Reply-To is now preserved on delivery and carried through message export.
Fixed: The free deliverability audit reported working SPF as broken — SPF records commonly include other records, and a domain reached twice through two different branches of that tree is ordinary — it is a diamond, not a loop. The audit's cycle detection used one shared set of visited domains for the entire walk and never unwound it, so any domain reachable by two sibling branches was reported as a permanent error. That verdict is not cosmetic: receiving servers treat an SPF permanent error exactly as they treat no SPF record at all. Folio's own domain was among those misreported. Cycle detection now tracks each branch separately, so a shared include resolves normally and a genuine loop is still caught.
Fixed: Sending held for subscribers whose mail was going out anyway — A new domain that tripped Folio's automated brand and registration screen was shown as held, with a note that sending would unlock once a subscription was active. For customers who already had an active subscription that note was both permanent and untrue: the screen the interface was reading and the check the send path actually applies were two different things, so their mail sent normally and the compose screen offered the identity while the domain page insisted it was blocked. Both now read the same check.
Fixed: Incoming messages had no size limit at all — Folio's mail server carried a configured 50 MB ceiling on incoming messages in a section the server does not read, so no limit was ever in force and the server advertised itself to the internet as accepting messages of unlimited size. The cap is now set where the server actually reads it, and is declared to sending servers so an oversized message is refused up front rather than transferred in full and rejected at the end.
Reliability: In-flight deliveries now finish before the mail server restarts — The mail server's graceful-shutdown setting was inert. It depended on a signal handler the server only installs when it is the first process in its container, and an init wrapper held that position — so every deploy and every node eviction severed connections mid-delivery instead of letting them finish. Sending servers retry, so mail was not lost, but delivery was delayed by each restart. Shutdown now drains in-flight sessions as configured.
Reliability: Monitoring now watches the mail path, and caught a frozen certificate — Folio had thirteen external monitors, all green, and not one of them connected to the mail port — the product's primary surface was the one thing nothing checked. It does now, and within minutes of being switched on it found a real defect: the mail server's TLS certificate was mounted in a way that is populated once when the container starts and never refreshed, so a renewed certificate was not picked up and the server was serving an expired one. The mount has been corrected and certificate expiry is now monitored directly.
Reliability: Shipping to production now requires a person — Merging a pull request deployed it. The deploy workflows ran on every merge with no approval anywhere, and an automation merges pull requests the moment their checks pass — a continuous path from a pushed branch to live production with no human in it. On one occasion that path ran end to end and sent real email that had been staged deliberately unsent. Deploys are now triggered deliberately rather than by merging. Because that makes a forgotten deploy silent by construction, a daily check now compares what is merged against what is actually serving traffic and keeps an open report of any gap; it reads the running images for the backend and mail server, and it now fails loudly instead of reporting an unknown when it cannot determine what is deployed. Jobs are also pinned to the runner platform they require, after builds were scheduled onto an unrelated machine and failed.</description>
    </item>
    <item>
      <title>No. 023 — Adding a domain is now one screen — and where your DNS host supports it, Folio writes the records for you.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-09-07</guid>
      <pubDate>Mon, 07 Sep 2026 12:00:00 GMT</pubDate>
      <description>Connecting a custom domain used to be three surfaces held together by the person doing it: a wizard printed seven DNS records, a separate page checked them, and the values were carried between the two by hand. Everything after choosing the name now lives on a single setup screen. If your domain is on Cloudflare, you paste a scoped, single-use zone token and Folio writes every record through the API, reporting exactly what it created, merged, kept or skipped — an existing SPF record is merged rather than replaced, an enforced DMARC policy is left alone, and mail delivery is never cut over to Folio without you ticking a box that says so. If your domain is at GoDaddy, IONOS, Squarespace Domains, WordPress.com or another Domain Connect host, a button naming your own host hands the whole record set to them, signed so the host can verify the request really came from Folio. Alongside it: the plan you click on the pricing page now survives the entire signup, including email links, codes, passkeys and a cancelled checkout; the mobile inbox opens with a welcome rather than a blank mailbox and offers a retry instead of a false empty inbox when a request fails; there is a new free WorkMail migration checklist and a fit check to take before you switch; and the comparison pages had a factual audit that corrected a send limit important enough to change which provider some people should pick.

New: Connect a domain on one screen, with your DNS host doing the work where it can — Adding a domain meant reading seven DNS records off a wizard, leaving to enter them at your registrar, and returning to a different page to find out whether they had taken. Nothing told you when it worked, so anyone who closed the tab simply never learned. Everything after naming the domain now lives on one setup screen, and every route that used to send you elsewhere — the domain list, the verification nudge, the next-step card and the domain detail page — deep-links straight to it. The fast paths come first. On Cloudflare, you mint an Edit zone DNS token scoped to that one zone, paste it, and Folio writes every record through the API and reports what it created, merged, kept or skipped; the token is used for that one operation and never stored. Your existing SPF record is merged rather than overwritten, an enforced DMARC policy is kept as you set it, and an MX record pointing at another provider is never removed unless you explicitly tick the cutover box — which is only shown when another host is actually receiving your mail today. On a Domain Connect host such as GoDaddy, IONOS, Squarespace Domains or WordPress.com, a Connect with your host button appears once Folio has confirmed that host supports it, and hands over the record set for you to approve there. Those hand-off links are now cryptographically signed, so the receiving host can verify the request genuinely came from Folio and has not been altered in transit, and Folio's public verification key is published in DNS for them to check it against. Everything else — the record-by-record manual list, copy buttons, and live verification — is still there for hosts that support neither path.
Fixed: The plan you chose no longer disappears during signup — Clicking a plan on the pricing page did not actually carry that choice into signup: the tier and the monthly-or-yearly cadence were both discarded, and you arrived at billing with nothing selected and no indication that anything had been lost. The selection now travels the whole way through — through an emailed sign-in link opened in a different browser, through a verification code, through a passkey, and back again if you start checkout and cancel it — and ends at an explicit confirmation screen that states the plan and cadence before anything is charged. The pricing page also gained a short plan finder that recommends a tier from how much mail and how many domains you actually have, and the no-card preview is now clearly separated from the trial that does ask for a card, so it is obvious which one you are starting. Billing now waits for your account status to be genuinely current before it renders, offers a retry when a service call fails instead of showing a wrong state, and returns an expired session to sign-in without throwing away the plan you had picked.
Improved: The mobile inbox now opens with a welcome instead of a blank screen — Opening the app on a phone showed an empty mailbox while mail was still loading, which is indistinguishable from having no mail. Startup now shows a short “Getting your inbox ready…” message with quiet placeholder rows, and the notices that sit above the message list — billing warnings and domain setup guidance — are held back until mail has actually loaded, so an account whose billing status simply had not arrived yet is no longer told its billing is inactive. If a request fails or times out, you now get a retry instead of a mailbox that falsely reports being empty, and messages already on screen are kept rather than cleared when a refresh fails. Switching folders or searching quickly no longer lets a slower earlier response overwrite the newer one, and a slow identity lookup no longer holds up the messages themselves.
New: A free WorkMail migration checklist, and a fit check to run before you switch — Anyone weighing a move off Amazon WorkMail can now download a versioned migration checklist from the WorkMail migration hub with no account, no email address and no form, and share it by link. Next to it is a short capacity check that says plainly when Folio is the wrong tool — shared team queues, groupware calendaring and bulk sending are disqualified rather than sold to — so you can find that out in a minute instead of after a migration. The hub's own guidance was corrected too: the previous instructions could put a live domain through an avoidable delivery gap during cutover, and a section of the page could not be reached by keyboard.
Fixed: Comparison pages understated Migadu's daily sending limits — Our Forward Email versus Migadu comparison stated that Migadu had no published cap on outbound mail. It does: on the $19-a-year Micro tier the limit is 20 outgoing messages a day, counted across every domain and mailbox on the account. That single figure changes the recommendation, because the tier that actually matches Forward Email's 300-a-day allowance is Migadu's $290-a-year Standard plan, not the $19 one — so the comparison people were making was between the wrong two numbers. Re-checking both vendors' own pages on 7 September also found that Migadu's Standard tier was missing from our pricing table entirely, and that its administrative API was listed as unavailable when it exists. Three further Migadu comparisons said nothing about send limits at all, leaving the cheapest tier reading as unmetered; each now carries the per-tier caps in its feature table, pricing table, verdict and FAQ. Counterpart limits for Fastmail, Zoho Mail, Purelymail and Google Workspace were verified against each vendor's own documentation on the same day.
New: A new Purelymail versus Forward Email comparison — A new page at Purelymail vs Forward Email compares the two on the point most comparisons skip: what each one's terms of service actually permit. Purelymail's terms prohibit using the service to send mailing-list or advertising email and allow immediate suspension, with payments non-refundable; Forward Email's explicitly permit transactional and opt-in marketing mail subject to unsubscribe headers and a one-time domain review. For anyone who wants a cheap mailbox and also sends a monthly update to their own list, that is the deciding difference rather than the price gap. The page also works out the storage crossover point from each vendor's published add-on rates, and was written from a fresh reading of both vendors' pricing, features, FAQ and terms pages rather than copied from a sibling page.
Improved: Buyer guides rewritten against provider documentation, with the wrong claims removed — Five guides covering custom-domain email without Google Workspace, multi-domain webmail, the cheapest way to host several email domains, and email hosting for multiple websites were rewritten with sourced direct answers, comparison tables, setup steps and visible FAQs. The rewrite existed mainly to remove things that were not true: Google Workspace licensing was described in a way that implied a charge per domain rather than per user, several competitors' capabilities were overstated, and the pages carried blanket claims about being cheapest and about deliverability and privacy that nothing supported. Each replacement cites the provider documentation it reads from, discloses that Folio wrote it, and says where Folio is the wrong fit. Separately, twelve pages that were all competing for the same Google Workspace question have been consolidated onto the five that people actually reach, and two comparison pages that existed but were linked from nowhere are now reachable from the comparison index.
Reliability: Marketing links keep their tags through the CDN, and the redirect map has room to grow again — Public pages are served through a CDN rule that tidies up URLs, and it was stripping every query string — which quietly removed the campaign tags on any link shared from a newsletter or a social post before anything could record where the visit came from. The five standard campaign parameters are now preserved through those redirects while everything else is still tidied away, the canonical URL published to search engines stays clean, and there is a check after every deploy that a tagged production URL still arrives with its tags. The same CDN function holds the site's redirect map and must fit inside a hard 10,240-byte limit that is only enforced when a deploy runs, and it had been left with 152 bytes of headroom — less than one more redirect. Moving its explanatory comments out of the shipped block and into the surrounding template, which is not counted, restored 2,294 bytes without deleting a single line of the explanation or changing any behaviour.</description>
    </item>
    <item>
      <title>No. 022 — A second spam report now blocks the whole domain, open tabs survive new deploys, and transport security moves to full enforcement.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-08-31</guid>
      <pubDate>Mon, 31 Aug 2026 12:00:00 GMT</pubDate>
      <description>Reporting spam on messages from the same domain twice now automatically blocks that domain for your account, stopping senders who rotate email addresses from walking back into your inbox. Alongside it, inbound mail defense received a major hardening: credential-phishing lures and advance-fee scams can no longer slip past on self-signed authentication, while sender reputation is now measured against mail you actually open. Frontend deploys no longer freeze open browser tabs or demand a hard reload, MTA-STS transport security across Folio's domains has graduated from testing to strict enforcement, and background domain setup alerts now retire quietly after four warnings.

New: A second spam report now blocks the sender's entire domain — Reporting a message as spam previously blocked only the specific sending address (such as sender@example.com), which let throwaway spammers rotate their mailbox names and continue landing in your inbox. When you report spam from the same domain a second time, Folio now automatically blocks that domain for your account. The block is kept strictly per-user so one person's reports never affect another mailbox, shared providers like Gmail or Outlook are never blocked, and marking a message as Not spam immediately revokes the block and resets the counter. The rule has also been backfilled for domains you had already reported repeatedly.
Fixed: Spam and phishing senders can no longer buy a pass by authenticating as themselves — Senders that publish SPF, DKIM, and DMARC records for their own throwaway domains previously received a substantial score discount, allowing credential harvesting lures and advance-fee pitches to land clean in the inbox simply because they passed DNS checks they controlled. The authentication discount floor has been raised so valid DNS stops earning penalties without granting a free pass for malicious content. Brand impersonation detection now catches fraudulent links regardless of the sender's own domain authentication, and a new body scanner identifies credential-phishing phrasing such as requests to verify your email address or confirm account details.
New: Advance-fee scam detection and engagement-based sender reputation — Advance-fee pitches and donation lures rarely link to phishing sites or impersonate known brands, allowing them to dodge traditional heuristics. A 69-term advance-fee lexicon now flags these messages when received from untrusted or stranger domains. To distinguish between unknown spammers and genuine low-volume correspondents (such as login codes or service notices), Folio now tracks an engaged status for senders whose mail you have opened or replied to without complaint. Furthermore, sender reputation for low-volume domains is now calculated against mail you actually touched rather than everything delivered, preventing senders from staying unscored by pushing unread volume.
Fixed: Publishing an update no longer freezes open browser tabs — When a new version of the web app was deployed, previously cached chunk files were deleted from the server immediately. Any browser tab left open across a deploy would fail when navigating to a new screen or lazy-loading a component, freezing the interface without an error until the user manually performed a hard refresh. Deploys now retain hashed assets on the server with a 7-day grace window before pruning stale files. In addition, the web app now detects missing or out-of-date bundles across all major browsers and automatically reloads to the intended page, with cooldown guards to prevent reload loops.
Improved: MTA-STS transport security graduated to full enforcement — Folio's incoming recipient domains (including folioinbox.com and wm.emcognito.com) have moved their MTA-STS (Mail Transfer Agent Strict Transport Security) policies from testing mode to strict enforcement. Following weeks of zero-failure TLS reporting from major email providers and direct verification of all MX endpoints, sending servers are now instructed to require encrypted TLS connections and valid certificates when delivering mail to Folio. The deployment automation was also updated to verify changes against authoritative nameservers directly, eliminating false deployment timeouts caused by caching resolver delays.
Reliability: Domain setup alerts now retire cleanly after four attempts — When a newly added custom domain was left without DNS configuration, the background verification engine would log a stuck-domain warning every few hours indefinitely. Setup warnings are now tracked directly on the domain record and capped at four alerts spaced across 18 hours, clearly stating when the final reminder has been reached. Any subsequent DNS progress automatically resets the counter, and incomplete domain setups remain fully visible in the admin dashboard.
Reliability: Self-hosted runner jobs now carry explicit execution ceilings — Every automated test, build, and deployment job across our workflows now declares an explicit timeout ceiling scaled to its historical run duration. If a self-hosted runner process is interrupted or fails mid-job, the pull request is failed promptly rather than remaining blocked for GitHub's default six-hour limit.</description>
    </item>
    <item>
      <title>No. 021 — Mail too large to store was being accepted and then lost — that's fixed and the lost messages recovered, alongside a free deliverability audit anyone can run.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-08-24</guid>
      <pubDate>Mon, 24 Aug 2026 12:00:00 GMT</pubDate>
      <description>A message whose contents ran past a storage limit could be accepted from the sender and then quietly discarded, with nothing to tell either side it had happened. That is fixed at every write path, the affected messages have been recovered from the raw archive, and a sender now gets a retry rather than a false acceptance. Alongside it, Folio's free public tools had a substantial pass: a new deliverability audit that grades a domain's authentication and transport setup against the actual standards, a plain-language explanation under every check with a command you can run yourself to confirm it, and an end to several ways those tools could mislead — a working DKIM setup reported as missing, a score printed as 100 out of 85, a green tick over a sentence saying a standard was not configured, and “we'll email your report” on a button that never sent anything. Also in this release: a sharper homepage with a Sign in link that finally goes to the sign-in page, mobile confirmations that no longer sit on top of the buttons underneath them, and two blog rendering fixes.

Fixed: A large incoming message could be accepted and then lost — A letter whose contents exceeded the size limit of the database row it was stored in was accepted from the sending server — which was told, correctly as far as it knew, that delivery had succeeded — and then discarded. No copy was stored, no notification fired, and nothing bounced, so neither the sender nor the recipient had any way to know the message had existed. Attachments were never the cause; they have always been stored separately. Large message contents now spill to separate storage with the row keeping a pointer, so nothing is capped by that limit any more, and the same rule applies to every path that writes a message, including imports. If storage genuinely fails, delivery is now refused with a temporary error so the sending server retries — a real retry rather than a false success — and repeat deliveries of the same message are recognised so a retry can't produce a duplicate. Every message already lost to this has been recovered from the raw archive Folio keeps of everything it accepts.
New: A free deliverability audit for any domain — A new public tool grades any domain's email setup across four areas — authentication, transport security, brand indicators, and reputation — with eighteen individual checks covering SPF, DKIM, DMARC, BIMI, MX, MTA-STS, TLS-RPT, DANE and blocklist listings. Each check cites the standard it is reading against, and a check the tool genuinely could not answer is reported as unanswered rather than counted as a failure, so an inconclusive lookup never costs a domain points it should have kept. It needs no account and no email address to see the result, and the result has a shareable link you can hand to whoever administers the DNS.
Fixed: A working DKIM setup reported as no DKIM at all — The domain health checker showed a red DKIM result reading “no record found” for domains whose signing was verified and working. Three separate faults stacked into that one wrong answer: the list of selector names it guessed included one that Amazon SES has never actually published, so SES users were told their setup had been checked when it could only ever miss; a miss against that guess list was graded as a failure, when DNS simply cannot be asked to list a domain's selectors and a provider that randomises them can never be guessed at all; and the key itself was only recognised in one of the two forms the standard permits, so even a correctly supplied selector read as missing. The checker now identifies the sending platform from the domain's own SPF record, says plainly when that platform's selectors cannot be guessed and where to read yours from its console, and accepts a selector or a signature header if you want a definite answer. A published-but-empty key is now correctly reported as a revoked one. Separately, the SPF and DMARC results were displaying every unrelated TXT record on the domain — site verification strings and the like — as part of the policy they had read; the grading was always right, only the text shown was wrong.
Improved: Every check now explains what it is and why it matters — The public tools stated what was true about a domain and what to do about it, but never what the thing being checked actually is — which is the question most people arrive with. Every check on both tools now carries a plain-language explanation, folded away by default and opened automatically for anything failing or unanswered, along with a command you can run to confirm the finding without taking our word for it. Those commands used to contain a sample domain that a reader had to notice and edit; they are now written against the domain actually being audited, and the two that needed a mail server name now look it up first so they are self-contained. The explanations expand automatically when you search the page and when you print it, since this is a report people tend to hand to someone else.
Fixed: Scores and badges that contradicted the words next to them — Three ways the public tools misreported their own results. The domain health score ring could render an impossible fraction — 100 out of 85 — because the two halves were being measured in different units after a change that correctly stopped an unanswerable check from being counted against a domain; it now reads points earned over points assessed. Five optional checks told readers they could never cost points while the grader was in fact deducting for them, so a BIMI mistake could take a clean domain from 100 to 93 under a sentence promising that was impossible; the copy now states the rule actually applied — publishing nothing costs nothing, publishing something and getting it wrong is graded like any other misconfiguration. And a check that found an optional standard simply not deployed showed a green pass tick above a sentence saying it was not configured; those now show a neutral “not set up” instead, with the category header counting them separately, and the score is deliberately unchanged so that never adopting an optional standard still costs nothing.
Fixed: The “email me this report” button now actually emails the report — Submitting an email address to have a report sent returned a confirmation and then did nothing at all — the address was stored and no code anywhere ever read it back. The audit report is now genuinely sent, as a link to your own live result rather than a snapshot, so it still shows the current answer after you fix something; the domain health tool got a shareable result link of its own so its capture form has something real to send too. The email itself was then rebuilt: a preview line that no longer just repeats the subject, a readable width and text size, colours that survive dark mode in Apple Mail and Outlook rather than leaving grey text on a near-black background, and one genuinely useful next step — the email authentication guide — instead of ending on a dead sentence. Sent to a real Gmail account and read as it arrived, three plain strings turned out to be getting linkified by Gmail into blue links to the marketing homepage, one of them sitting directly above the actual button; all three now carry their own destination. The confirmation also names the address it sent to, so a mistyped one is visible instead of silently rewarded with a green tick.
Improved: A sharper homepage, and a Sign in link that went to the wrong page — Sign in linked to the signup page. The masthead has been compressed so the headline and the primary button land in the first screenful on a phone, rather than roughly twelve hundred pixels down. Pricing guidance no longer badges one plan as recommended while steering undecided readers to a different one a line below, the founder profile link no longer competes with Start free at the same visual weight, and there is now a plain answer to what happens to your mail if the person running Folio is hit by a bus — you can export all of it as a standard mailbox file at any time. The deliverability proof section gained iconography so it reads as verified fact rather than assertion, and three product screenshots that still showed the pre-rebrand Emcognito name in production were recaptured — two of which had also been swapped with each other relative to their own captions.
Fixed: Mobile confirmations no longer sit on top of the buttons — On a phone, the confirmation that appears after an action like Empty spam or Empty trash was anchored to the bottom of the screen above everything else, covering the tab bar and, while selecting messages, the bulk action buttons — so there was no way to navigate away until it dismissed itself. Reported by a customer. It now appears at the top, below the header, on every screen that uses it; the desktop position is unchanged.
Fixed: Two blog rendering faults, both self-healing — A handful of posts were still showing literal Markdown in list items — stray **bold** markers rendering as text — because the converter added last release treated any tag left open across several lines as content to leave untouched, when it was only ever meant to protect blocks of DNS record examples. And the previous/next links at the foot of a post could point at a URL that immediately redirects elsewhere, because those links were picked from a set that deliberately keeps a consolidated post listed for its recrawl window; they now resolve to the post the reader actually ends up on. Both fixes apply as posts are re-rendered, so no post needed editing individually.
New: A Zendesk alternatives guide, and tidier blog URLs — A new evidence-led buyer's guide for people evaluating Zendesk alternatives, which states plainly where Folio is not the answer — it has no shared or team mailbox workflow — and cites its sources rather than asserting. Nineteen older blog posts consolidated in the previous release have now graduated out of the sitemap and blog index after their recrawl window, with their redirects kept in place, and several pages had their titles, descriptions and opening answers sharpened. A number of further suggested rewrites were deliberately skipped because the pages had been rewritten too recently to have been measured yet.
Reliability: A healthy deploy could be rolled back for being slow — Two faults in the backend deployment pipeline, found by a release that failed twice for reasons unrelated to what it contained. Waiting for a new version to become ready measured scheduling, image download and readiness against a single deadline, so a deploy that spent most of its budget waiting for the cluster to add a machine was rolled back moments after it had actually come up healthy. Scheduling now has its own separate allowance, leaving the readiness deadline to measure what it was meant to. And retrying any deploy that failed after its image had been uploaded was guaranteed to fail again on the upload step, because the version tag cannot be overwritten — the upload is now skipped when that exact version is already present, which is safe precisely because it cannot have been changed. Separately, an in-cluster networking quirk meant Folio's own servers could not fetch their own published transport policy, which made the new audit tool grade folioinbox.com's own setup as unreachable.</description>
    </item>
    <item>
      <title>No. 020 — The iOS app works again, account deletion finally does too — and a broad accessibility pass clears the product end to end.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-08-17</guid>
      <pubDate>Mon, 17 Aug 2026 12:00:00 GMT</pubDate>
      <description>The iOS app could show its login screen and nothing else, because its origin wasn't allowed through the API's CORS policy — that's fixed, and the app works end to end again. Account deletion is reliable now too, after a multi-round fix to the third-party verification integration guarding that page. A message that's already gone can no longer come back as a ghost row, billing and other server errors now reach the browser instead of vanishing, and a broad accessibility pass fixed unlabeled form controls, keyboard-only file attachment, and color contrast across the admin dashboard and several public pages. Also fixed: the Deliverability dashboard's DMARC recommendation, which could tell an already-protected domain to loosen its own policy — and, the bug a reader flagged directly, blog posts that were rendering raw Markdown instead of formatted text.

Fixed: The iOS app could load its login screen and do nothing else — Its in-app WebView runs at a different origin than the website, and that origin wasn't on the list the API accepts requests from — so every request after the login screen loaded, including the login itself, was silently blocked. The iOS app works end to end again.
Fixed: Deleting your account is reliable now — The delete-account page runs a third-party check that verifies a real visitor is submitting the form, and getting that integration working took several rounds. Two submit handlers were firing at once, so a deletion could go through unverified while the page still showed an error. The verification token the third-party service issues was longer than the API allowed, so a legitimate submission was flatly rejected. The verification call itself was misrouted and always failed silently, quietly falling back to weaker protection with no indication that had happened. And the spam classifier reading the submitted reason was scoring ordinary sentences — explaining you're consolidating email providers, for instance — as spam, refusing real customers on custom domains more than a third of the time. Deletion now goes through cleanly, and that classifier has been set to record rather than block until it can be retrained.
Fixed: Blog posts rendering raw Markdown instead of formatted text — Some posts were showing literal, unconverted Markdown — stray ###, **bold**, bare --- lines — instead of formatted text, because the sanitizer that cleans incoming post bodies only understands HTML tags and had no idea that syntax needed converting at all. A converter now runs both when a post is first published and whenever an existing post is re-rendered, so every affected post self-heals without anyone touching it individually.
Fixed: Billing and other server errors now reach the browser — A server error — most visibly, anything going wrong while choosing a billing plan — used to vanish before it reached the browser. The app and the API run on separate domains in production, and the response describing what went wrong was built in a way that never carried the header letting the browser actually read it, so it just looked like nothing happened. Server errors, a Stripe outage, and rate-limit responses now all reach the browser with an actual message instead of a silent failure.
Fixed: A deleted message could come back as a ghost — A quirk in how message actions were saved meant that archiving, restoring, or deleting a letter that had already been permanently removed elsewhere — in another open tab, say — could bring it back to life as an empty, sender-less row, still counted in your inbox. Those actions now correctly do nothing if the letter is already gone.
Fixed: A search with no results used to strand you — Searching the inbox for something that matched nothing made the search box itself disappear, along with the Clear button and every filter chip — leaving no way to recover except reloading the whole page. The search box, and a working way to clear the search, now both stay on screen when a search comes up empty.
Fixed: The Deliverability dashboard's DMARC advice, and a layout gap — The Ready to tighten suggestion always recommended moving a domain's DMARC policy toward quarantine, even for a domain that had already reached the strictest reject setting — so a domain in its most protected state could be told, incorrectly, to loosen its own policy. It now reads the domain's actual published policy and recommends the real next step, or nothing at all once there is no next step. Separately, a shorter card sitting next to a taller one no longer gets stretched to match it, which used to leave a blank gap under the shorter card's own content.
Fixed: A broad accessibility pass — Every form control now has a real accessible name rather than relying on placeholder text alone — that included the account-deletion field, of all things. A keyboard-only user can now attach a file in Compose, which previously required clicking an unlabeled drop zone with a mouse. The footer's nameplate link no longer has a screen-reader label that contradicts what it visibly says. And text contrast was corrected across the admin dashboard, the AWS WorkMail migration timeline, and every place the site's sage-green accent color is used as text — 44 places across 20 files were all failing the same contrast check off one shared color value.
Fixed: Adding an existing alias no longer overwrites it — Adding an email alias that already existed on a domain used to silently succeed and overwrite the existing row — quietly un-blocking an alias someone had deliberately blocked from Operations, or exposing a domain's internal DMARC-report collector as a regular, sendable identity in Compose. Creating an alias that already exists is now refused outright instead of clobbering it.
Fixed: Remote images in a letter, and what they can see — An image embedded in an incoming letter could silently fail to load if the sender's server set a strict cross-origin policy, with no explanation to the reader. Remote images are now fetched by Folio's own servers and re-served from our origin instead of being loaded directly by your browser — which also closes a real privacy gap: a tracking pixel in a marketing email can no longer see your IP address, device, location, or the exact time you opened it, because your browser never contacts the sender at all. Folio's privacy and trust pages now say this plainly, since it was true and undocumented.
Fixed: The AWS WorkMail importer, and its migration wizard — The tool that imports mail from AWS WorkMail wasn't verifying the TLS certificate on the connection it opens to fetch your mailbox — meaning anyone positioned to intercept that connection could have read your WorkMail password off the wire. That connection is now properly certificate-verified. Separately, the migration wizard's region picker offered five AWS regions that WorkMail has never actually run in; picking one meant entering your credentials and then waiting out a connection failure. The picker now only offers the three regions that are real.
Fixed: Deleted domains, and what evaluation accounts can do — Deleting a domain could leave behind a residual internal alias — the one that collects DMARC reports for that domain — which caused two problems downstream. Mail kept arriving at that address and landing in an account that no longer owned the domain, which is now cleaned up on delete. And an account whose only domain was ever deleted could get permanently locked out of activating Folio's free instant address, because the leftover alias looked like proof the account had already been set up; that's fixed too. Separately, a limit was added on how many distinct strangers a brand-new evaluation account can email in total — previously only total send volume was capped, letting one account import a scraped list and mail twenty unrelated strangers within a few minutes without tripping anything.
Fixed: The head-to-head comparison pages now state Folio's price — The pages comparing Folio against Migadu, Purelymail, Fastmail and Zoho Mail never actually said what Folio costs, and buried the section on where Folio doesn't fit under a note calling it not a sales pitch. Both now open with the price stated plainly, and say clearly which competitor is the better buy for a given use case.
Improved: A round of iPhone-specific fixes — The header no longer draws underneath the status bar or Dynamic Island — on the native app and, once a second gap in the fix was found, on the mobile website too. Compose no longer tells a touchscreen user to press keyboard shortcuts it can't use. And small-caps labels across the site — footer credits, comparison links, captions — are now large enough to read on a phone instead of sitting at 9-10px regardless of screen size.
Improved: The deliverability test-send tool asks where the letter landed — Folio's test-send tool checks your domain's authentication, then asks you to send yourself a test letter. If it landed in spam, the tool used to just point you back at the same authentication check, which had already passed and could never explain anything further. It now asks directly where the test letter landed and answers accordingly: proof of a working setup if it reached the inbox, a plain explanation that authentication isn't the issue if it landed in spam, or troubleshooting steps if it never arrived.
Fixed: A broken essay or doc link now shows a real 404 — Following a stale or mistyped link to an essay or a doc page loaded the correct not-found content for a moment, then silently swapped it for the section's full index once the page's JavaScript took over. An unknown slug now consistently shows a real not-found page instead.
Fixed: Cleaner blog URLs and page structure — A handful of older blog posts covering overlapping topics have been consolidated onto one canonical post each, with the old URLs redirecting rather than sitting around as near-duplicates. Separately, one post's body content was reusing heading IDs the page template also relies on for its own Related guides and Sources sections, which broke in-page anchor links and confused screen readers; that's now prevented for good.
New: A free deadline checker for AWS WorkMail migrations — A free tool now checks your domain's DNS and tells you, honestly, whether you're actually on AWS WorkMail and need to plan around its shutdown, or whether the similar-looking records belong to something else entirely. The migration guide was also rewritten to lead with AWS's own recommended alternatives — including ones that aren't Folio, for anyone who needs shared or corporate mailboxes we don't offer — before making the case for switching, with a dated timeline instead of a countdown.
New: Two more independent host comparisons — Migadu vs. Zoho Mail, and Purelymail vs. Fastmail — completing the full set of pairings across the four services Folio is most often compared against.</description>
    </item>
    <item>
      <title>No. 019 — Folio's own mail now publishes a transport policy — and the reports it generates have a home.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-08-10</guid>
      <pubDate>Mon, 10 Aug 2026 12:00:00 GMT</pubDate>
      <description>MTA-STS is live in testing mode on folioinbox.com and wm.emcognito.com, so a sending server can check which machines are allowed to accept our mail and report back what it found. Those transport reports now ingest into the Deliverability view alongside DMARC — after a week that began with the very first one landing in a spam folder. Also fixed: ten pages that shared without a preview image, a publishing guard that was rejecting valid posts, and a migration page with nothing to offer visitors who only wanted a disposable address.

Reliability: A published policy for how mail reaches Folio — Plain SMTP has no way to insist on a safe connection: a sender that is redirected to an impostor server, or offered no encryption at all, will usually deliver anyway. MTA-STS closes that off by publishing, over HTTPS where it cannot be forged in transit, exactly which servers may accept a domain's mail and that the connection must be encrypted. folioinbox.com and wm.emcognito.com now publish such a policy, together with the record that asks senders to report what they observe. It is deliberately in “testing” mode, which means senders check the policy and report failures but still deliver as they did before — so nothing about your mail changes yet, and a mistake on our side cannot bounce it. Those reports are what will tell us it is safe to move to enforcement. The policy is served by its own isolated, rate-limited service on its own certificates, deliberately separate from the app so neither can affect the other, and the DNS records that make it discoverable are only allowed to go live after both endpoints return the exact expected bytes over a trusted certificate.
New: Transport reporting, in the same view as DMARC — Publishing that policy means senders start mailing back aggregate reports about it: how many connections to Folio succeeded, how many failed, and for what reason. Those reports now have a full ingest pipeline of their own, mirroring the DMARC one — the same limits on size and nesting, one stored row per report, and atomic daily per-domain rollups — and they surface in the Deliverability view as a TLS section beneath each domain. Authentication and transport reporting are answered in one place rather than two. It carries its own switch, independent of DMARC ingest, so either can be turned off without the other.
Fixed: Deliverability reports were being filed as spam — On 9 August, Google's first transport-security report for one of Folio's own domains was classified as spam. Nothing was wrong with the report: nine successful sessions out of nine, in a plain, generic-looking first message from an address that had never written before — which is close to the shape of a cold bulk sender. Aggregate DMARC and transport reports are now recognised by the filename shape their standards define and set aside before the reputation ladder ever sees them. Two neighbouring errors went with it. Reports that Amazon sends as unnamed attachments were not being recognised as reports at all, so they were never ingested. And for a period the opposite was happening: transport reports were being pulled out of normal delivery and pushed into the DMARC pipeline, which is not where they belong. An unnamed compressed attachment is now decompressed and confirmed to contain a real DMARC report before anything is diverted.
Fixed: Ten pages shared without a preview image — The Terms, persona, and comparison pages each named a social preview card in their metadata that had never actually been generated — so sharing any of them anywhere, in Slack, iMessage, LinkedIn or a post, produced a bare link with no image. All ten cards now exist, and one that still carried the retired Emcognito nameplate has been redrawn with the Folio identity. The cause was a hand-maintained list of cards drifting away from the pages referencing it, which nothing checked; the build now fails outright if any page points at a preview image that is missing, malformed, or the wrong size.
Fixed: The publishing API stopped rejecting valid posts — Folio's automated publishing endpoints run a guard that refuses articles claiming capabilities the product does not have. It was matching bare phrases, so an article that mentioned team members or shared mailboxes in the very act of explaining that Folio is built for a single operator was rejected as though it had claimed the opposite. The guard now reads the qualifying sentence around a phrase instead of the phrase alone, and the backend's backstop scanner was aligned to the same published capability contract the public file declares, so the two can no longer disagree about what is allowed.
Improved: A straight answer for visitors who don't want a migration — Both migration guides describe the same thing: a permanent move of a mailbox and a domain onto Folio. Some visitors arrive wanting close to the opposite — one throwaway address for a single signup or thread. Rather than leave that mismatch to quietly bounce them, both pages now say plainly that this is not what Folio is for and link to Emcognito, the sibling product that does exactly that job.</description>
    </item>
    <item>
      <title>No. 018 — Domain setup gets continuous canary checks, and account deletion shuts out automated bots.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-08-03</guid>
      <pubDate>Mon, 03 Aug 2026 12:00:00 GMT</pubDate>
      <description>A background canary now audits every pending domain and clears stalled onboarding states automatically. Alongside it, account deletion is protected by proof-of-work challenges, automated publishing endpoints support external CMS workflows, and SEO improvements landed across marketing pages.

New: Domain onboarding canary and self-healing setup paths — Four edge cases in domain onboarding could previously leave setup stuck in a pending or failed state without a clear path forward—such as stalled AWS MAIL FROM provisioning or re-adding an active domain. A new background canary loop continuously audits every pending domain to recover stuck identities, while setup pages now provide explicit recovery actions for all sixty recognized onboarding states.
Improved: Account deletion hardened against bot abuse — To protect against automated request floods, account deletion now requires an HMAC-signed proof-of-work challenge before accepting an anonymous request. The form is further secured by the Siftfy content gate widget on the frontend and validated via siteverify on the backend.
New: Automated publishing contract for external content managers — Folio now implements standard Custom API publishing endpoints (POST, PUT, and DELETE for /blog/publish) backed by Bearer authentication. This allows direct publishing and updates from automated content systems such as VectraSEO while preserving claim guard and disclaimer rules.
Reliability: Suppression list guard for single-label domains — The automated SES suppression sweep now explicitly ignores single-label top-level identities (such as com or org) to ensure invalid inputs can never trigger bulk suppression deletions on root infrastructure.
Improved: Admin panel polish and search optimization updates — The admin metrics grid and wait-tone table received visual refinement, ensuring clear published status contrast. Code-actionable SEO recommendations were also applied across blog, comparison, and tool pages to improve search engine visibility and accessibility.</description>
    </item>
    <item>
      <title>No. 017 — A domain another project already claimed can now finish setup on its own.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-07-27</guid>
      <pubDate>Mon, 27 Jul 2026 12:00:00 GMT</pubDate>
      <description>The week's headline is a rule that replaces a queue: prove you control a domain's DNS and Folio will use a sending identity it didn't create. Alongside it, a setup page that stops calling things green when they aren't, prices that lead with the monthly rate, and unknown links that finally return a real 404.

New: Prove the zone is yours and sending unlocks itself — Some domains already have a sending identity registered elsewhere — set up by another project, or by an earlier tool, long before Folio saw them. Folio refuses to take over an identity it didn't create, which is right, but it left those domains permanently short of the records they needed and there was nothing the owner could do about it. Now there is: publish the four records already on your setup page and Folio checks them itself, including a DKIM key it generated at a selector only the zone's controller could answer for. When they resolve, the remaining records are issued automatically on the next pass. No ticket, no waiting on us, and no change to how the identity behaves for whoever else is using it — Folio will use it to send, and still never rename, retag, or delete it.
Fixed: Setup no longer reports green when it isn't — Three checks on the setup page could pass on records a receiving mail server would reject. SPF and DMARC were matched anywhere in the record rather than at its start, so a value that had accidentally kept its quote marks counted as valid; and a domain carrying two SPF or two DMARC records passed, when in fact a duplicate means no policy is applied at all. Because these checks are what unlock sending, a false green could authorise mail from a domain with no working authentication. All three now match the way a receiver does. Separately, a domain that can't finish outbound setup now shows all seven record positions with the reason, instead of announcing seven, rendering four, and quietly reloading itself every ten seconds forever.
Fixed: Pricing leads with the monthly rate — The pricing and home pages headlined the full annual total, so $348/yr sat next to competitors quoting $7 per user per month — which reads as expensive even though Folio is dramatically cheaper for anyone running several businesses. Both cadences now headline the monthly rate, with the billed total directly beneath at full ink, and the trial line moved up next to the price where the question about committing to a year actually lands. The comparison figures were re-checked against primary sources at the same time: Microsoft 365 Business Basic is $7, not $6, and Fastmail Business is $3, not $4 — we had been overstating a competitor's price in our own favour. The annual saving is 25%, which we had been understating as 20%.
Fixed: Unknown links return a real 404, and old links land where they meant to — Any address that didn't exist on folioinbox.com returned the home page with a success code, which told search engines and AI crawlers that every mistyped or stale URL was a real page. Misses now return a genuine 404 with a page that offers somewhere useful to go, while the app's own deep links keep working as before. Seventeen addresses that were linked from elsewhere but never shipped — a features and solutions structure this site never had, plus near-misses of real URLs — now redirect to the page that answers the same question, in a single hop.
Reliability: Domain setup stopped queueing behind a shared AWS limit — Folio's AWS account is shared with other projects, and two background jobs were asking Amazon about every sending identity in it one at a time, against a limit of roughly one request per second. Once the account passed a couple of dozen identities that reliably hit the ceiling — and a request that gets refused looks the same as a negative answer, so a bad pass could quietly stop tidying up bounce records or under-report problems on the admin view. Both now ask a single question against a different, far more generous service. Retries on the shared connection were also capped, so a throttling incident can't turn an interactive click during domain setup into a minute-long wait.
Reliability: Infrastructure changes are checked before they deploy — A permissions stack had been stuck in a failed state since late June, silently rejecting every update, and the daily check meant to catch that couldn't run its deeper assertions. The stack is unblocked, the check now runs in full on a schedule, and a class of change that quietly forces AWS to delete and recreate a live permissions policy has been identified and backed out. None of this is visible in the product; it is the difference between a deployment that is verified and one that is assumed.
Improved: Search copy, and a changelog that was showing its own scaffolding — Two rounds of search and answer-engine work across the marketing pages: clearer titles and descriptions on pages that were being seen but not clicked, better internal links into the pages nothing reached, and repairs to seventeen dead links inside published writing. Found while checking that work: this page and the shipping log on the home page had been serving the release-notes drafter's raw output — placeholder headings and unfinished sentences — for several weeks. Those releases are now written, and a test now refuses to let an unwritten draft reach the site again.</description>
    </item>
    <item>
      <title>No. 016 — Replies land where the sender asked — and setup warns you before mail moves.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-07-23</guid>
      <pubDate>Thu, 23 Jul 2026 12:00:00 GMT</pubDate>
      <description>Three changes at the edges of the product: replies now honour a sender's Reply-To, connecting a domain tells you first when mail is already flowing to it, and identity changes are fenced to domains Folio provisioned itself.

Fixed: Replies honour the sender's Reply-To — A sender's Reply-To header was read at delivery and then dropped, so every reply addressed the From line instead — wrong for mailing lists, ticketing systems, and no-reply senders that publish a real reply mailbox. Replies now address Reply-To when it is present and fall back to From when it is not, and reply-all keeps both addresses out of Cc so nobody is written to twice. This applies to mail imported from here on; letters already in your mailbox keep replying to From.
New: Setup that knows your registrar — and warns before mail moves — The DNS step of connecting a domain now detects your DNS host from its nameservers and shows the click-path for that specific control panel, across roughly forty hosts, with a picker to correct it when the guess is wrong. And before you connect a domain that already receives mail somewhere else, a “Before you switch” alert says so plainly — pointing the apex MX at Folio moves your inbound mail, and that should never be a surprise.
Reliability: Sending identities fenced to domains Folio provisioned — Every change to a domain's sending identity now passes through a single ownership checkpoint that fails closed: Folio will create, reconfigure, or remove an identity only for a domain it provisioned itself, and a set of reserved zones is refused outright. Infrastructure permissions were narrowed to match, and any identity deletion raises an alert. Nothing about how your domains behave changes — this closes a path where an identity could be acted on without a positive ownership signal.</description>
    </item>
    <item>
      <title>No. 015 — The Spam list holds still under your cursor.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-07-20</guid>
      <pubDate>Mon, 20 Jul 2026 12:00:00 GMT</pubDate>
      <description>A quiet week, and one fix that took two tries — the second time by instrumenting the real thing on production instead of guessing again.

Fixed: Spam review no longer jitters under the cursor — In the Spam folder, resting the cursor over a message could throw the page into a rapid scroll-and-reflow loop, with the review panel flickering between two letters. The cause was a feedback loop: the review aside changes height per message, that changes the page height, the browser's scroll anchoring re-pins the scroll position, a different row slides under a stationary cursor, and it selects itself — round and round. A first attempt disabled scroll anchoring on the workspace, which did nothing, because anchoring only applies to the element that actually scrolls. Anchoring is now disabled on the document itself while Spam is open and restored the moment you leave, with a movement check on selection as a second layer. Measured on production before and after: 170 scroll events in three seconds down to one, and a 52px scroll swing down to none.</description>
    </item>
    <item>
      <title>No. 014 — Leave AWS WorkMail without exporting a thing.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-07-13</guid>
      <pubDate>Mon, 13 Jul 2026 12:00:00 GMT</pubDate>
      <description>The headline is a real migration tool — connect a WorkMail mailbox and Folio pulls the mail across itself. Alongside it: a stricter read on known-bad sending hosts, an accessibility pass over the app, and a second server behind the API.

New: Import your AWS WorkMail mailbox over IMAP — Connect a WorkMail mailbox and Folio imports its history directly over IMAP — no export file to produce, download, or upload. The credential is used for that one session and never written to storage, to logs, or to the job record, and connections are IMAPS-only. An interrupted import costs nothing to resume: the per-message marker skips anything already brought across. The guided cutover, including the DNS switch, lives at the WorkMail migration guide.
Improved: Known-bad sending hosts now count against a message — Inbound mail is checked against public blocklists — Spamhaus and SpamCop — at delivery, and a listing feeds the spam score as a bounded signal rather than a hard rejection. This closes a gap where confidently-spammy mail was pulled back toward the inbox by otherwise-clean SPF, DKIM, and DMARC results. Passing authentication proves who sent a message, not that you want it.
Improved: Keyboard, contrast, and touch-target fixes throughout — A full pass over the app's accessibility. The closed mobile navigation drawer is out of the tab order entirely; opening it moves focus inside, Tab stays within it, Escape closes it, and focus returns where it started. Domain headings use contrast-safe text instead of arbitrary per-domain colours, the Deliverability page's definition lists are marked up correctly, Calendar heading order is repaired, and inbox filters, selection controls, and dismiss buttons are all up to comfortable touch sizes. The next action on a blocked Compose now sits above the explanation of why it is blocked, rather than below it.
Reliability: The API runs on more than one server — The backend ran as a single instance, so any machine failure or routine deploy meant a gap in service. It now runs two, spread across separate machines, with a disruption budget that drains them one at a time. Nothing about the application itself changed — durable state has always lived outside the process.</description>
    </item>
    <item>
      <title>No. 013 — A denser inbox, and fewer dead ends on the way in.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-07-06</guid>
      <pubDate>Mon, 06 Jul 2026 12:00:00 GMT</pubDate>
      <description>The desktop list is rebuilt for scanning — roughly two and a half times more letters on screen — and the paths that used to strand a new account now lead somewhere.

Improved: The desktop inbox is a dense, single-pane list — The desktop folder list spent about 165px per message and showed roughly four letters at a time. Rows are now about 60px — around ten on screen — with the sender's name over a date and via-domain line, a single-line subject, and a one-line preview. The per-domain colour stripe, serif subjects, flagged fleuron, and likely-spam seal all stay. The wide-viewport two-pane reading desk introduced in No. 012 is retired with this release: a row click opens the letter on its own page again, at every screen size. Mobile is unchanged.
Fixed: Trash sorts by date again — Discarded drafts pinned themselves to the top of Trash regardless of their date, because a draft's row key starts with a letter and every other row's starts with a digit. Trash is now sorted by received date, which puts old drafts back in their real place — including the ones already sitting in your Trash. On one real mailbox, four drafts dated 25 May to 14 June moved from the top four positions down to where they belonged.
Fixed: Onboarding paths that led nowhere — Three dead ends on the way in. An account with no domain was told to “write the first letter,” which it had no address to do — it now reads “Add a domain to begin” and goes there. A transient failure loading your identities blanked the whole message list; it no longer does. And hitting the preview's one-domain limit showed a notice and stopped, where it now takes you to billing with the upgrade in front of you.
Improved: Hitting a plan limit no longer throws away your work — Reaching the domain or send cap used to show a notice and redirect to billing, discarding whatever you had just typed. You now get an in-place dialog naming the specific limit you hit and what the next tier changes. If you do go on to billing, the domain you typed or the draft you were writing is waiting for you when you come back.
New: Your preview usage, visible — Accounts on the no-card preview had no way to see where they stood. The app now carries a quiet meter — sends used of 100, domains used of 1 — and the billing page shows preview accounts the same plan ladder that subscribers already had.
New: Try the multi-domain inbox before you sign up — The home page's demo link used to scroll toward a video that was never recorded. It is now a working demo: mail from three fictional businesses arrives in one inbox, and hitting reply shows the From address selecting that brand on its own. Also added: an honest note that the web app runs in mobile Safari today, and a waitlist for the iOS launch.
Improved: Pricing shows monthly and annual side by side — The pricing page gained the monthly/annual toggle the home page already had, so the two surfaces stop disagreeing with each other, plus a five-question FAQ. Two long-standing bugs went with it: two tiers could both claim to be the recommended plan, and on narrow phones the cookie banner covered the first plan card.
Improved: Setup emails that name the actual problem, once — The nudge that helps you finish connecting a domain now names the specific blocker — inbound MX, SPF, DKIM, DMARC, MAIL FROM, or a missing alias — and carries the exact record to publish plus a link to the right screen. It sends once per problem and then stops: no recurring reminder, and an account that never acts is marked and left alone for good. Renewal notices now also respect the suppression list and carry a working unsubscribe.</description>
    </item>
    <item>
      <title>No. 012 — A new front page, a new inbox, and formatting you can find.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-06-29</guid>
      <pubDate>Mon, 29 Jun 2026 12:00:00 GMT</pubDate>
      <description>The site and the app were redrawn as a broadsheet — a real nameplate, ruled sections, an editorial icon set — and Compose finally surfaces the formatting controls it always had.

Improved: The site and the app redrawn as a broadsheet — The design system was consolidated into a single token layer and applied across the product. The home page became a front-page nameplate with a dateline and ruled sections; every marketing page picked up the running head; the app followed. On wide screens the mailbox became a two-pane reading desk where a letter opens beside the list instead of navigating away, with the reply and file actions pinned so they stay reachable partway down a long letter. The two-pane desk was retired the following week — see No. 013.
New: Rich-text formatting in Compose, where you can see it — Compose could already render bold, italic, links, lists, and quotes — the controls were just hidden behind selecting text first, which nobody thinks to do. The toolbar now appears the whole time you are writing: docked above the field on desktop, riding the top of the keyboard on mobile. Bulleted lists, numbered lists, block quotes, and clear-formatting joined bold, italic, and link. It is fully keyboard-operable with arrow-key navigation, and Escape returns you to the letter exactly where you left off. Markdown is still what gets stored, so nothing about how your mail is sent changed.
Improved: A mobile app built for thumbs — The launcher icon was a pale mark on a pale ground and effectively invisible on a home screen; it is now a high-contrast masthead “F.” Inside, a bottom tab bar — Inbox, Agenda, Compose, More — replaces the hamburger, and hides itself while you are writing or reading so a rising keyboard never lifts it. Search moved into the masthead. Crude unicode glyphs gave way to one hairline icon set. Alongside: safe-area padding under the notch, domain filters on a single scrolling strip instead of a ragged wrap, and a domain health score that reads as a score rather than an error code.
Fixed: Signatures render the way the brand-kit preview shows them — A signature saved with its own leading delimiter came out of the composer with that delimiter doubled, and its line breaks collapsed into one run-on line in Gmail. The composer no longer adds a delimiter to a signature that already carries one, and single newlines inside a signature are preserved.
Improved: One notice per domain when mail hits an address you don't have — A dictionary attack against a hosted domain used to spawn one banner per invented address, each needing its own dismissal, and they could overlap the spam-review banner. Notices now share a single ordered stack, group into one card per domain with a hit count and an expandable address list — so a real address is still rescuable — and offer one tap to dismiss a whole domain, both the backlog and anything that arrives later.
Fixed: Domain health reads SES Easy DKIM correctly — Domains whose DKIM is published as SES Easy DKIM CNAME records were reported as failing, because the health check only probed for the common selector names. It now detects those records and scores them correctly.
Fixed: Attachment links refresh instead of expiring — Links to attachments are signed and short-lived, so a message left open long enough would hand you a dead one — including when clicking through an image thumbnail. They are now treated as expiring cache entries and refreshed before use.
Improved: Storage and attachment limits stated plainly — The 15 MiB attachment limit and the per-plan storage allowances now appear on the pricing page, in the FAQ, in the manual, and in the app's billing view, instead of being something you found out by hitting one.</description>
    </item>
    <item>
      <title>No. 011 — Tougher on spoofed senders — and we show our work.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-06-22</guid>
      <pubDate>Mon, 22 Jun 2026 12:00:00 GMT</pubDate>
      <description>Mail that fails authentication outright no longer gets the benefit of the doubt: it's filed as spam on arrival. And when a message is flagged, the letter now explains why — in plain English, right next to the checks that made the call.

New: Spoofed senders don't reach your inbox — Incoming mail that can't prove who sent it — no passing SPF and no passing DKIM, or a From-domain whose own DMARC policy says to reject failures — is now filed straight to Spam on arrival, before it's ever scored on content. This holds even when the spoofed domain publishes no policy at all, so a forged sender can't dodge the check simply by staying silent. Authentication that's merely missing or temporarily unreachable still fails open, so a misconfigured-but-honest sender isn't punished.
New: Why a message was flagged, in plain English — Open Show message information on any letter and you'll see the authentication results — SPF, DKIM, DMARC — written out plainly, plus a new Sender history line describing how the sending domain's mail has been received across the network lately. History is framed as history, never as proof of identity: a domain with a strong track record still has to pass the authentication checks sitting right beside it, because reputation keys on a domain that can be spoofed and authentication is what actually verifies the sender. How Folio handles spoofed senders.
Improved: More borderline spam actually lands in Spam — The threshold for automatically filing a message to the Spam folder dropped from 98% to 90% likelihood, so mail that's very probably spam stops slipping into the inbox just under the old line. Anything below that still rides in the inbox with its reasoning one click away.</description>
    </item>
    <item>
      <title>No. 010 — See who's forging your domains — and who's passing.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-06-16</guid>
      <pubDate>Tue, 16 Jun 2026 12:00:00 GMT</pubDate>
      <description>DMARC aggregate reports used to arrive as opaque daily ZIPs in your inbox. Now Folio reads them for you and charts the result on a new Deliverability page — per-domain pass rates, daily trends, and the IPs sending as you and failing.

New: Deliverability dashboard — A new Deliverability page reads the daily DMARC aggregate reports mailbox providers file for your domains and rolls them up per domain: authentication pass rate, a daily pass/fail series, the source IPs sending as you and failing, and which providers reported. The raw reports are diverted out of your inbox and parsed server-side — no more opaque ZIPs. Reports land about once a day per provider, so a freshly bound domain takes roughly a day to show its first data.
New: Per-domain reporting, wired automatically — Every domain you bind now publishes its DMARC reports to a receive-only dmarc-rua@&lt;your-domain&gt; address that Folio creates and manages for you — hidden from your alias list and never a sendable identity. Nothing to set up. To bring in a domain you added earlier, add rua=mailto:dmarc-rua@&lt;your-domain&gt; to its existing _dmarc record; that one line is the only change.
New: Ready-to-tighten nudge — Once a domain shows a clean pass rate across a full window, the page surfaces a prompt to move its policy from p=none toward p=quarantine and then p=reject — so spoofed mail is actually held or rejected instead of merely logged. A new Manual article, “Reading your DMARC reports,” walks through the page and the policy ladder.
Fixed: DMARC reports route to an address that exists — Generated _dmarc records previously listed a second rua destination on shared infrastructure that had no live mailbox behind it. Records now carry a single rua pointing at your own per-domain dmarc-rua@ address, so no report is sent to a dead destination. Existing domains pick up the corrected record the next time you view their DNS.</description>
    </item>
    <item>
      <title>No. 009 — Prove deliverability before you switch — and a roomier free preview.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-06-05</guid>
      <pubDate>Fri, 05 Jun 2026 12:00:00 GMT</pubDate>
      <description>Three changes aimed at the moment before you commit: test that mail lands before repointing MX, get setup steps for your actual DNS host, and a free preview big enough to actually trust the result.

New: Send a test before you move MX — From a domain's setup page you can now send a real, DKIM-signed test letter to an inbox you control — before repointing MX. Sending never touches your incoming mail, so you can confirm a letter lands in the inbox (not spam) with zero risk to your current setup. Test sends use a separate allowance and never count against your preview sends.
New: Guided, registrar-aware DNS setup — Folio now detects where your domain's DNS is hosted — Cloudflare, GoDaddy, Namecheap, Squarespace, Route 53, and more — and shows the exact click-path to the record editor instead of a generic table. Unrecognized host? You'll still get your nameservers and clear next steps.
New: Export all mail as .mbox — Security → Export all mail downloads your inbox, archive, sent, and spam as a standard .mbox file that Thunderbird, Apple Mail, mutt, and Google Takeout all read. Paired with Google Takeout import, your mail moves in and out freely — nothing held hostage.
Improved: Free preview raised to 100 sends — The no-card preview now includes 100 sends (up from 25), so you can live with the product long enough to trust its deliverability before adding a card. Still one domain in preview; the rest of every plan is unchanged.</description>
    </item>
    <item>
      <title>No. 008 — Emcognito WebMail is now Folio — at folioinbox.com.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-06-04</guid>
      <pubDate>Thu, 04 Jun 2026 12:00:00 GMT</pubDate>
      <description>Same inbox, same team, same product. We've moved off the shared Emcognito address onto a home of our own. Your email, domains, and DNS are untouched; old links redirect automatically.

New: A name and a home of our own — The product now lives at folioinbox.com. Bookmarks and links to the old wm.emcognito.com address forward to the new one automatically — nothing to update. Your email address, custom domains, and MX/DNS records are unchanged.
Improved: Passkeys: one quick re-enrollment — A passkey is tied to a site's address, and ours changed — so a passkey set up on the old domain can't sign you in here. Sign in with your email link as usual and you'll be prompted to add a fresh passkey; the Security page flags any old one that needs replacing. Magic-link sign-in always works as a fallback.</description>
    </item>
    <item>
      <title>No. 007 — AgentDraft now reads like a first-party calendar connection.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-31</guid>
      <pubDate>Sun, 31 May 2026 12:00:00 GMT</pubDate>
      <description>The Calendar setup panel now presents AgentDraft as a same-studio integration, with explicit token scope, connection status, rotation, and disconnect controls.

Improved: First-party AgentDraft bridge — The old numbered setup step became a full integration panel with the AgentDraft mark, same-studio badge, agentdraft.io link, clear connection state, and a scoped-token row that tells you exactly where to paste the Webmail / Folio token.</description>
    </item>
    <item>
      <title>No. 006 — Calendar invites read like the actual invite, not a stub.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-18</guid>
      <pubDate>Mon, 18 May 2026 12:00:00 GMT</pubDate>
      <description>The agenda card now carries the full briefing — description, named guests with RSVP status, recurrence sentence, and a Join chip that picks the right video provider even when the LOCATION field stacks several URLs.

Improved: Briefing pull-block — The agenda card now surfaces the invite description as an editorial pull-block under the meta line — collapsed to a single-line excerpt by default, expanded in place when you click Read all. No more bouncing to Google Calendar to figure out what the meeting is.
Improved: Named guests — Attendees moved from anonymous coloured dots to named chips with partstat-toned pips. First four guests render inline; the rest collapse to a +N more chip with the overflow names available on hover.
Fixed: Join chip provider label — Invites whose LOCATION jammed two URLs together with a semicolon (a GitHub thread and the Meet link, for example) were labelling the chip with the wrong hostname. The parser now splits stacked URLs before extraction so the chip always names the recognised provider — Google Meet, Zoom, Teams, Webex, Whereby, and the rest of the known set.</description>
    </item>
    <item>
      <title>No. 005 — Invites land in the inbox with a real agenda behind them.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-16</guid>
      <pubDate>Sat, 16 May 2026 12:00:00 GMT</pubDate>
      <description>Calendar invites are now first-class objects in the reading view: RSVP without leaving the letter, see conflicts before you accept, and let any calendar app subscribe to the result.

New: Inbox-side agenda — A new Agenda view groups every invite that has arrived in the inbox into Today / Tomorrow / weekday rails, with per-identity filtering so a portfolio operator can see one brand's week at a time.
New: RSVP, with conflict warning — Inbound invites get accept, decline, and propose-new-time controls inline. Accepting an event that overlaps another accepted event surfaces the conflict in a confirm step before the reply goes out.
New: Recurring events from RRULE — Recurring invites expand by RFC 5545 RRULE, so a weekly standup shows up on every occurrence rather than only the series start.
New: Subscribe-out iCal feed — Each account can mint a private iCal feed URL that exposes its accepted agenda to Apple Calendar, Google Calendar, or any CalDAV-aware reader — read-only and revocable.
Improved: Time zones and clipping — Invite times now honour the original TZID on the inbound message instead of being silently rewritten to the server zone, and declined or canceled events drop off the agenda automatically.
Improved: Public Domain Health tool — The free /tools/domain-health checker now detects DKIM at common provider selectors (Google, Microsoft 365, Mailchimp, SendGrid, Amazon SES, others) instead of penalising a domain whose selector lives outside the usual default.</description>
    </item>
    <item>
      <title>No. 004 — Android availability is now part of the public product story.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-12</guid>
      <pubDate>Tue, 12 May 2026 12:00:00 GMT</pubDate>
      <description>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 Folio 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.</description>
    </item>
    <item>
      <title>No. 003 — Clearer setup, safer billing, better sending identity control.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-11</guid>
      <pubDate>Mon, 11 May 2026 12:00:00 GMT</pubDate>
      <description>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.</description>
    </item>
    <item>
      <title>No. 002 — No-card preview and a cleaner Workspace migration path.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-10</guid>
      <pubDate>Sun, 10 May 2026 12:00:00 GMT</pubDate>
      <description>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.</description>
    </item>
    <item>
      <title>No. 001 — Public pages received a conversion and clarity pass.</title>
      <link>https://folioinbox.com/changelog</link>
      <guid isPermaLink="false">folio-changelog-2026-05-09</guid>
      <pubDate>Sat, 09 May 2026 12:00:00 GMT</pubDate>
      <description>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.</description>
    </item>
  </channel>
</rss>
