Changelog

A new domain overview page is now available.

It is now much more detailed than before and aims to be a comprehensive bird eye’s view of your domain, providing the current status, quick statistics, and an easy way to spot issues that require your attention, for DMARC, SPF and SMTP TLS.

Read more in the Domain overview documentation page.

We’ve also moved the Checks feature: find an overview of the failing checks in the domain overview page, and browse the detailed list of checks inside the individual tabs for DMARC, SPF, and SMTP TLS, alongside the record validation results.

Find more about checks and validation for DMARC, SPF, and TLSRPT in the corresponding documentation pages.

Today, we’re launching a new feature called SPF monitoring, which adds observability capabilities to the dashboard to monitor SPF (Sender Policy Framework) records.

SPF still plays an important role in electronic mail, and is one of the two cornerstones of DMARC.

Until now, it was hard to obtain visibility into SPF records and spot issues and misconfigurations that affect email delivery. The new DMARCwise dashboard solves this:

• In the new SPF tab, the current SPF record will be presented visually and with simple natural language, making it easier to understand what your SPF record does.
• DMARCwise continuously scans and analyzes your domain’s SPF record, producing a list of Checks and Record validation results.
  • These two features evaluate the adherence of the configuration to standards and best practices, to ensure best compatibility and interoperability.
  • Our SPF analyzer supports all the SPF features and syntax variants and is heavily tested with hundreds of automated tests.

To learn more about the new SPF features, visit our documentation pages:

• SPF monitoring
• SPF checks and validation

Stay tuned for further updates around SPF monitoring.

When passing multiple roles with SAML SSO through the supported roles attributes, we now take the role with the highest level of permissions. Previously, the first one of the list was picked.

Learn more in our SSO documentation.

Starting today, all DMARCwise paid plans include unlimited reporting volume.

Previously, subscription plans such as Starter and Growth had a soft limit on the number of DMARC-complaint emails detected per month (as reported through DMARC reports).

The limit is now completely removed, and the price of subscription plans stays the same. Enjoy!

This change doesn’t affect the free plan, but it applies to the non-profit plan.

The DMARCwise dashboard now shows useful charts to monitor the trend of key metrics over time.

Specifically, the new charts help you monitor these metrics over time:

• Total emails reported.
• Amount of monitored/quarantined/rejected emails.
• DMARC pass/fail.
• SMTP TLS success/failure sessions.

Hover over a chart to see the corresponding metric value for the past 28 days.

SAML SSO is now fully compatible with Google Workspace after our testing, and we now provide a dedicated guide to set it up.

Although our SSO implementation theoretically works with any generic SAML implementation, each Identity Provider has their own peculiarities and we want to ensure the most commonly used ones are properly tested by us.

Read the Google Workspace SSO setup guide for more information, including how to set up access control and application roles.

We’ve made some improvements to the SAML SSO implementation to allow passing roles through SAML attributes and enforcing the presence of a valid role.

Previously, passing application roles from the Identity Provider to DMARCwise was only possible/documented when using Microsoft Entra ID.

Now it’s possible to use the custom SAML response attribute named urn:dmarwise:role to pass a role. DMARCwise will automatically assign and synchronize the role when the user logs in to DMARCwise with SSO.

In addition to this, it’s now possible to require the presence of a valid role attribute for every login. This is useful when using Identity Providers that don’t have an easy way to restrict who can use applications out of the box (e.g. Keycloak): users without a valid role attribute won’t be able to log in to DMARCwise when the option is enabled.

To learn more about roles and access control, read the updated SSO documentation page.

You can also refer to the updated Keycloak setup guide.

After a request from one of our customers, we’ve added a way to choose the period for which the statistics in the domains list refer to.

You can now choose between:

• Last 7 days (default)
• Last 28 days

Reflecting the period for which statistics such as the total number of reported emails, the DMARC pass percentage, etc. are calculated on.

This weekend, we have completed the second step towards a full migration of the core components of DMARCwise infrastructure to European cloud providers.

The main website dmarcwise.io is now hosted in a European Union country with a fully European cloud provider.

In the coming months we’ll be continuing this process and move other parts of the infrastructure to the EU, where possible. We expect that this will be especially appreciated by our European customers that take great consideration of data location and data privacy topics.

For customers using Keycloak as an SSO identity provider, we have just improved our SAML implementation with the aim of simplifying the setup process.

You’ll now find a setup guide specific for Keycloak in the documentation.

Plus, DMARCwise now supports the standard Keycloak attributes for the email address, first name and last name, so you can simply check them in the Keycloak client configuration without the need of manually entering the required claims.

This weekend, we have completed the first step towards a full migration of the core components of DMARCwise infrastructure to European cloud providers.

Our main database with all customer data is now hosted in a European Union country with a fully European cloud provider.

At the same time, we have reworked most of our infrastructure architecture to make it more reliable, resilient, faster and secure than before.

In the coming weeks and months we’ll be continuing this process and move the remaining parts of the infrastructure to the EU, where possible. We expect that this will be especially appreciated by our European customers that take great consideration of data location and data privacy topics.

When exporting domains to a CSV file, you can now optionally choose to use semicolons (;) instead of commas (,) as separators.

This can be useful when importing the CSV file in Microsoft Excel, which often expects semicolons by default in some countries.

Learn more in the export documentation.

We have added a new view option to configure which data columns are shown in the domain list/grid.

You can now choose to focus on Status and see at a glance the configuration status for both DMARC and TLSRPT for all domains.

The default focus remains DMARC.

The Focus feature will be improved to include more choices in the future. It will also be persisted, so that when you refresh the page or access from another device you don’t lose the state.

The MSP clients management page has been redesigned to be more compact and provide more information at a glance.

You can still view the details for a client as before by clicking on a row.

The page now also allows for filtering the list of clients by name.

Customers on the MSP plan using the clients feature can now choose whether to grant write permissions to invited users.

When you allow write access, additional permissions will be granted to the user on the domains they have access to. Learn more in the documentation page.

It is now possible to switch between subscription plans without contacting support. Specifically, these changes are now possible from the billing settings:

• Downgrading from the trial plan to the free plan.
• Downgrading from a canceled subscription to the free plan.
• Upgrading/downgrading between paid subscription plans (Starter, Growth, Scale).
• Change the billing interval between monthly and yearly for paid plans (Starter, Growth, Scale).

The plan change preview dialog will alert you if you need to reduce your usage before downgrading to a plan with lower limits or less features.

Customers on the MSP plan or on other custom plans are not affected by this change.

Customers that use Okta as an Identity Provider can now simplify the SSO setup by using the official app published in the Okta Integration Network catalog.

To learn more on how to set up SSO with Okta, consult our documentation.

We now support the custom userId claim for situations where you can’t configure the NameID claim to contain a persistent identifier like a user ID.

When using SSO with SAML, it’s important to make sure that the NameID claims contains a persistent identifier such as a user ID or employee ID, and not an email address. This is because the email address may change with time and a NameID change would make it impossible to match the user in DMARCwise upon login.

If you’re unable to change the configuration of the NameID claim, you can now create a custom claim with type userId: if the NameID format is not declared as persistent and the userId is present, the userId will be used in place of the NameID.

Learn more in the SSO documentation.

Starting 1 August 2025, duplicate DMARC and TLSRPT reports are automatically detected and discarded.

Some email service providers like Google are in fact known to sometimes deliver several copies of the same report, leading to incorrect statistics.

A report is now detected as duplicate if an identical report was received from the same sender in the previous 24 hours.

Although the DMARC specification suggests the use of the Report-ID for deduplication, some email providers tend to reuse the same IDs over short periods of time, therefore we’ve opted for a stricter algorithm.

Users can now change the email address associated with their account from the account settings.

Changing the email address requires following the confirmation link received via email. After confirmation, all the login sessions will be terminated and the old email address will receive an email alert.

We have published an RSS 2.0 feed for the DMARCwise product changelog. You can access it at this URL:

https://dmarcwise.io/changelog/rss.xml

Today, we’re launching a new feature called hosted DMARC.

With hosted DMARC, you can delegate the management of the DMARC DNS record to DMARCwise with a CNAME (alias) record.

You’ll then be able to manage the DMARC configuration from the dashboard, without going through your DNS provider for every change.

You can learn more about hosted DMARC and how to set it up for existing or new domains in our new documentation pages:

• Hosted DMARC
• Setting up DMARC

We have improved the validation of the fo tag in DMARC records. The fo tag stands for failure options and allows a domain owner to decide in which cases a failure report should be generated.

There are strict rules around the formatting and accepted values of the fo tag, and we have noticed that users often get it wrong.

For example, the following tag is valid:

fo=0:d:s

While these ones are not:

fo=0:1

fo=0:0

(0 and 1 are mutually exclusive and there can be no duplicates.)

DMARCwise’s DMARC record validator now catches this issue and shows an error about it in the dashboard.

Existing records were re-scanned and so you may see new issues being reported in the dashboard.

Keep in mind that the fo tag must be used only when the ruf tag is also specified. DMARCwise doesn’t currently support the processing of failure reports, but you can specify an email address of yours in the ruf tag to receive these (rare) reports.

Your domains’ DMARC records are now analyzed to identify syntax issues that could prevent parsers from using DMARC correctly.

When a syntax error or potential issue is detected, you’ll find the details in the DMARC overview page. A check warning or error will also be triggered.

We currently validate the record to make sure that:

• No leading whitespace is present.

• Policy tag (p) is present.

• Policy tag (p) is the second tag in the record.

• All tag names are valid.

• All tag values are correctly formatted.

• No duplicate tags are present.

• No misplaced mailto: destinations are detected.

We currently don’t detect the following issues:

• Strict fo value compliance.
• Missing ruf when fo is present.
• rua and ruf URIs correctness.
• A record not starting with v=DMARC1 (leading whitespace is ignored) will be discarded and not shown at all.

The validation will be improved in future updates.

Learn more in the documentation.

The DMARC record summary table now shows default values when a tag is not set.

For example, if you don’t specify the sp tag (subdomain policy) in your DMARC record, the UI will show that the value of p is being used as per RFC 7489.

You can now group domains by domain group, DMARC setup status or DMARC policy, making it easier to identify which domains require action.

You can now bulk import and export domains from/to a CSV file to ease the management of a large number of domains.

Learn more in the documentation about importing domains and exporting domains.

We’ve just improved the design of several tables and pages in the web app.

Take a look at the before and after in the video above.