Introduction

Imaginons qu’une base de données doive périodiquement communiquer quelque chose vers l’extérieur : envoyer une notification d’erreur, transmettre un rapport, signaler la fin d’un traitement planifié ou envoyer le résultat d’une requête SQL.

Lorsqu’il existe déjà une véritable couche applicative autour de la base, c’est généralement l’application elle-même qui s’en charge. Mais si la logique d’automatisation vit depuis longtemps dans SQL Server, maintenir un service séparé uniquement pour quelques notifications peut être disproportionné. C’est à ce moment-là qu’on pense à Database Mail. Il ne faut pas le voir comme une simple procédure, mais plutôt comme un petit sous-système avec sa propre configuration, ses droits et ses mécanismes de diagnostic. Vu sous cet angle, toute la configuration devient plus claire.

Définition du besoin

À première vue, tout semble simple : pour envoyer un e-mail depuis SQL Server, on ajoute un appel à sp_send_dbmail dans une procédure stockée, un job SQL Agent ou un traitement de service.

En pratique, pourtant, il est rare que le premier essai aboutisse directement à un e-mail reçu. L’un des symptômes les plus fréquents ressemble à ceci :

Executed as user: NT SERVICE\SQLAgent.

SQL Server blocked access to procedure 'dbo.sp_send_dbmail' of component

'Database Mail XPs' because this component is turned off...

Le problème peut se situer à plusieurs niveaux : le composant est désactivé, le profil n’a pas été créé, l’utilisateur n’a pas les droits nécessaires, ou bien l’e-mail est bien placé dans la file d’attente mais échoue ensuite côté SMTP à cause de TLS, de l’authentification ou d’une politique réseau.

Il faut donc vérifier non seulement l’appel à sp_send_dbmail, mais toute la chaîne autour.

Qu’est-ce que Database Mail et comment cela fonctionne

Dans les grandes lignes, le processus ressemble à ceci :

• Vous appelez msdb.dbo.sp_send_dbmail.
• SQL Server enregistre la demande d’envoi dans msdb.
• L’e-mail est ensuite traité par le composant Database Mail et par un processus de messagerie externe.
• Ce n’est qu’après cela que l’échange SMTP réel avec le serveur de messagerie a lieu.

Ainsi, un appel réussi à la procédure confirme que l’e-mail a été placé en file d’attente, mais ne garantit pas sa livraison. C’est un point important.

Avant de commencer la configuration, il est utile de vérifier quelques éléments de base :

• vous disposez d’un serveur SMTP qui autorise l’envoi pour le compte concerné ;
• vous connaissez l’adresse d’expéditeur, le login, le mot de passe, le port et les exigences de chiffrement ;
• le serveur SQL Server a un accès réseau à l’hôte SMTP et au port nécessaire ;
• Windows Firewall, les ACL réseau, les proxys et les pare-feu ne bloquent pas la connexion SMTP sortante ;
• vous savez sous quel login ou quel job SQL Agent sp_send_dbmail sera appelé ;
• vous n’allez pas stocker de vrais mots de passe SMTP dans le code source, les scripts de migration ou le dépôt Git.

Le dernier point paraît évident, mais c’est précisément là que la sécurité est souvent compromise. Un script de configuration avec un vrai mot de passe commité dans Git, ce n’est plus de l’automatisation : c’est un incident prêt à se produire.

Ensuite, pour envoyer un e-mail, nous allons suivre les étapes suivantes : activer le composant, créer un compte et un profil, attribuer les droits, puis faire un test.

Étape 1. Activer Database Mail XPs

Si le composant est désactivé, sp_send_dbmail ne fonctionnera pas. Il s’active de manière standard :

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'Database Mail XPs', 1;
RECONFIGURE;

Ensuite, il est utile de vérifier immédiatement l’état actuel :

EXEC sp_configure 'Database Mail XPs';

Si vous utilisez les notifications par e-mail spécifiquement depuis des jobs SQL Server Agent, après l’activation du composant il est également utile de vérifier les paramètres de l’Agent et, si nécessaire, de redémarrer le service SQL Server Agent afin qu’il prenne correctement en compte la configuration des notifications.

Étape 2. Créer un compte et un profil de messagerie

La configuration peut se faire via l’assistant dans SSMS. C’est le chemin le plus rapide et le plus simple :

• Ouvrez SSMS.
• Allez dans Management -> Database Mail.
• Lancez l’assistant de configuration.
• Créez un compte SMTP : serveur, port, login, mot de passe, adresse d’expéditeur.
• Créez un profil de messagerie et associez-le au compte.
• Si nécessaire, rendez le profil public ou attribuez-le à des utilisateurs spécifiques.

Mais vous pouvez aussi utiliser T-SQL:

EXEC msdb.dbo.sysmail_add_account_sp
@account_name = N'OperationsAccount',
@description = N'SMTP account for SQL Server notifications',
@email_address = N'sql-notify@example.com',
@display_name = N'SQL Server Notifications',
@replyto_address = N'support@example.com',
@mailserver_name = N'smtp.example.com',
@port = 587,
@enable_ssl = 1,
@username = N'sql-notify@example.com',
@password = N'<SECRET>';
GO

EXEC msdb.dbo.sysmail_add_profile_sp
@profile_name = N'OperationsProfile',
@description = N'Profile for operational SQL notifications';
GO

EXEC msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = N'OperationsProfile',
@account_name = N'OperationsAccount',
@sequence_number = 1;
GO

Si le profil doit être disponible pour tous les utilisateurs de msdb, il peut être rendu public:

EXEC msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = N'OperationsProfile',
@principal_name = N'public',
@is_default = 0;
GO

Un profil public est pratique pour un démarrage rapide. Mais si l’accès à l’envoi d’e-mails doit être restreint, il vaut mieux utiliser un profil privé et l’attribuer explicitement uniquement aux logins et utilisateurs qui en ont réellement besoin.

Si @profile_name n’est pas indiqué dans l’appel à sp_send_dbmail, SQL Server tente d’abord d’utiliser le profil privé par défaut de l’utilisateur courant, puis le profil public par défaut. C’est pratique, mais en production il est généralement préférable d’indiquer explicitement le profil dans le code afin que le comportement ne dépende pas de paramètres par défaut cachés.

Étape 3. Droits d’accès au profil

C’est un autre endroit où la confusion est fréquente. Le simple fait qu’un profil existe ne suffit pas. L’utilisateur qui appelle la procédure doit avoir le droit d’utiliser Database Mail dans msdb.

En général, on ajoute pour cela l’utilisateur au rôle DatabaseMailUserRole :

USE msdb;
GO
ALTER ROLE DatabaseMailUserRole ADD MEMBER [PlamarJobUser];
GO

Si l’e-mail est nécessaire spécifiquement pour les notifications SQL Server Agent, il est également pertinent de vérifier le profil Database Mail dans les propriétés de SQL Server Agent, dans l’onglet Alert System. Sinon, il est tout à fait possible que sp_send_dbmail fonctionne manuellement, mais que les notifications de l’Agent n’arrivent pas.

Étape 4. Envoyer un e-mail de test

Essayons ensuite d’envoyer un e-mail de test et de conserver le mailitem_id pour le diagnostic :

DECLARE @mailitem_id INT;

EXEC msdb.dbo.sp_send_dbmail
@profile_name = N'OperationsProfile',
@recipients = N'recipient@example.com',
@subject = N'SQL Server Notification',
@body = N'<h1>Database Mail works</h1><p>This is a test email from SQL Server.</p>',
@body_format = 'HTML',
@mailitem_id = @mailitem_id OUTPUT;

SELECT @mailitem_id AS mailitem_id;

Si vous avez besoin non pas simplement d’un e-mail texte, mais par exemple du résultat d’une requête SQL, sp_send_dbmail sait aussi le faire :

EXEC msdb.dbo.sp_send_dbmail
@profile_name = N'OperationsProfile',
@recipients = N'report@example.com',
@subject = N'Nightly SQL report',
@body = N'The result of the nightly query is attached.',
@query = N'SELECT TOP (10) Id, Status, CreatedAt FROM dbo.Orders ORDER BY CreatedAt DESC;',
@attach_query_result_as_file = 1,
@query_attachment_filename = N'orders.csv',
@query_result_separator = N';';

Comment vérifier que l’e-mail est réellement parti

C’est la couche pratique la plus importante. Il faut vérifier non seulement que la procédure a été appelée, mais aussi l’état du message dans msdb.

SELECT TOP (20)
mailitem_id,
sent_status,
send_request_date,
sent_date,
recipients,
subject
FROM msdb.dbo.sysmail_allitems
ORDER BY mailitem_id DESC;

Le journal Database Mail est également utile pour le diagnostic:

SELECT TOP (50)
log_date,
event_type,
description
FROM msdb.dbo.sysmail_event_log
ORDER BY log_date DESC;

Si vous vous intéressez précisément aux envois échoués, sysmail_faileditems est également pratique:

SELECT TOP (20)
mailitem_id,
subject,
recipients,
last_mod_date,
last_mod_user
FROM msdb.dbo.sysmail_faileditems
ORDER BY mailitem_id DESC;

Erreurs courantes et méthode de diagnostic

Allons du plus simple au plus complexe. Nous vérifierons d’abord si le composant est activé et si les droits existent, puis nous regarderons l’état de la file d’attente, et seulement ensuite nous passerons à SMTP, TLS et à la partie réseau.

Le composant Database Mail XPs est désactivé

C’est le cas le plus évident. C’est précisément ce qui provoque le message indiquant que Database Mail XPs est désactivé. La solution est simple : activer le composant via sp_configure, puis vérifier le résultat.

Le profil est introuvable ou inaccessible à l’utilisateur appelant

Si le profil existe mais que le login appelant n’a pas les droits nécessaires, sp_send_dbmail ne pourra pas l’utiliser. Il faut alors vérifier :

• si le profil existe ;
• s’il est public ou privé ;
• si l’utilisateur possède le rôle DatabaseMailUserRole dans msdb ;
• sous quelle identité le job SQL Agent ou la procédure s’exécute réellement.

C’est souvent le dernier point qui est décisif. Tout fonctionne manuellement sous un compte administrateur, mais plus dans le job.

L’e-mail est mis en file d’attente, mais n’est pas envoyé

C’est déjà une situation plus intéressante. Il faut alors examiner :

• l’état de Database Mail ;
• la file d’attente dans sysmail_allitems ;
• le journal sysmail_event_log ;
• si Service Broker est activé dans msdb ;
• si la file d’attente de messagerie n’est pas arrêtée.

Vous pouvez vérifier l’état ainsi :

EXEC msdb.dbo.sysmail_help_status_sp;

Si Database Mail est arrêté, vous pouvez le démarrer :

EXEC msdb.dbo.sysmail_start_sp;

Vérifier Service Broker dans msdb :

SELECT name, is_broker_enabled
FROM sys.databases
WHERE name = N'msdb';

Si is_broker_enabled = 0, il s’agit déjà d’un problème administratif distinct. Il faut le corriger avec prudence, généralement pendant une fenêtre de maintenance de la base de données.

Erreurs SMTP, d’authentification et TLS

Ici, il faut regarder la description de l’erreur dans sysmail_event_log. C’est généralement là que l’on voit ce qui s’est passé : login ou mot de passe incorrect, refus de relais, erreur de handshake TLS, impossibilité de se connecter à l’hôte ou timeout.

Erreurs liées aux pièces jointes

Si vous joignez un fichier via @file_attachments, SQL Server doit y avoir réellement accès au niveau du système de fichiers. Et ici, le contexte important est celui du service SQL Server, pas celui de la session interactive de l’administrateur. Lorsqu’un fichier « existe » localement mais que Database Mail ne le voit pas, le problème vient généralement des droits d’accès ou du chemin.


TLS 1.2 et restrictions de sécurité modernes

C’est la partie que les anciennes instructions décrivent souvent de manière trop simplifiée. Un serveur SMTP moderne exige généralement non pas simplement « un chiffrement quelconque », mais une prise en charge TLS précise, une version compatible de .NET et des paramètres système Windows corrects.

Si le serveur SMTP attend TLS 1.2, il est utile de vérifier les points suivants :

• les mises à jour Windows et SQL Server sont à jour ;
• la prise en charge de TLS 1.2 est disponible sur le serveur ;
• .NET Framework et les paramètres crypto du système ne bloquent pas le handshake nécessaire ;
• la connexion sécurisée est activée dans les paramètres Database Mail.

Un exemple typique de paramètres de registre pour activer strong crypto ressemble à ceci :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

Après modification de ces paramètres, un redémarrage du service SQL Server est généralement nécessaire, et parfois même un redémarrage complet du serveur, afin que Schannel et .NET prennent bien en compte les nouveaux paramètres.

Il y a ici trois nuances pratiques.

Premièrement, pour Database Mail, il est généralement préférable de viser le port 587 avec TLS/STARTTLS. Le port 465 est souvent mentionné dans les anciennes instructions comme une option, mais en pratique il se révèle fréquemment problématique, car Database Mail s’appuie sur la pile SMTP de .NET et fonctionne mieux dans un scénario STARTTLS que dans un scénario SMTPS implicite.

Deuxièmement, si vous utilisez Microsoft 365 ou un autre service de messagerie cloud moderne, vérifiez non seulement TLS, mais aussi le modèle d’authentification. Database Mail ne prend pas en charge les flux OAuth modernes. Si le fournisseur a désactivé l’authentification SMTP classique, l’e-mail ne partira pas, même avec un T-SQL correct. Dans ce cas, on utilise généralement soit un relais SMTP dédié, soit une boîte aux lettres pour laquelle SMTP AUTH est autorisé par la politique de l’organisation.

Troisièmement, la case SSL dans l’assistant SSMS signifie en pratique que le serveur doit prendre en charge un scénario SMTP-over-TLS correct. Il faut donc regarder non seulement l’interface, mais aussi la compatibilité réelle entre votre endpoint SMTP et Database Mail.

Limitations et pièges

• sp_send_dbmail confirme la mise en file d’attente du message, pas sa livraison dans la boîte de réception de l’utilisateur.
• Database Mail dépend de l’infrastructure SMTP, de l’accessibilité réseau, du DNS, de la politique TLS et des règles d’authentification en dehors de SQL Server.
• Il ne prend pas en charge les scénarios OAuth modernes pour la messagerie cloud ; tous les services de messagerie d’entreprise ne fonctionneront donc pas sans relais ou configuration spécifique.
• Pour les pièces jointes, les droits importants sont ceux du compte de service SQL Server, pas ceux du compte administrateur sous lequel vous avez ouvert SSMS.
• La taille des pièces jointes et la liste des extensions interdites sont limitées par les paramètres de Database Mail et peuvent bloquer de manière inattendue certains scénarios pourtant fonctionnels.
• Database Mail est disponible dans SQL Server Database Engine et Azure SQL Managed Instance, mais pas dans Azure SQL Database ni dans les elastic pools.

Conclusion

En résumé, Database Mail convient surtout aux notifications de service, aux rapports planifiés et aux envois techniques. Je ne l’utiliserais pas pour une intégration e-mail complexe avec logique métier, templating et scénarios modernes d’authentification cloud. Dans ces cas-là, il cesse très vite d’être pratique.

Liens utiles

• Documentation officielle de Database Mail
• Documentation de sp_send_dbmail
• Étapes générales de diagnostic de Database Mail