Personally I find most of those automated code tools useless. There are times when it fails code for things that are simply preference and things that are bad in some circumstances but good or even necessary in others. And often they leave the dev unsure about what the actual fix should be. If you know something fails but don't understand why it fails or what you should be doing instead, the tool itself has failed.
What does help is 100% code review. No code is committed to the production branch without being accepted through code review and no dev has the rights to commit to the production branch only the build team or the lead.
This is where you send back the bad code preferably with an explanation as to why it is bad. The key is to make it painful to not fix the code. Yes they will have a few times where the deadline will be missed because the code failed code review. And they will have to explain that as a reason. This leads people to be less likely to make the same mistake repeatedly so that they can meet their deadlines. If there is no pain to writing bad code, there is no reason to fix it, human nature being what it is.
That said, you and your team need to have an agreement concerning what is good code and what is acceptable code. If your standards and theirs are currently in a mismatch, this needs to be resolved over discussions and an agreeable standard approved. If they have input into the standard (and yes that means you need to compromise and accept their standards at least in part, having the discussion is irrelevant, even counterproductive, if you are still going to dictate end results), that are going to have more buy into actually using it.