Get to know more about URIports

Read the frequently asked questions about URIports and the reports. Also check our blog with more articles about DMARC, Content Security Policy, Network Error Logging (NEL) and more!


When you have set the correct headers on the server where your website is running, your visitors' browsers are instructed to send reports to an address you have set. When this address is set to your own URIports account, we will receive and process the reports so that you have a good overview in your account of problems that occur on your website. Read more on our Getting Started page.

In addition to website reports, we can also receive DMARC and MTA TLS and reports. We will receive this as soon as you have set the correct policy in your DNS records. Sounds complicated, but it is not. Check our Getting Started page for more info.

Good that you ask! URIports was created by two close friends, Freddie Leeman and Roeland Kuiper, who have over a decade of experience in online coding, montoring and security. This project is fully self-funded and the result of a great love for the field of online software and security. We hope that we can help you better monitor your website and secure your website with, among other things, a good content security policy. Thank you for your interest!

Our servers are located in the Netherlands (within the EU) and therefore have to comply with very strict privacy legislation. The servers are located in a highly secured data center to create the safest possible place for your data.

Most reports we receive do not contain any personal information. The only possible personal information that may be present is the IP address, the browser's user agent and a URL that triggered a 404 error, for example. We only need the IP address to connect certain reports, such as determining that it is one user who submits multiple reports. For that reason, we do not store the IP address itself, but a hash of that IP address. We do not use the IP address for anything else. If a report contains URLs, the query parameters will be removed.
DMARC failure reports may contain personal information. All this personal information is filtered and removed before reports are processed.

Your Account

You can easily change your username/email address and email address you would like to use to receive notifications. Go to the settings and click the option to change your email address or click the notification settings.

Yes of course, when your requirements change, you can always up- or downgrade. Upgrades are instant and you will only pay the price difference between the old and new plan. We will show you exactly what will happen if you choose to upgrade in the application. When downgrading, we will downgrade your account automatically after your old subscription expires.

You can cancel your subscription at any time. When you have cancelled your subscription, the cancellation will be in effect at the end of your current subscription. We will not charge your payment method any more. You can cancel your subscription in the settings of your account.

We are sorry to hear that you are leaving! You can close your account in the settings. We will delete your account and related data immediately and this action is not reversable.

We use Paddle as a platform to sell our subscription plans. They store your credit card details and you will receive your invoice from Paddle. Their name will also appear on your billing statement. If you have questions about a Paddle transaction, you can easily contact them.

When you have found something that does not add up, send us a bug report at
Thanks for your help! We will try to fix the bug as soon as possible.

You can easily hide report types that you do not use. Go to your settings and click the option "Hide report types".


Certainly! You can filter your dataset and you can search to find exactly what you are looking for. In any case, we already aggregate your data and sort it in such a way that the most important reports are at the top of the list. There are 4 easy ways to navigate your dataset:

Search: By searching you can easily find reports. Think of searching on a certain url, a certain error code or something else. Searches are performed directly across your entire data set.
Filtering: You can easily filter on parts of the dataset by clicking the filter icon next to a field in your report.

View aggregated data: If an aggregated report contains multiple values in a specific field, we display it as an icon with a number after it . Click on that icon to see the values. We will then set a filter so that you will see exactly those values.
Inspect: If you actually want to view the individual reports of an aggregated dataset, you can click the "Inspect" button located to the right of an aggregated report. This opens a window containing all individual reports. Values that are unique in all reports will be summarized at the top of the window.

Reports that we receive that are triggered by many individual site visitors will be highlighted with a red number in your report list.
The threshold is based on the number of individual clients sharing the same violation relative to the total number of individual clients.

Reports that exceed the set threshold are the reports that you need to focus on. All website reports are automatically sorted on this threshold so you can immediately see what is important.

If you would like to ignore or block reports about issues that you can not fix, you can set ignore and block rules in your account. Read our blog about setting up ingore and block rules.

When a report is received that you would like to block, we will not process the report in your account and we will drop the report when we receive it. We use a fair use policy for blocking reports.
You can setup ignore and block rules in your account. Read our blog about setting up ingore and block rules.

Ignored reports are processed like normal reports, the only difference is that ignored reports are automatically hidden for your standard report view. You can view hidden reports by flipping the "Show hidden" switch in the reports view.

Blocked reports will not count towards your monthly quota, but to ensure that our service runs smoothly, we apply a fair use policy for blocking reports. Blocked reports have to be processed by our system to check whether they have to be blocked. The current fair use policy is 20% of your quota. So if you have a subscription with 500,000 reports, you can block 100,000 reports every month. It is possible that the fair use policy will change unannounced in the future. When you exceed the fair use policy limit, it is possible that newly blocked reports will count towards your monthly quota. Unactionable violations, like the 'abandoned'-network error are never counted towards your quota or fair use policy.

When you have a Content Security Policy violation that you want to fix, there are two options: fix the violation or white list the source. Read our blog about setting up a solid and secure Content Security Policy. It contains some tips and tricks on how to fix CSP violations.
Some violations can not be fixed. You can set ignore and block rules for those violations.

These network errors occur when a visitor on your site aborts fetching a resource on your site before it is complete. This can happen when a user is navigating to another page on your site before the site is fully loaded or when an ajax call is aborted. There is not much you can do to fix abandoned reports. When you do not want to see those reports in your account, you can block or ignore these type of reports.


In the settings of your account, you can define per notification channel what type of notifications you would like to receive. The email notification channel also has the option to set a notification frequency to aggregate notifications.

Yes you can, you can subscribe to our Telegram-bot to receive instant notifications on issues we detect on your site that were reported by the browsers of your site visitors.


DMARC (Domain-based Message Authentication, Reporting and Conformance) aggregate reports contain information about the authentication status of emails sent on behalf of a domain. With these reports, you can see which messages authenticate against DKIM and SPF. It is also visible which emails do not authenticate.

An aggregated report does not contain information about the email itself, but contains information about the source that sent the message, the domain used when sending, the IP address of the sending server, the number of messages sent on a given date, the DKIM and SPF sending domain and the authentication status.

All this information is useful for checking who sends an email on your behalf, whether the sender is allowed to send an email on your behalf, and whether these messages are properly authenticating against DKIM and SPF. In addition, you can check who sends malicious emails on your behalf.

Ultimately, you can ensure that the malicious emails do not reach the recipient's inbox, this can be done by enforcing a DMARC rejection policy.

A DMARC failure report contains the original email and email headers for an email that has failed delivery because it did not pass the DMARC validation. These reports can be handy for analyzing why an email failed the DMARC validation. When we receive such a report, we strip the message body and clean the headers from all privacy sensitive information, so no personal data is processed by our servers.

It is possible to save the unfiltered headers by uploading your PGP public key. The email headers will then be encrypted with your PGP public key. Read more in our blog about privacy and DMARC failure reports.

SPF and DKIM can associate pieces of an email with a domain. DMARC tries to match the results of SPF and DKIM with the content of the email and specifically the domain found in the email headers like the "From:" header. If the domain in the email headers matches the SPF and DKIM policies set, there is an alignment. If there is an alignment, the email will pass DMARC validation.

Have a look at the example below. The SPF auth results for hostname pass (1), but the hostname does not match the "Header from"-value (2). This causes the DMARC SPF check to fail (3). Please keep in mind that for DMARC to fail BOTH SPF and DKIM must generate anything other than pass. So in the example below the message still passes the DMARC validation. SPF can fail when messages are forwarded or are sent from a third party service. Avoid DMARC failures by adding a DKIM signature to every message that is sent on your domain's behalf.

When you have published your new DMARC policy in your DNS, it can take up to 72h for email providers to load your new policy, due to DNS caching. So, you should see results in your URIports account within 72 hours after updating your DNS records.
Besides this, it is good to know that most email providers send reports on daily basis.

To ensure that forensic DMARC reports are received, you must create a DMARC record and publish it in the domain's DNS. After publishing a DMARC record, URIports can receive failure (forensic) DMARC reports from all ISPs that support DMARC. These failure (forensic) reports contain crucial information to secure your domain. Check our Getting Started page on how to configure your DMARC record in your DNS.

Bear in mind that not all email providers send failure reports.

Simply put, DMARC compliance means that the emails that you or your organization send all pass DMARC validation. The goal is to achieve the highest possible DMARC compliance, so that no legitimate email is blocked.