NinjaOne tickets​

NinjaOne only lets a signed-in person raise tickets, so dotMARC connects as a NinjaOne user. On Manage > PSA settings, the new NinjaOne tab takes your instance and a client app's ID and secret, then Connect to NinjaOne signs you in at NinjaOne and brings you back. The tab shows who connected and when the sign-in was last refreshed.

Choose the ticket form, the status new tickets start in, and their type, priority and severity, then link Groups to NinjaOne organisations as you would companies in the other PSAs. Domain imports take a ninjaone organisation column.

When an alert clears, dotMARC adds a private comment and sets the ticket to Resolved. NinjaOne doesn't let other apps close tickets directly, so its own rules close it in time. A ticket a tech resolves or closes, or moves to a custom status under either, resolves its alert.

See NinjaOne for setting up the client app.

Keeping the connection alive​

NinjaOne's refresh tokens last an hour unless they're used, so dotMARC uses its sign-in every 20 minutes, even when no alerts are firing. If dotMARC is stopped for more than an hour, NinjaOne forgets the sign-in: dotMARC raises a new PSA connection lost alert and stops raising NinjaOne tickets until someone reconnects. To survive longer gaps, ask NinjaOne support for sliding refresh tokens, as the docs explain.

Smaller changes​

• PSAs are now listed HaloPSA, NinjaOne, ConnectWise, Autotask everywhere: the settings tabs, the Groups and Domains pages, and domain import.
• The API reference sets each parameter's name apart from its details, so long parameter lists are easier to scan.

A much bigger API​

Filters on every list​

Every list endpoint takes filters, with the same rules everywhere: give several values with commas or by repeating the filter, in any letter case, and dates as a day or a time with its zone. A value dotMARC doesn't recognise is a 400 that names the filter and lists what it accepts. See Filtering.

• Alerts: type, severity, domain, group, tag, whether the API can acknowledge it, whether it has an open PSA ticket, and when it was raised or resolved.
• Domains: name, groups and tags, the result of every DNS check, the same plain-language status the client portal shows, DMARC policy, DNS provider, when reports last arrived, and pass rate.
• Groups and tags: search by name.

New endpoints​

• The audit log: who did what, filtered by action, actor, target, domain, date or text. A key limited to certain groups sees only the entries about its own domains and groups.
• Sending sources: every IP that sent as a domain over any range of up to a year, with its pass rate and, once dotMARC has looked it up, who owns the network.
• DMARC and TLS reports: each report with its records, and the original file exactly as the receiver sent it.
• The dashboard's headline figures, over the domains a key can see.
• Client reports: each group's schedule and delivery history, a report as a PDF for any period, and sending a report now, recorded and audited as from the Reports dialog.
• Parse failures: report emails dotMARC couldn't read, and why.
• PSA tickets on every alert.

The report summary takes any range of up to a year with from and to, and how many sending IPs to return with top, and is now worked out in the database. Every endpoint, filter and error is in the API reference, whose code examples now start with PowerShell, C# and curl.

Light and dark brand colours​

Manage > Branding now sets a primary and secondary colour for light mode and for dark mode. Dark colours start automatic, worked out from the light ones, until you pick your own. Advanced: backgrounds sets the page and card colours for each mode. A Group can set its own light and dark colours too.

Every colour shows a swatch and its WCAG contrast rating (AAA, AA, AA for large text only, or below AA) against the background it sits on. You can still use a colour that falls short, since a brand's official colours sometimes do.

The secondary colour now does more: headings, the pass rate line, footer links and neutral statuses in the portal, and section headings and table headers in client reports. See Branding.

Reports that wouldn't import​

• DMARCbis reports. Reports that name the software that generated them, or include the new psd tag, failed with "failed schema validation". They now import, as do reports with DMARCbis's pass disposition.
• Reports in an unusual order. Some senders, such as Trellix, put a report's sections in a different order from the standard. A report that has everything dotMARC uses now imports, and the log says where it strayed.
• If a report still can't be read, the log and its parse failure now say exactly why.

Smaller changes​

• DNS push setup scripts. A script creates the Azure DNS app registration for you, and another prepares a Google Cloud project, with each step shown in the DNS push docs.
• An unexpected error in the API now comes back in the API's own error format, not as a web page.

DMARC reports in the DMARCbis format​

Some reporters have started adding parts of DMARCbis, the updated DMARC standard, to their aggregate reports. Reports that named the software that generated them, or included the new psd tag, failed with "DMARC aggregate report failed schema validation" and were retried on every poll. They now import, as do reports whose disposition is DMARCbis's pass.

Reports left unread by the failure are picked up again on the next poll after you update. If a report still can't be read, the log and its parse failure now name the element at fault.

Client report email​

• New permissions take effect straight away. dotMARC fetches a fresh Microsoft Graph token when you save Manage > Email & reports, and retries a refused send once with a new token, so adding a permission no longer needs a restart.
• Clearer refusals. When Exchange's application access policy blocks a send, the error says so. The Client reports page shows how to check the policy, and that changes to it can take a while to apply.

A friendlier API​

• Find a domain by name. Every /domains/{domain} route takes the domain's name, such as contoso.example, as well as its id, so a script that knows the name needs one request, not two.
• Every error is documented. Each operation now lists the errors it can return (401, 403, 404, 409, 429 and 500) and what each means. An unexpected error comes back as problem+json, like every other API error, instead of the web page it returned before.
• One click to the reference. Using the API and the API keys tab on Access link straight to the API reference.
• Examples use the reserved .example domains.

DNS push setup scripts​

Setting up DNS push for Azure DNS is now one command: a script creates the Entra app with the right redirect URI and permission, and prints the client ID and secret to enter in dotMARC. For Google Cloud DNS, a script turns on the APIs and gives you a link for each remaining step in the console. The docs show each script.

Smaller changes​

• HaloPSA, ConnectWise and Autotask settings remember the names of your chosen ticket types, priorities and statuses as soon as the options load, so they no longer show as numbers after a reload.
• Help icons sit centred on their fields, and the Send test buttons are as tall as the inputs beside them.
• A new AI use page explains how AI tools help build dotMARC, and that a human developer reviews every change before release.

ConnectWise and Autotask, alongside HaloPSA​

Alert tickets are no longer HaloPSA only. dotMARC raises and closes tickets in ConnectWise PSA and Autotask too, and you can connect more than one PSA at once.

• Manage > PSA settings has a tab for each PSA, with a Test the integration button that creates, checks and closes a real ticket.
• Each Group (and, where needed, each domain) links to a company in each PSA. Manage groups suggests matches by name, and a domain import can set the company per PSA.
• dotMARC checks its open tickets regularly, so closing a ticket in any PSA resolves its alert. HaloPSA's webhook still works and stays the fastest route.
• Each alert shows the tickets raised for it in each PSA.

See PSA integration for how several PSAs work together.

A branded client portal​

Give a client contact a simple, read-only view of their own domains instead of your dashboard. Turn on Client portal for their access grant (it must be limited to their Groups), and when they sign in at your usual dotMARC address they see:

• Your domains: each domain's status in plain words (Protected, Monitoring only, Needs attention, No reports yet), its pass rate and trend, and open alerts.
• A page per domain: what its policy does, its health checks, who sends as it, and its alerts.

Manage > Branding sets your product name, colours, logos and support details, with a contrast warning and a live preview in light and dark. On Manage groups, a Group can override the name, logos and colours with the client's own, and Preview as client shows exactly what they'll see. Portal users can't reach anything else in dotMARC, or the API. See Client portal.

Scheduled client reports​

dotMARC can now send each client a branded PDF report weekly, monthly or quarterly, by email:

• A cover with their status in one line, a summary of every domain with the change since last time, a pass rate trend, each domain's policy, health, top senders and what receivers did, and a short list of what to do next.
• Set up email on Manage > Email & reports, through Microsoft Graph or any SMTP server, along with the time zone, send hour and number format reports use.
• Each Group's Reports button on Manage groups sets its schedule and recipients, and can send or download a report for any past period, such as a quarter for a business review.
• A report that can't be sent is retried for a day, then raises a Client report failed alert.

See Client reports.

Alerts in Slack​

Alerts can go to a Slack channel through an incoming webhook, alongside Teams and the generic webhook. Each channel on Alert settings now has its own switch and Send test button.

Upgrading​

Database migrations run automatically when the new version starts.

• HaloPSA moves to PSA settings. Your HaloPSA connection, defaults and client links carry over to Manage > PSA settings. Nothing to redo.
• Client reports through Microsoft Graph need the Mail.Send application permission on dotMARC's app registration. A report too big for one Graph request (over about 3 MB, so only with a very large logo) also needs Mail.ReadWrite in place of Mail.Read. With SMTP, neither is needed. Reports stay off until you set up email.
• Autotask needs an API tracking identifier from your own Autotask setup until dotMARC has its own.
• A new permission, ReportsManage, covers email settings and client reports. The Admin role gets it automatically; add it to any custom role that should manage reports.

Everything else​

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

MTA-STS MX hosts come from DNS again​

When the old Manage MTA-STS page became a tab on each domain, its button for looking up a domain's MX hosts didn't come with it. So a domain switched on from Advanced could end up with no MX hosts, which means the policy dotMARC served listed no mail servers at all, and senders that check MTA-STS could refuse to deliver.

• Filled in from DNS. When the MX hosts field is empty, it's filled in from the domain's MX records as soon as the MTA-STS tab opens, ready for you to check and save. Look up from DNS is back beside the field to fetch them again.
• Never on without MX hosts. dotMARC refuses to save MTA-STS as on with no MX hosts, and a bulk import skips such a row with a note instead.
• Easy to spot. A domain that's already on with no MX hosts says so on its MTA-STS tab, with the hosts filled in from DNS and the Advanced section opened.

Check your domains after upgrading: open the MTA-STS tab of each domain with hosting on. Any that shows the warning needs its filled-in MX hosts saved.

Waiting for a certificate isn't a failure​

On Azure, a new domain's TLS certificate can take a few minutes to issue. dotMARC used to show that wait as Failed with Azure's raw error, even though it carried on and finished by itself. It now shows Waiting for certificate, with a note that Azure is still issuing it and dotMARC retries automatically. A certificate Azure can't issue still shows as Failed, with Azure's reason.

Help beside every setting​

The settings pages now have a small help icon beside each field, explaining what it does and what to put there: alert settings and the HaloPSA connection, DNS push (including the exact callback URL each provider needs), audit log retention, and MTA-STS. Hover over it, or tap or tab to it.

Upgrading​

There are no database migrations and no new settings. Redeploy, then check your MTA-STS domains as above.

Everything else​

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

DKIM records filled in for you​

Configure selectors on a domain's DKIM check now does more of the typing:

• Records already in DNS are filled in. For any mail platform, a selector that's already published starts with its current CNAME target or TXT value, and says so. Nothing you've typed or saved is replaced.
• Paste from Microsoft 365. Microsoft 365 domains get a box for the output of Get-DkimSigningConfig, or the Defender portal's Publish CNAMEs text. dotMARC reads both selectors' targets from it and fills them in.
• The known part of a Microsoft 365 target. With nothing published yet, each selector starts with the part that follows from the domain, such as selector1-contoso-com._domainkey., and a note on what to add. The rest (your tenant's name and a letter Microsoft assigns) can only come from Microsoft 365, and dotMARC won't save a target that stops at ._domainkey.

The dialog's rows line up properly too: each selector's type and value sit side by side, with the selector named in the value's label. See DKIM records.

A tidier API description​

The OpenAPI document at /api/v1/openapi.json now groups operations into Domains, Imports, Groups and tags and Alerts, and describes whole numbers and decimals as numbers rather than as text matching a pattern. API tools show cleaner types as a result. The API reference on this site is built from the same document.

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.

An audit log​

The new Audit log page records every change made in dotMARC: domains, groups, tags, roles and access, settings and ticket rules, DNS pushes, HaloPSA actions, sign-ins and page views. Each entry says who did it, when, and what changed, field by field, with secrets recorded as changed but never stored. Filter by person, action, target or date, and export what you see as CSV. Entries are kept for a period you choose and cleaned up daily.

Two new permissions control it: AuditView to read the log and AuditManage to set how long it's kept. Admin has both. See the audit log docs.

Import domains in bulk​

Manage domains > Import domains adds many domains at once from a pasted list, a CSV file or an Excel file, with their groups, tags, Halo client, monitoring, DKIM selectors and MTA-STS settings. Nothing is saved until you've seen a preview of every row: new domains, changes to existing ones (shown in red where something is removed), duplicates and anything invalid, with suggestions for group and tag names that look mistyped. Existing domains can be skipped, added to, or made to match the file. The whole import is saved at once or not at all. See importing domains.

DNS health alerts​

dotMARC already checks each domain's DMARC, SPF, DKIM, MX, TLS-RPT and MTA-STS records. It now alerts when they go wrong, through your usual Teams, webhook and HaloPSA channels:

• A check breaks. A failing check is rechecked within minutes before it alerts, so a brief DNS blip doesn't open a ticket. Each check can alert when it breaks (the default, which stays quiet for records that were never set up), whenever it fails, or not at all.
• The DMARC policy weakens. Moving from reject to quarantine or none, or lowering the percentage.
• The nameservers change, often the first sign of a DNS migration. This one doesn't open a ticket by default.

Alerts close themselves once the problem is fixed. Policy and nameserver changes can be deliberate, so those can be acknowledged with a button, by closing their Halo ticket, or automatically after a number of days you choose. See DNS health alerts.

SPF and DKIM push​

The DNS push that already set up MTA-STS, DMARC and TLS-RPT records now covers SPF and DKIM too:

• An SPF editor on each domain shows the record term by term, counts its DNS lookups by following every include, and warns when it needs more than the 10 lookups SPF allows. Add or remove senders (with a catalogue of common services), merge duplicate records into one, and choose how the record ends. A new setting picks whether new records end in ~all or -all.
• DKIM records for each selector can be stored in dotMARC, checked against what's published, and pushed.

Pushes to Cloudflare, Azure DNS and Google Cloud DNS change only the value they mean to, keep every other TXT record exactly as it was, and refuse rather than guess when the zone isn't what dotMARC expects. See editing SPF and DKIM records.

An API​

dotMARC has a JSON API for scripted bulk work, client reporting and integrations it doesn't have built in. It covers the common jobs: list domains and their DNS health, summarise a domain's DMARC reports, list groups, tags and alerts, add or import domains, set a domain's groups, tags and monitoring, and acknowledge alerts.

• API keys are created on the Access page, which now has People, Roles and API keys tabs. A key gets a role just as a person does, and a Viewer key can be limited to certain groups so it only ever sees those clients. Keys can't manage access, last 30 to 365 days, and are announced two weeks before they expire.
• Everything a key does is in the audit log, as that key and the person who created it.
• The API is described in OpenAPI at /api/v1/openapi.json on your own dotMARC, which tools like Postman can import directly.

See the API docs.

Fixes along the way​

• Domain names must now be real hostnames everywhere they're entered.
• A DNS push that fails partway through is recorded as such, rather than looking like it never ran.
• A nameserver lookup that fails is treated as an error rather than as "no nameservers", and dotMARC never reports a top-level domain's nameservers as a domain's own.

Upgrading​

The database is migrated automatically on startup. There are no new required settings.

• Admin gets the new permissions automatically. Custom roles that should read the audit log need AuditView added on the Access page's Roles tab.
• DNS health alerts are on, in "when it breaks" mode for every check, as long as alerting is enabled. A check only alerts after it has passed at least once, so records that were never set up stay quiet. Look over Alerts > Settings after upgrading if you'd rather start differently.
• The API is available as soon as you create a key. Each key may make 120 requests a minute; set Api__RequestsPerMinute to change that.

Everything else​

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

Search the Halo client list​

Every Halo client picker can now be searched: type part of a client's name and the list narrows as you go. That covers the Halo Client picker on each group and each domain, the Halo client filter on Manage domains, and the client you run the Halo integration test with. The agent picker under Assign new tickets to can be searched the same way, with Don't assign kept at the top.

Halo clients, ticket types and statuses are now listed alphabetically too, instead of in whatever order Halo sent them. Priorities keep Halo's order, since that runs from lowest to highest.

Search groups and tags too​

The same search is on the other dropdowns that grow with your data:

• Choosing a domain's groups and tags on Manage domains, and a person's groups when granting access. These now open a search box above a checklist. Tick as many as you like, then click away or press Escape to save them all at once. Groups the search is hiding stay ticked.
• The Group and Tag filters on the Dashboard and Manage domains, and the Country filter on a domain's Sources tab.

Short, fixed lists, such as Yes or No, severities and delivery modes, stay as plain dropdowns.

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.

Every Halo client, not just the first page​

dotMARC only ever asked Halo for one page of clients, so if you have more clients than fit on a page, the rest were missing from Manage groups and the Halo client pickers, with no error to say so. It now asks page by page until it has them all. Halo can quietly send fewer clients per page than dotMARC asks for, so dotMARC counts the clients it has received against Halo's total rather than trusting the page size.

Create groups from your Halo clients​

When Halo is connected, Manage groups now lists the Halo clients that no group is linked to or named after. Create group makes a group with the client's name and links it to that client in one step, and Create all does the same for every client listed, after asking you to confirm. Only the groups are created, so add their domains from Manage domains afterwards.

Suggested matches between a group and a Halo client are also looser: case, punctuation and endings such as Limited, Ltd or LLC are ignored, and a group whose name starts a client's name is suggested that client. If Halo can't be reached, Manage groups now says so instead of quietly showing no suggestions. See Create Groups from your Halo clients.

Filters and sorting on every table​

The Filters button that the Dashboard and Manage domains tables have is now on every table: a domain's Sources, TLS reports and Raw reports tabs, Alerts, Unparseable messages, Roles, Access grants, Groups, Tags and the Halo clients without a group. It opens a row of filters under the headings, one per column, and the column headings now sort.

The Sources tab is where this helps most. You can narrow it to new sources, a single SPF or DKIM result, a disposition or a country, search by IP, reason or owner, or hide sources below a minimum volume.

Smaller things​

• The demo splits SPF and DKIM failures. It now includes senders that fail only SPF or only DKIM, so every bucket of the rejected-mail reasons shows something.
• The TLS and raw report tables show date ranges the same way, so a date search works on both.

Docs and website​

• The docs are organised into categories, in the order you're likely to need them: get started, deploy, monitor, alerts and integrations, administer, and about the project. There's also a new Update or redeploy dotMARC page. Existing links still work.
• Fresh screenshots. The website's screenshots are now captured automatically from the demo, in both themes, so they show the app as it is.

Upgrading​

There are no database migrations and no new settings. Redeploy and you're done. If you use Halo, open Manage groups afterwards to see any clients that were missing before.

Everything else​

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

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 HaloPSA 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.