Non hai un componente lato server in esecuzione adesso?
Eviterei che SQL Server inviasse la stessa Email.
Se hai solo bisogno di codice da qualche parte per svegliarti di tanto in tanto e verificare condizioni specifiche e intervenire, potresti scrivere una semplice app per console e utilizzare l'utilità di pianificazione di Windows sul server per eseguirla ogni tanto. Se le condizioni sono corrette, invia i tuoi messaggi e-mail, altrimenti, basta uscire pulito. Controlla di nuovo la volta successiva che l'utilità di pianificazione attiva l'app della console.
Oppure potresti scrivere un servizio di Windows per fare essenzialmente la stessa cosa, tranne per il fatto che useresti l'API di attività oi timer di Windows per svegliarti di tanto in tanto e verificare le condizioni appropriate. Il servizio sarà un po 'più complicato della programmazione di una semplice app per console. Esistono problemi di installazione del servizio. Non è possibile che il codice del lavoratore blocchi il thread principale in cui stai ascoltando per cose importanti come i messaggi di controllo del servizio. Anche il tuo codice lavoratore deve essere reattivo a questi eventi. Quindi se ricevi un messaggio di spegnimento, devi rispondere ad esso in un ragionevole lasso di tempo (un secondo o due, non un minuto o due). Probabilmente vuoi prendere in considerazione un tipo di progettazione basata sulla coda che può inviare metà dei messaggi, chiudersi, risvegliare e inviare l'altra metà senza perdere il posto, e così via.
Se non sei esperto su problemi come l'installazione del servizio e la sincronizzazione dei thread e gli eventi di controllo del servizio, farei semplicemente la semplice app per console e userai l'Utilità di pianificazione di Windows. "Low tech" può effettivamente essere una specie di cosa bellissima.
Ma per reiterare, sicuramente non lo farei direttamente da SQL Server. Solo perché è possibile (le stored procedure estese .NET) non significa che dovresti. : -)