Error checking of DBCC CEHCKDB is not entirely straightforward
You can use it in a SQL Agent Maintenance Plan I believe, but I'm not familiar with that
SET @sql = 'DBCC CHECKDB (' + QuoteName(@name) + ') WITH ... options ...'
EXEC sp_executesql @sql
IF @@ERROR <> 0
.. Error Handler ...
... Continue with backup ...
The options I use are EXTENDED_LOGICAL_CHECKS and DATA_PURITY
But ... that said ... I personally would NOT stop backups because CHECKDB failed. The failure might be minor (and repairable), the failure might go unnoticed for some time - and then you have no backups, which might be critical in a number of ways - if you stop backing up the LOG (for FULL Recovery Model) it will grow continuously, might fill the disk, but would then need shrinking - which we try to avoid at all times.
Also, CHECKDB can be slow, and could become a scalability problem, so we prefer to do CHECKDB on a RESTORED copy of the database (on a non-critical server). That also proves that the database backup is actually restorable
Some other things I would look to, in terms of early-error-warning:
Set all databases to Page Verification = CHECKSUM rather than TORN_PAGE or, worse!!, None (You then need to rebuild all indexes to "apply" the Page Verification because only newly written pages will get a Checksum)
Set backups to "CONTINUE_AFTER_ERROR " - better, to my mind, to have something that might be rescuable rather than nothing.
Set backups to use WITH CHECKSUM (that both checks that the Page Verification is correct and generates a checksum for the entire backup)
I would also recommend that you turn on Compression of backups - there is a single, global, flag you can use (i.e. to change the default). Reduces I/O on both Backup and Restore, and of course file size / transmission time over LAN/WAN etc.