v0.3.0-beta19

Pre-release for v0.3.0. Not for production use.

Fixed

• Switching sign-in provider no longer gives people a second account. Before, each provider created its own account, so switching from Microsoft to an OpenID Connect provider (and back) left two accounts with the same email on the Team page.
  • Now someone's first sign-in through the new provider takes over their account from the previous provider: role, name and history carry over.
  • Only an account of a provider the organization no longer uses can be taken over (never an active one, never a local or break-glass account), only when the email address is on one of the organization's verified domains, and only when exactly one such account has that address. A disabled account stays disabled.

New

• Remove accounts nobody can sign in with any more (Team page for org admins; Admin → Organizations for the platform admin).
  • Removable: accounts of a provider the organization no longer uses, and disabled local accounts.
  • Not removable: your own account, the break-glass account, and accounts of the current provider (disable those instead: removing would let them back in as a new account).
  • The sign-in history stays; the removal itself shows up in Sign-in activity as "Account removed".
• The Team page shows each account's provider (Microsoft, Google Workspace, OpenID Connect), and marks accounts of a provider the organization no longer uses as "previous provider".

No database changes since beta18.

v0.3.0-beta18

Pre-release for v0.3.0. Not for production use.

New

• SPF record builder (Domain → DNS Checks → "Build SPF record"), next to the DMARC, MTA-STS and TLS-RPT builders.
  • Starts from the published record: known mail services are ticked, everything else is kept as written.
  • Tick mail services from a list of common providers (each with its documented include value), add your own includes or IP addresses and ranges, a and mx, and pick ~all or -all.
  • Counts the DNS lookups as you edit, exactly like the SPF check, and warns above the limit of 10, about includes that don't exist, and about records longer than 255 characters.
  • Suggests senders you approved in Senders that the record doesn't cover yet, when their mail uses your domain as its return address (only then does SPF on your domain apply to it).
  • Warns when a domain has more than one SPF record, and reminds you to replace the record rather than add a second one.
  • The Fixes item "SPF near lookup limit" opens the builder directly.
• The SPF check shows the published record, and when expanded, every part of it in plain words with the DNS lookups each part costs.

Improved

• Ask AI questions describe SPF fully.
  • The mail setup line lists every include, named where the service is known. Before, includes the app didn't recognize were silently left out ("SPF allows Microsoft 365" for a record that also includes another service).
  • The SPF record is now part of the DMARC pass-rate question too, not only the SPF and sender questions.
  • A failed DNS lookup is reported as "couldn't be looked up just now" instead of "none published".
  • When the app is only waiting for more reports before recommending a stricter policy, the question says so, so the answer is about waiting rather than changing records that are fine.

No database changes since beta17.

v0.3.0-beta17

Pre-release for v0.3.0. Not for production use.

Security

• IMAP mailboxes now check certificates against the same list as all of YADT's HTTPS connections (certifi), instead of the container's system list.
  • Why: after eMudhra's intermediate keys were stolen (October 2026), certifi dropped the emSign roots, but the system list still trusted them. A forged certificate chained to those keys would have been accepted for an IMAP server.
  • YADT now has one list, which follows Mozilla's trust decisions and is refreshed with every build.
  • An IMAP server whose certificate chains to an emSign root no longer connects, just as browsers now refuse it.
• certifi is pinned explicitly, at 2026.10.19.
• Node.js: this build's frontend is compiled with the fixed Node.js 24.22.1. YADT runs no Node.js itself.

No database changes since beta16.

v0.3.0-beta16

Pre-release for v0.3.0. Not for production use.

Fixed

• Sign-in with your own OIDC provider: spaces or a line break around a pasted client ID or client secret are now ignored. Before, a copied secret often carried one along, and the provider refused it as wrong.
• Clearer errors from the provider: when it refuses, the message now includes its own reason, for example invalid_client: Client authentication failed instead of only "HTTP 400".

No database changes since beta15.

v0.3.0-beta9

Pre-release for v0.3.0. Not for production use.

Fixed

• IMAP: the app now subscribes to the folder that processed reports are moved to, right after creating it. Some mail apps and webmail only list subscribed folders, so the folder could exist without showing up there.

No database changes since beta8.

v0.3.0-beta8

Pre-release for v0.3.0. Not for production use.

Fixed

• IMAP sender check: some mail providers write a separate Authentication-Results header for each check, each with its own ID under one domain (for example bimi.provider.example, dmarc.provider.example). Only the top header was read. That one often holds no DMARC result, so every report counted as coming from an unverified sender. The app now reads the whole block of headers at the top from your mail server and uses its DMARC result. Headers further down, which a sender could have added themselves, still don't count.

No database changes since beta7.

v0.3.0-beta7

Pre-release for v0.3.0. Not for production use.

Fixed

• Settings → Mailbox: an IMAP mailbox now shows its report address as the connected mailbox, not the sign-in username. When the two differ, the username is shown next to it.
• Settings → Mailbox: confirming the mail server's ID with Use this no longer resets the report address to the username.

No database changes since beta6.

v0.3.0-beta6

Pre-release for v0.3.0. Not for production use.

Fixed

• Setup wizard: organizations without Microsoft sign-in that connected their own IMAP mailbox were still told a hosted reporting address would be created for their domain. The wizard no longer says this, and doesn't create one, once your own mailbox is connected. A hosted address is still available from the Policy Builder if you want reports in both places.

No database changes since beta5.

v0.3.0-beta5

Pre-release for v0.3.0. Not for production use.

Changed

• IMAP mailbox: separate report address. Some providers sign in with a different name than the address reports are sent to. The IMAP form now has an optional Report address field: the address in your DMARC rua= record. The DMARC and TLS-RPT checks compare your records against this address. Leave it empty when the username is that address.

No database changes since beta4.

v0.3.0-beta15

Pre-release for v0.3.0. Not for production use.

New: Google Workspace report mailboxes

• An organization's report mailbox can be a Google Workspace mailbox, read through one service account for the whole server.
  • Its Workspace admin grants that service account access once (domain-wide delegation, scope gmail.modify); Settings → Mailbox shows the client ID and scope to enter.
  • Then: Google Workspace mailbox → Test connection → Save & start syncing.
  • The mailbox must be on one of the organization's verified domains, so no organization can point it at another's mailbox.
  • Reports are marked read, removed from the inbox and labelled "DMARC processed".
• The hosted reporting mailbox can be read from Google Workspace too: HOSTED_REPORTS_SOURCE=google.
• Server setup: GOOGLE_MAIL_SERVICE_ACCOUNT_FILE (the service account's JSON key, mounted read-only) or GOOGLE_MAIL_SERVICE_ACCOUNT_JSON (its contents), for the api and the worker. The admin console's setup checks say when the key can't be read.

Changed

• Settings → Mailbox offers every kind this server supports: Microsoft 365, IMAP and Google Workspace. "Use another kind of mailbox" switches between them.

Deployment

• Azure template:
  • a Google Workspace mailboxes step (the key is stored in Key Vault);
  • the hosted mailbox step now has a source (Microsoft 365, IMAP or Google Workspace) and the IMAP settings (the password is stored in Key Vault).
  • All optional; existing deployments are unchanged.
• Portainer and .env.example: the new settings are listed.
• Migration 0045 runs automatically: mailboxes can be of kind google.

Docs

• New wiki page: Connecting a Google Workspace Mailbox.