Changelog

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