Looks like blocking an MTA after an issue is fixed is standard for the folks that set up this "service".
With helpful log messages like this:
554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.
No reference on where to try to de-list, no reference to what blacklist is employed. Oh so helpful.
It is automated, so I don't know why they employ customer service.
Automation gone wrong?:
Hint, I think so.
https://www.crn.com.au/news/cisco-blacklists-thousands-of-legit-aussie-mail-servers-296155
... Thousands of Australian businesses have been unable to send emails this week due to a configuration error in a blacklisting service operated by Cisco Systems. The issue, which has baffled IT administrators all week, incorrectly gave a large set of IP addresses – many of them Australian customers of Cisco’s IronPort service – a poor reputation score. ...
We are not alone :-)
http://michael.orlitzky.com/articles/cisco_%28senderbase%29_security_products_lose_email.xhtml
... SenderBase reacts badly to minor incidents, and there's no way to fix the system manually.
Of course, good design decisions in the hardware as well:
https://threatpost.com/cisco-warns-of-critical-flaw-in-email-security-appliances/120968/
...Cisco Systems released a critical security bulletin for a vulnerability that allows remote unauthenticated users to gain complete control of its email security appliances.
Update: 7/10/17 - Now we are reported as "good" by that same service. Not sure how we rocketed from poor to good.
Might just be a basic program doing rand calls I suppose.