A tidier interface​

• Buttons beside inputs now match them. The Clear cached sign-in and Generate new secret buttons, and the Add group, Add tag, Add domain and Add role buttons, are the same height as the field next to them and line up with it. Those Add forms, and the Grant access form, now use the same outlined inputs as the rest of the app.
• Icons are centred on their text. Capital letters sit above the middle of a line, so icons on buttons looked about a pixel low. They are now centred on the lettering.
• Real actions look like buttons. Clear cached sign-in, Ticket rules, the DNS push buttons, Configure selectors and the MTA-STS Save were plain text links. They are outlined buttons now.
• Dashboard summary. The numbers are larger and centred above their captions.
• Why rejects and quarantines happened is a bulleted list, with the count first and reasons that have no messages dimmed, on both the Dashboard and each domain's page.
• The filter button applies to the whole table. It sat inside the DNS Status heading, so it looked like it only filtered that column group. It is now a labelled Filters button above the Dashboard and Manage domains tables.

Fixes​

• Manage domains no longer logs a warning every time it loads. The page loaded each domain's groups and tags in one large query, which Entity Framework warns about. They are loaded separately now, and the warning under Manage > Server logs stops.
• Ticket rules are sturdier. The badge count on Manage groups no longer risks ending your session if the database hiccups as the dialog closes, the Which alerts create tickets panel follows the ticket sync setting you have saved rather than the switch you have just flipped, and each switch is announced by screen readers with its alert type.
• A missing alert type entry can't stop monitoring. If a future alert type were added without being listed for ticket rules, it is now logged as an error and the alert is still raised, instead of halting the whole monitor cycle.

Releases and Updates​

The blog is now called Releases and Updates, at /releases-updates. Every old /blog link, including the RSS and Atom feeds, redirects to its new address, so existing links and subscriptions keep working.

Docs and website​

• Update or redeploy dotMARC. The Docker and Azure guides now cover checking which image is running, updating to a release tag, forcing a new revision when you use :latest, checking the app is ready, and rolling back.
• The website follows the latest release. The homepage shows the latest release, and the example image tag in the docs updates itself, so neither needs editing when a release ships.

Upgrading​

There are no database migrations and no new settings. Redeploy and you're done.

Everything else​

As always, see the full changelog for everything that shipped between these two tags.

HaloPSA now works, and you can prove it​

The HaloPSA integration could not actually sign in: dotMARC asked Halo for a scope that doesn't exist, so every attempt was rejected. Once past that, the priority list failed to load too, because Halo returns one row per priority per SLA rather than a plain list. Both are fixed, and errors now quote what Halo actually answered instead of a vague "couldn't reach".

More usefully, Alert settings now has a Test the integration button. It creates a clearly marked test ticket from your most recent alert's details, closes it using your closed status, then waits for Halo to call the webhook back, showing each step as it goes. When something is wrong, the message says what to check: a status that doesn't match your closed status, a body dotMARC couldn't read, or a webhook URL with the wrong secret. A list of recent webhook calls shows what Halo has really sent, and the webhook URL now copies with a click. The webhook reads the ticket and its status from whichever payload Halo is set to send, and asks Halo for the status when the payload only names the ticket. When it can't find the ticket at all, the list shows the field names Halo sent, never their values. See PSA integration for the walkthrough.

Halo can also be configured (and commonly is) to refuse to close a ticket that nobody is assigned to, so there is a new Assign new tickets to setting. Pick an agent, or leave it on Don't assign if your Halo assigns tickets itself (round robin, a rule or the ticket type's default).

What dotMARC can do in Halo is decided by the agent the API application signs in as, and Halo has no scopes for that, so the PSA docs now list a tested set of role permissions for it and what each missing one looks like. Halo may bake a role's permissions into the sign-in token dotMARC keeps for about an hour, so there is a Clear cached sign-in button, and saving the PSA settings clears it too. The PSA settings are also tidier: grouped into Connection, Ticket defaults and Webhook, and your chosen ticket type, priority, closed status and agent now show by name instead of a number.

If you set up Halo on an earlier version, it most likely never worked. After upgrading, load the options again, pick your priority, closed status and, if you want one, an agent, save, and run the test.

Choose which alerts create tickets​

Every alert used to open a HaloPSA ticket. Now Alert settings has a Which alerts create tickets panel with a switch for each alert type, and a group can override it for its own client: on Manage groups, a group with a Halo client has a Ticket rules button where each alert type can follow the default, always create tickets, or never create them. A group with overrides shows a badge such as "2 overrides".

A rule only decides whether a ticket is created. The alert is still recorded, any Teams or webhook notification still goes out, and an existing ticket still closes when its alert resolves. If a domain belongs to several groups, the rules of the group its ticket goes to apply, and a domain with its own Halo client uses the global settings. Nothing changes until you edit a rule: every alert type creates tickets by default. See Choose which alerts create tickets.

Reports that were being dropped are now read​

Some receivers write values like Fail (capitalised) or no policy where the DMARC schema expects lowercase, and dotMARC's report library rejected those reports outright. They were left unread in the mailbox and retried on every poll, which meant missing data and around 158,000 warnings since the first release. They are now read, while genuinely unknown values are still rejected.

Expect a backlog of previously stuck reports to appear on the first poll after upgrading, which can move your dashboard numbers and resolve missed-report alerts. One known limitation remains: a report that uses the sampled_out override reason still can't be read, because of a bug in the report library.

Why was this rejected, when the receiver won't say?​

Many receivers send a rejected or quarantined source with no reason at all. dotMARC now works out a plain-English explanation from the SPF and DKIM results in the report, such as no DKIM signature, or SPF passing for a different domain than the From: address, and marks it Inferred so it is never mistaken for a reason the receiver reported. The reason-breakdown charts split these into SPF-only, DKIM-only and both.

The Sources tab also shows when each source was first seen (with a New badge for recent ones) and a 7-day volume sparkline, names well-known email services such as SendGrid and Mailgun in its recommendations, and the suspicious reject activity alert now breaks down which mechanism failed.

See what the server is doing​

Diagnosing a failed integration used to need access to the host's logs. Manage > Server logs now shows the most recent warnings, errors and dotMARC's own messages, newest first, with level and text filters, auto-refresh and a copy button. Secrets in URLs and tokens are redacted, and access is its own LogsView permission, part of the Admin role. Entries live in memory and reset when the app restarts, and nothing is captured on demo instances. See Server logs.

Smaller things​

• More DNS providers recognised. Microsoft 365, Amazon Route 53, GoDaddy, Namecheap, DigitalOcean, OVH, Gandi, NS1, DNS Made Easy and Vercel are detected, and the DNS provider row shows a domain's actual nameservers on hover. One-click DNS push still works for Cloudflare, Azure DNS and Google Cloud DNS.
• Faster Dashboard and domain pages. They no longer load every report's full raw XML, which nothing on those pages uses, and related data is loaded separately instead of being multiplied into one large result. What you see is unchanged.

Upgrading​

Five database migrations run automatically at startup. One adds a nameservers column to domains, one adds the Halo agent setting, one saves the names of your chosen Halo ticket type, priority, status and agent beside their ids, one adds the table for ticket rules (empty, so every alert type keeps creating tickets), and the other changes no schema, so nothing moves and it is safe to roll back. The built-in Admin role gains LogsView on its own; a custom role needs it granting from Manage Access. The new settings are Assign new tickets to, which defaults to leaving assignment to Halo, and the ticket rules, which default to creating tickets for everything.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Sort by any column​

Every column on both tables, Domain, Report Status, Pass rate, Last report, Monitored, DMARC, MTA-STS on the Dashboard, and Domain, Groups, Tags, Halo Client override, Monitored, Reports, Last report on Manage Domains, is now sortable by clicking its header. The combined DMARC column sorts by the same label it displays (own record and authorization status together), so it groups domains the way you'd expect rather than by a raw internal status code.

Per-column filters, tucked out of the way until you need them​

A small funnel icon in the header toggles a filter row for every column: text search for Domain and Last report, dropdowns for Report Status, Monitored, DMARC, and MTA-STS populated from whatever values are actually present, and a minimum threshold for Pass rate and Reports. The row is hidden by default so it doesn't clutter either table for the common case of just a few domains, and the funnel icon highlights when filters are active even while the row's collapsed.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Google Cloud DNS joins Cloudflare and Azure DNS​

DNS push now supports Google Cloud DNS alongside the existing Cloudflare and Azure DNS providers - same delegation model as the other two (the signed-in user's own permissions govern the push, not a standing credential dotMARC holds), with one difference worth calling out: dotMARC discovers the right Cloud DNS zone automatically across every GCP project you can see, rather than asking you to configure a project ID up front. See DNS Provider Push for how to register it - each provider now has its own linkable setup section instead of being buried in a single wall of text.

Why did this actually get rejected?​

DMARC aggregate reports carry more than a raw pass/fail: they carry why a receiver overrode its own policy - a forwarder tripping alignment, a mailing list rewriting headers, sampling, local policy, or genuinely nothing. dotMARC used to discard that detail entirely. Now it's captured for every report (and backfilled for reports you already have), and shown two new ways:

• Each domain's Overview tab, and the main Dashboard, both show a breakdown of why rejected or quarantined mail happened, not just how much of it there was - a domain that's 100% benign forwarders reads very differently from one where nothing explains the rejects at all.
• The Sources tab shows the same detail per source IP - the actual SPF/DKIM domain and result behind each pass/fail on hover, plus who owns the IP.

A new Suspicious reject activity alert uses this directly: it fires when a domain's reject volume looks like more than benign forwarding, not just when reject volume is high. IP ownership lookups are also proactive now - previously they only ran when someone opened a domain's Sources tab; now they run on a schedule regardless, so the data's already there when you go looking for it.

A Docker deployment that's actually a deployment​

Self-hosting docs used to say "put a reverse proxy in front of it" and leave the rest to you. docker-compose.selfhosted.yml is now a complete, ready-to-run stack - dotMARC, PostgreSQL, and Caddy for automatic HTTPS, wired together with nothing left to hand-edit beyond setting your hostname in .env. Deploy with Docker is also now its own page, weighted the same as Deploy to Azure rather than buried inside Getting Started - both are genuinely first-class paths, not a primary one and an afterthought. The setup-heavy pages (Entra app registrations, both deployment paths, each DNS provider) also got interactive checklists now, so you can tick off progress as you go instead of losing your place halfway through.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Alerts that open and close their own PSA tickets​

If you run HaloPSA, dotMARC can now turn an alert straight into a ticket, and close it again the moment the underlying problem clears, no manual bookkeeping either way. Map clients to Halo companies from Manage Groups or Manage Domains (a per-domain override is there if one domain needs to go somewhere different from its group's default), pick a priority, and configure the rest from the new PSA integration section in Alert settings. A domain that already has an open ticket for the same problem won't get a second one.

DNS pushes that can actually fix what's wrong​

Every DNS push, DMARC, TLSRPT, MTA-STS, its ownership-verification record, now lives on the domain's own page instead of being scattered across separate screens, and all of them share one confirm flow: dotMARC looks up what's actually there first and shows you a before/after diff before touching anything. The real change is what happens when that record is a CNAME delegated to a third party (a common shape for TLSRPT and DMARC when another vendor manages your reporting): dotMARC used to just refuse and tell you to fix it by hand. Now it says exactly what it's about to do, deleting that CNAME and replacing it with the record dotMARC manages, and only proceeds once you confirm. Every push also gets its own manual recheck button, so confirming a fix landed doesn't mean waiting for the next scheduled check.

MTA-STS closes its last Azure-only gap​

Azure Container Apps needs a second, easy-to-miss DNS record before it'll bind a custom domain: an ownership-verification TXT record alongside the usual MTA-STS CNAME. dotMARC now shows that record right on the MTA-STS tab and pushes it automatically alongside the CNAME on Azure deployments, so "the CNAME's right there, why won't it activate" is one less thing to debug by hand.

A real health checklist, not just a DMARC guess​

DMARC's status used to be one chip standing in for four different things, including whether a cross-domain authorization record existed, checked only if the record itself was already fine. That authorization check is now fully independent, shown as its own row, checked and pushable on its own regardless of what the main DMARC record is doing. Alongside it, dotMARC now runs SPF and MX checks for the first time (presence, a sane record count, and that MX targets actually resolve), and DKIM if you tell it which selector to look for. All seven checks, DMARC record, DMARC authorization, TLSRPT, MTA-STS, SPF, MX, and DKIM, now live on one consolidated health checklist on each domain's Overview tab.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Know when a domain stops sending reports​

dotMARC now watches every monitored domain's report cadence, not just its pass rate. If a domain goes past its expected reporting interval, you get an alert, through a Teams adaptive card, a generic JSON webhook, or both, instead of noticing weeks later that a client's reports quietly stopped arriving. Alerts resolve themselves automatically the moment a report comes back in, and a cooldown keeps a genuinely down domain from paging you every cycle. Configure delivery from the new Alert settings page; the Alerts page itself is the feed.

TLS Reporting joins MTA-STS​

SMTP TLS Reporting is MTA-STS's other half: where MTA-STS tells senders to require a secure connection, TLSRPT asks them to tell you when one failed. Point a mailbox at it, and dotMARC checks every domain's TLSRPT record daily, polls for the aggregate reports, and surfaces both DNS status and delivered reports on the domain's own page, including the specific failure reasons, not just a pass/fail count. A failed-session report raises an alert through the same pipeline as monitored-domain alerting; a later clean report resolves it.

Push DNS changes instead of copying them by hand​

Every DNS record dotMARC asks you to add, the MTA-STS CNAME, a missing or misconfigured DMARC record, now a TLSRPT record too, can be pushed straight to Cloudflare or Azure DNS instead. Click push, authenticate through that provider's own consent screen, and it's done. Nothing about that authentication is ever stored: every push is its own fresh exchange, and a misconfigured record gets a before/after diff to confirm before anything is overwritten. If your DNS isn't on one of those two providers, or the deployment hasn't set either up, the manual instructions are still right there, this only ever adds an option, never removes one.

Tell us what to build next​

There's a new Feedback & Feature Requests page linked from the site nav, post an idea, vote on someone else's, or just see what's already planned.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Who owns that source IP?​

The Sources tab on each domain's detail page now enriches every source IP with its registered organization and country, looked up via RDAP. A DMARC failure from an unfamiliar IP no longer means pasting it into an external WHOIS tool by hand. Lookups are cached indefinitely once resolved, covering both IPv4 and IPv6, and related IPs in the same registry allocation block (for example a whole /31 from one provider) share a single cached lookup instead of each triggering its own RDAP call.

Self-hosted or Azure-hosted MTA-STS, without the yak-shave​

MTA-STS tells receiving mail servers to require a valid, verified TLS connection when delivering to your domain. Standing it up means hosting a policy file on mta-sts.<yourdomain> with a real, publicly trusted certificate, for every domain you manage. dotMARC now does this for you, from a new Manage MTA-STS page: enable a domain, point a CNAME where it tells you (a sync button next to the MX hosts field can pull the current record straight from DNS instead of typing it from memory), and dotMARC verifies DNS, provisions the certificate, and serves the policy, either through your own self-hosted instance (via Caddy's on-demand TLS) or, on the Azure deployment, through Azure Container Apps' managed custom domains. The domain detail page's own MTA-STS tab stays purely a status view: a chip and a detail message that walks you through onboarding and flags anything that regresses later.

Try it without installing anything​

There's now a public demo at demo.dotmarc.app, seeded with a simulated MSP's worth of client domains and DMARC history. Switch between an Admin and a Group-scoped Viewer persona to see exactly what an external client would (and wouldn't) have access to. It resets on a nightly schedule, so feel free to poke at everything.

Everything else​

As always, see the full changelog for everything that shipped between these two tags, including the usual pile of fixes.

Why dotMARC​

If you manage DMARC for more than a handful of domains (an MSP watching client domains, or one org watching its own), the aggregate reports mail providers send back pile up fast, and they're not meant to be read by a human. dotMARC points every monitored domain's DMARC record at one mailbox, polls it, parses the reports, and attributes each one back to the right domain automatically. No per-domain mailbox, no manual XML wrangling.

What's in this release​

• One mailbox, every domain: automatic polling and parsing of DMARC aggregate (RUA) reports, deduplicated so a message is never processed twice, attributed back to the right domain from its From header.
• Multi-domain dashboard: pass/fail rates, source breakdowns, and DNS record status across every monitored domain, filterable by Group and Tag.
• DNS status checks: live DNS lookups confirm each monitored domain's DMARC record is actually in place and pointed at the right mailbox, not just assumed.
• Built for MSPs: fine-grained, per-domain access control. Grant an external client visibility into just their own domains via a Group-scoped Viewer role, not an all-or-nothing login.
• Self-hosted, your data: runs on your own infrastructure via Docker Compose or the included Azure Container Apps Bicep template, backed by PostgreSQL. Report data never leaves your environment.

Getting started​

• Read the docs to set up the two Entra app registrations dotMARC needs and run it with Docker Compose.
• View the source on GitHub: dotMARC is open source.

More to come. Check back here for release notes as new versions ship.