First it helps to understand what we mean by forwarding. Let’s think of a scenario first. The providers used my example are used expressively just as an example and not indicative necessarily of what you would see in your own forwarders landscape.
A user has an outlook.com email address. You send marketing emails to this recipient. One day they decide they are no longer satisfied with outlook.com, and registers a Gmail address. Instead of changing their email address they are subscribed with to your marketing drip, they simply configure the auto-forward of their entire mailbox to Gmail.
The above does one important thing that matters in the context of DMARC. It retains the original From header so that once this user receives mail at Gmail, they know who originally sent it. This means Gmail will authenticate an email sent by your marketing provider, but by using outlook.com’s connecting IP since they did the delivery.
Due to address rewriting schemes, where the return-path is changed to the domain doing the forwarding, SPF largely will not help with DMARC compliance. This means in the majority of cases, only DKIM can help an email which was forwarded potentially still pass DMARC once received at the final destination mailbox. This is because DKIM is a header, and like the From header, it will be retained during this type of forwarding. DKIM survival represents your DKIM compliance with DMARC.
Regarding Threat/Unknown, that is correct. This category contains all data we don’t have an identifying rule for to highlight them as an ESP. Majority of the data you will find there is going to be a form of forwarding, or abuse, or even forwarding of abuse. You can also use the Compliant Filter drop down in the Detail Viewer and choose Impact of Policy if you want to see a view of all emails that would be impacted by any level of enforcement in your DMARC policy ahead of time.
I hope this helps.