If you must use the same account on both environments, Drupal/CiviCRM hooks could potentially support this? *(All of this answer is likely more work than just using the provider's supported test mode, though!)*

You can pick any hook that fires before `Mte.callback` gets fired, and trigger rejection / invalidation based on any of the incoming data including the secret key or contact details in the request.

CMS boot hooks (eg Drupal [`hook_init`](https://api.drupal.org/api/drupal/modules%21system%21system.api.php/function/hook_init/7.x)) or CRM config hook ([`hook_civicrm_config`](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_config/)) happen early but on many requests so will add overhead; if possible I'd do this as late and specifically as possible - [`hook_civicrm_apiWrappers`](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_apiWrappers/) could be just the ticket if it works for this usage? Alternatively you could just throw some interception in `settings.php` / `civicrm.settings.php` / environment-specific `settings.development.php`.

If the secret keys aren't suitable, you could look for test-specific properties of the submitted contact data.

That might look like,

    // Lives in settings.php so it's not in your committed code.
    $mandrill_secrets = [
      'development' => 'devkey',
      'production' => 'livekey'
    ];

Boot time: obtain current environment, put in `$environment`:

 * [Drupal environment module](https://www.drupal.org/project/environment)
 * `strpos($_SERVER['SERVER_NAME'], '.demo.example')`
 * Whatever you want to use ...

Before CiviCRM has a chance to respond to `civicrm/ajax/mte/callback`: If the supplied secret doesn't match the current environment, unset it or make it invalid.

    if (isset($_GET['mandrillSecret']) && $_GET['mandrillSecret'] != $mandrill_secrets[$environment]) {
      $_GET['mandrillSecret'] = 'invalid';
    }