Ai-je besoin d’une clé API botoi pour ce flux de travail ?

Non. L’offre gratuite autorise 5 requêtes par minute sans clé API. Le workflow effectue 3 requêtes par exécution (SPF, DMARC, DKIM), ce qui correspond à la limite. Si vous effectuez des vérifications sur plusieurs domaines ou sélecteurs, ajoutez votre clé API en tant que secret GitHub et transmettez-la dans l'en-tête Autorisation.

Puis-je vérifier plusieurs domaines en une seule exécution de workflow ?

Oui. Parcourez un tableau de domaines dans le script de vérification. Chaque domaine nécessite 3 appels d'API, donc une exécution gratuite gère un domaine par appel. Pour plusieurs domaines, ajoutez une clé API botoi pour éviter toute limitation de débit.

Quel sélecteur DKIM dois-je utiliser ?

Le sélecteur dépend de votre fournisseur de messagerie. Google Workspace utilise « google », Microsoft 365 utilise « selector1 » et « selector2 », Amazon SES utilise un sélecteur basé sur l'UUID. Vérifiez vos enregistrements DNS TXT pour les entrées correspondant au modèle [selector]._domainkey.yourdomain.com.

Ce workflow bloquera-t-il mes déploiements ?

Uniquement si une vérification échoue, ce qui signifie que vos enregistrements de sécurité de messagerie sont manquants ou mal configurés. C’est là le point : vous voulez détecter ces problèmes avant qu’ils ne causent des problèmes de délivrabilité. Vous pouvez modifier le flux de travail pour publier un avertissement au lieu d'échouer en remplaçant « sortie 1 » par une étape qui crée un problème GitHub ou envoie un message Slack.

À quelle fréquence dois-je effectuer cette vérification ?

À chaque poussée vers votre branche principale se trouve la ligne de base. Ajoutez un déclencheur cron programmé (par exemple, tous les jours à 9 heures du matin) pour détecter les modifications DNS effectuées en dehors de votre dépôt, par exemple lorsqu'un coéquipier modifie des enregistrements dans le tableau de bord du registraire.

Integration

Auditez la sécurité de la messagerie de votre domaine à chaque poussée avec GitHub Actions

26 mars 2026 | 7 min read

Une action GitHub qui vérifie les enregistrements SPF, DMARC et DKIM à l'aide de l'API botoi et échoue à la construction si un enregistrement est manquant ou mal configuré.

GitHub Actions workflow running in a terminal — Photo by Roman Synkevych on Unsplash

Un membre de votre équipe met à jour un enregistrement DNS. Une entrée TXT est supprimée lors d'une migration de fournisseur. Votre enregistrement SPF dépasse silencieusement la limite de 10 recherches. Les e-mails commencent à atterrir dans le spam. Personne préavis pendant deux semaines jusqu'à ce qu'un client mentionne qu'il n'a jamais reçu votre facture.

Les enregistrements de sécurité de messagerie basés sur DNS (SPF, DMARC, DKIM) constituent le type d'infrastructure qui fonctionne parfaitement jusqu'à ce que ce ne soit plus le cas. Lorsqu'il se brise, le mode panne est silencieux : pas d'erreur, aucune alerte, les e-mails disparaissent dans les dossiers spam.

Ce guide configure une action GitHub qui valide les trois enregistrements à chaque poussée. Si tout enregistrement est manquant ou mal configuré, le flux de travail échoue et vous indique ce qui s'est cassé.

Ce que fait le flux de travail

À chaque poussée vers main, l'action :

Appelle le botoi /v1/dns-security/spf-check point final pour valider votre enregistrement SPF
Appels /v1/dns-security/dmarc-check pour valider votre politique DMARC
Appels /v1/dns-security/dkim-check pour vérifier que votre clé DKIM est publiée
Quitte avec un code différent de zéro si une vérification échoue, bloquant la fusion

Le flux de travail des actions GitHub

Créer .github/workflows/dns-security.yml dans votre dépôt :

Remplacer yourdomain.com avec votre domaine et google avec le sélecteur DKIM de votre fournisseur de messagerie. Le flux de travail s'exécute à chaque poussée vers main, selon un planning quotidien et peut être déclenché manuellement à partir de l'onglet Actions.

Ce que chaque chèque valide

SPF (cadre de politique de l'expéditeur)

SPF déclare quels serveurs de messagerie sont autorisés à envoyer des e-mails pour votre domaine. L'API renvoie l'enregistrement brut, une liste analysée de mécanismes et indique si l'enregistrement est valide.

Domaines clés à surveiller :

has_spf: Existe-t-il un enregistrement TXT commençant par v=spf1? Si faux, n’importe quel serveur peut prétendre envoyer des e-mails depuis votre domaine.
valid: L'enregistrement est-il analysé correctement ? Les records SPF sont battus lorsqu'ils dépasser la limite de 10 recherches DNS ou contenir des erreurs de syntaxe.
all_policy: Le mécanisme de suivi. -all (échec difficile) est le réglage le plus fort. ~all (échec logiciel) marque le courrier non autorisé comme suspect. +all va complètement à l’encontre de l’objectif du SPF.

Exemple de réponse API pour un enregistrement SPF sain :

DMARC (authentification, reporting et conformité des messages basés sur le domaine)

DMARC indique aux serveurs de réception quoi faire lorsque les vérifications SPF ou DKIM échouent. Sans cela, même les enregistrements SPF et DKIM valides n'empêchent pas l'usurpation d'identité.

Domaines clés à surveiller :

policy: Qu'arrive-t-il aux messages ayant échoué. reject gouttes eux, quarantine les envoie au spam, none ne prend aucune mesure (surveillance uniquement).
pct: le pourcentage de messages auxquels la stratégie s'applique. Commencez à un niveau bas nombre lors du déploiement, puis passez à 100.
reporting.rua: Où les rapports agrégés sont envoyés. Sans cela, vous n'ont aucune visibilité sur les échecs d'authentification.

Exemple de réponse API pour un enregistrement DMARC :

DKIM (courrier identifié par DomainKeys)

DKIM ajoute une signature cryptographique aux messages sortants. Les serveurs de réception vérifient le signature contre une clé publique publiée dans votre DNS. Si la clé est manquante ou tournée sans mettre à jour le DNS, la vérification de la signature échoue.

Domaines clés à surveiller :

has_dkim: Une clé DKIM est-elle publiée pour le sélecteur donné ? Chaque e-mail Le fournisseur utilise un nom de sélecteur différent.
public_key_length: Le NIST recommande 2048 bits minimum. Clés plus courtes plus de 1024 bits sont considérés comme faibles.
key_type: La plupart des clés utilisent RSA. Les touches Ed25519 sont plus petites et plus rapides mais ont un support limité parmi les fournisseurs de messagerie.

Exemple de réponse API pour une vérification DKIM :

Sélecteurs DKIM courants par fournisseur

Fournisseur de messagerie	Sélecteur(s) DKIM
Espace de travail Google	`google`
Microsoft 365	`selector1`, `selector2`
AmazonSES	Basé sur l'UUID (vérifiez votre tableau de bord SES)
MailChimp / Mandrill	`k1`
EnvoyerGrille	`s1`, `s2`
Cachet de la poste	Généré par domaine (vérifiez les paramètres DNS)

Extension du flux de travail

Plusieurs domaines

Si vous gérez plusieurs domaines, utilisez une stratégie matricielle pour vérifier chacun d'entre eux. Ajouter un botoi Clé API en tant que secret GitHub pour éviter d'atteindre la limite de débit de l'offre gratuite.

Notifications Slack en cas d'échec

Ajoutez une étape de notification qui se déclenche lorsqu'une vérification échoue. Cela utilise le Action officielle Slack GitHub:

Configuration du monorepo

Dans un monorepo, vous ne souhaitez probablement pas que les vérifications DNS soient exécutées à chaque poussée vers chaque paquet. Étendez le déclencheur aux modifications apportées aux fichiers liés à l'infrastructure :

Le déclencheur planifié s'exécute toujours quotidiennement, quels que soient les filtres de chemin, vous capturez donc DNS modifications apportées en dehors du référentiel.

Utiliser une clé API pour des limites de débit plus élevées

Si vous vérifiez plusieurs domaines ou exécutez le workflow fréquemment, ajoutez votre clé API botoi en tant que secret GitHub Actions :

Accédez aux paramètres > de votre dépôt. Secrets et variables > Actes
Ajoutez un secret nommé BOTOI_API_KEY
Ajoutez l'en-tête auth à chaque commande curl :

Que faire en cas d'échec des contrôles

Enregistrement SPF manquant : Ajoutez un enregistrement TXT au DNS de votre domaine. Commencez par v=spf1 include:_spf.google.com ~all (remplacez l'inclusion par votre domaine SPF du fournisseur de messagerie).
Enregistrement SPF invalide : Vous avez probablement atteint la limite de 10 recherches DNS. Utilisez un Outil d'aplatissement SPF à remplacer include: mécanismes avec adresses IP, ou regrouper des prestataires.
Enregistrement DMARC manquant : Ajoutez un enregistrement TXT à _dmarc.yourdomain.com. Commencez par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com surveiller avant d'appliquer.
La politique DMARC est « aucune » : C'est très bien pendant le déploiement. Une fois que vous aurez confirmé les e-mails légitimes passent SPF et DKIM, passez à p=quarantine et puis p=reject.
Enregistrement DKIM manquant : Vérifiez que vous disposez du bon sélecteur pour votre fournisseur de messagerie (voir le tableau ci-dessus). La clé doit être publiée sous forme d'enregistrement TXT à [selector]._domainkey.yourdomain.com.
Clé DKIM trop courte : Faites pivoter votre clé DKIM à 2048 bits via votre Panneau d'administration du fournisseur de messagerie, puis mettez à jour l'enregistrement DNS TXT.

FAQ

Ai-je besoin d’une clé API botoi pour ce flux de travail ?: Non. L’offre gratuite autorise 5 requêtes par minute sans clé API. Le workflow effectue 3 requêtes par exécution (SPF, DMARC, DKIM), ce qui correspond à la limite. Si vous effectuez des vérifications sur plusieurs domaines ou sélecteurs, ajoutez votre clé API en tant que secret GitHub et transmettez-la dans l'en-tête Autorisation.
Puis-je vérifier plusieurs domaines en une seule exécution de workflow ?: Oui. Parcourez un tableau de domaines dans le script de vérification. Chaque domaine nécessite 3 appels d'API, donc une exécution gratuite gère un domaine par appel. Pour plusieurs domaines, ajoutez une clé API botoi pour éviter toute limitation de débit.
Quel sélecteur DKIM dois-je utiliser ?: Le sélecteur dépend de votre fournisseur de messagerie. Google Workspace utilise « google », Microsoft 365 utilise « selector1 » et « selector2 », Amazon SES utilise un sélecteur basé sur l'UUID. Vérifiez vos enregistrements DNS TXT pour les entrées correspondant au modèle [selector]._domainkey.yourdomain.com.
Ce workflow bloquera-t-il mes déploiements ?: Uniquement si une vérification échoue, ce qui signifie que vos enregistrements de sécurité de messagerie sont manquants ou mal configurés. C’est là le point : vous voulez détecter ces problèmes avant qu’ils ne causent des problèmes de délivrabilité. Vous pouvez modifier le flux de travail pour publier un avertissement au lieu d'échouer en remplaçant « sortie 1 » par une étape qui crée un problème GitHub ou envoie un message Slack.
À quelle fréquence dois-je effectuer cette vérification ?: À chaque poussée vers votre branche principale se trouve la ligne de base. Ajoutez un déclencheur cron programmé (par exemple, tous les jours à 9 heures du matin) pour détecter les modifications DNS effectuées en dehors de votre dépôt, par exemple lorsqu'un coéquipier modifie des enregistrements dans le tableau de bord du registraire.

Commencez a construire avec botoi

150+ endpoints API pour la recherche, le traitement de texte, la generation d'images et les utilitaires pour developpeurs. Offre gratuite, sans carte bancaire.

Voir la documentation API Voir tous les outils