Yes. Except in this case, the company is paying Mailgun to process inbound mail and attach SPF/DKIM/DMARC headers, which they don't do. And this is counter to their own API spec.
If you are running your own SMTP server, then you wouldn't be relying on headers from Mailgun.
Essentially though you are right, using Mailgun is akin to having an SMTP server without any spam protection in place, and limited ability to put that spam protection in place. You are better off running the server yourself.
The point here is that Mailgun customers won't be aware of this, and as such, it's a vulnerability.
The recipient has to be a mailgun user, yes.
Essentially, vulnerability reporter is saying "hey, you've created a landmine field of open relays, which hackers only have to discover to abuse" and mailgun is saying "no we haven't, our USERS have created those"
that is why this is different from 'literally anything that accepts email.'
Your attack is "I can spoof an email from address". Is that not true for literally anything that accepts email?
The person who receives your spoofed message gets a link to the original message (message-url) and can download it, right? Can't they download it and validate spf, dkim, sender ip, whatever else?
This really sounds like it's working as intended. You asked to receive email. You receive email. You can perform filtering on the email to get rid of spam if you want.
You said "If that address is handled via an inbound route to a webhook [and they don't do any validation] [then phishing is trivial]"
Is that not identical to "if a company runs an SMTP server, you send a spoofed email, and they don't do any validation then phishing is trivial"?