Guide d'intégration de PowerDMARC et Splunk
PowerDMARC → Accueil de la solution → Intégrations → SIEM
Grâce à l'intégration de PowerDMARC à Splunk, vous pouvez importer et surveiller vos données d'authentification des e-mails et de sécurité des domaines directement depuis votre environnement Splunk. En tirant parti de l'API PowerDMARC, les entreprises peuvent mettre en place une intégration SIEM simplifiée sans configurations complexes : il suffit de se connecter, de lancer le système et de bénéficier d'une visibilité centralisée sur leur niveau de sécurité des e-mails pour l'ensemble de leurs domaines.
Ce guide porte principalement sur la configuration et l'ingestion des données. Les tableaux de bord Splunk et les visualisations avancées ne sont pas abordés ici.
Documentation API
Documentation Swagger : https://app.powerdmarc.com/swagger-ui/index.html
Documentation alternative : https://api.powerdmarc.com/
Remarque : Les conventions de nommage (noms d'index, types de source, chemins d'accès aux fichiers) sont des suggestions et non des exigences. Adaptez-les aux normes de votre environnement.
Informations collectées par le script
Le script d'intégration extrait deux ensembles de données de l'API PowerDMARC :
Des rapports agrégés sont générés pour chaque domaine de votre compte, sur l'ensemble des conformeset « échoué »et redirigés . Les domaines sont répertoriés automatiquement via /api/v1/domains.
Présentation de l'architecture
API PowerDMARC
↓
Script Python (planifié via cron / la minuterie systemd / le Planificateur de tâches)
↓
Collecteur d'événements HTTP Splunk (HEC)
↓
Splunk (recherche, tableaux de bord, alertes, corrélation)
Splunk reçoit les données via son point de terminaison HTTP Event Collector (HEC), qui permet l'ingestion sécurisée de données provenant de sources externes.
Le script prend également en charge l'écriture de fichiers JSON délimités par des sauts de ligne à la place — ou en plus — du format HEC, pour les environnements dans lesquels les connexions HTTPS sortantes vers le port HEC de Splunk ne sont pas autorisées. Voir Alternative : ingestion via File Monitor.
Conditions préalables
Splunk Enterprise ou Splunk Cloud avec des droits d'administration
Autorisation de créer des jetons HEC, de créer des index et de configurer les sources de données
Python 3.7 ou une version ultérieure sur le système exécutant le script
Un jeton « bearer » de l'API PowerDMARC autorisant l'accès aux journaux d'audit et aux rapports agrégés
Connectivité réseau entre l'hôte du script et :
API PowerDMARC — https://app.powerdmarc.com (TCP 443)
Votre point de terminaison Splunk HEC (TCP 8088 pour Splunk Enterprise, TCP 443 pour Splunk Cloud)
Configuration Splunk
Étape 1 : Créer un index dédié
Accédez à Paramètres → Index
Cliquez sur Nouvel index
Configurer :
Nom de l'index : powerdmarc
Type de données d'index : Événements
Application : rechercher (ou votre application préférée)
Conservez les autres paramètres par défaut ou modifiez-les en fonction de vos besoins en matière de conservation des données.
Cliquez sur Sauvegarder
Étape 2 : Activer le collecteur d'événements HTTP (HEC)
Accédez à Paramètres → Entrées de données
Cliquez sur Collecteur d'événements HTTP
Cliquez sur Paramètres généraux
Configurer :
Tous les jetons : Activé
Activer SSL : Activé (recommandé)
Numéro de port HTTP : 8088 (par défaut)
Cliquez sur Sauvegarder
Clients Splunk Cloud : la fonctionnalité HEC est activée par défaut et écoute sur le port 443. Vous n'avez pas besoin de modifier les paramètres globaux, mais vous devrez peut-être envoyer une demande d'assistance pour activer HEC sur certains types de piles.
Étape 3 : Créer le jeton HEC
Toujours dans Paramètres → Entrées de données → Collecteur d'événements HTTP, cliquez sur Nouveau jeton
Configurer les paramètres du jeton :
Nom : PowerDMARC_Integration
Remplacement du nom de la source : powerdmarc:api
Description : Jeton pour l'ingestion du journal d'audit et des rapports agrégés de PowerDMARC
Cliquez Suivant
Paramètres de saisie :
Type de source : Sélectionner Automatique
Index autorisés : include powerdmarc
Index par défaut : powerdmarc
Cliquez ici « Examiner », puis « Soumettre »
Important : Copiez et enregistrez immédiatement la valeur du jeton — vous ne pourrez pas la récupérer ultérieurement.
Pourquoi le paramètre « Automatique » est important : le script définit un type de source par événement (dmarc:audit ou dmarc:aggregate) dans la charge utile HEC. Le fait de sélectionner un type de source fixe sur le jeton remplacerait ces valeurs et fusionnerait les deux ensembles de données en un seul type de source.
Configuration du script d'intégration
Étape 4 : Préparer l'environnement Python
Le script comporte une seule dépendance tierce : requests.
Option A — Installation en ligne (recommandée)
pip3 install requests
Option B — Installation hors ligne
Sur un ordinateur disposant d'un accès à Internet :
pip3 download requests -d ./packages
Transférez les paquets vers le système cible, puis :
pip3 install --no-index --find-links=./packages requests
Vérifiez l'installation :
python3 -c "import requests; print(requests.__version__)"
N'importe quelle version relativement récente (2.25 ou ultérieure) convient.
Étape 5 : Déployer le script
Créez un compte de service dédié et une structure de répertoires spécifique plutôt que d'exécuter l'intégration en tant qu'utilisateur « root » :
sudo useradd -r -s /usr/sbin/nologin dmarc
sudo mkdir -p /opt/dmarc /etc/dmarc /var/lib/dmarc /var/log/dmarc
sudo chown dmarc:dmarc /var/lib/dmarc /var/log/dmarc
sudo chmod 750 /var/lib/dmarc /var/log/dmarc
Copier dmarc_to_splunk.py à l'emplacement suivant :
sudo install -o dmarc -g dmarc -m 750 dmarc_to_splunk.py /opt/dmarc/
Étape 6 : Configurer le script
Chaque paramètre peut être défini soit en modifiant le fichier fichier de configuration dans la fonction main() ou en définissant une variable d'environnement. L'utilisation de variables d'environnement est fortement recommandée afin que les identifiants ne soient jamais stockés dans le fichier de script.
Formats d'URL des points de terminaison HEC :
Splunk Enterprise / sur site : https://your-splunk-instance:8088/services/collector/event
Splunk Cloud: https://http-inputs-<your-stack>.splunkcloud.com/services/collector/event
Splunk Cloud hostnames vary by stack age and type — some use http-inputs-<stack>.splunkcloud.com on port 443, others use a .splunkcloud.com:8088 form. Confirm yours under Settings → Data inputs → HTTP Event Collector in your Splunk Cloud console rather than assuming.
Créez le fichier d'identifiants :
sudo tee /etc/dmarc/splunk.env >/dev/null <<'EOF'
DMARC_API_KEY=votre_jeton_bearer_powerdmarc
SPLUNK_HEC_URL=https://your-splunk-instance:8088/services/collector/event
SPLUNK_HEC_TOKEN=votre_jeton_hec
SPLUNK_INDEX=powerdmarc
DMARC_DAYS_TO_FETCH=7
Fin de fichier
sudo chown root:dmarc /etc/dmarc/splunk.env
sudo chmod 640 /etc/dmarc/splunk.env
Étape 7 : Vérification de la connectivité
Le script accepte un --test qui envoie un seul événement de test à HEC puis se ferme. Cela permet de valider le jeton, l’URL, la chaîne TLS et le chemin du pare-feu sans attendre la fin d’une collecte complète :
sudo -u dmarc bash -c 'set -a; . /etc/dmarc/splunk.env; set +a; python3 /opt/dmarc/dmarc_to_splunk.py --test'
Résultat attendu :
============================================================
Intégration de PowerDMARC à Splunk
Mode de sortie : hec
============================================================
Test de la connectivité Splunk HEC...
Envoi d'un lot de 1 événement dmarc:audit (1/1)
Résumé HEC pour dmarc:audit — envoyés : 1, échecs : 0, total : 1
Vérifiez que la sonde est bien arrivée :
index=powerdmarc action="test_d'intégration_et_de_connectivité"
Étape 8 : Lancer une collecte complète
sudo -u dmarc bash -c 'set -a; . /etc/dmarc/splunk.env; set +a; python3 /opt/dmarc/dmarc_to_splunk.py'
Résultat attendu (en abrégé) :
============================================================
Intégration de PowerDMARC à Splunk
Mode de sortie : hec
============================================================
Traitement des rapports agrégés DMARC...
Récupération des rapports agrégés du 30 janvier 2026 au 6 février 2026
Récupération de tous les domaines...
Page 1 récupérée : 24 domaines (total à ce jour : 24)
24 domaines au total ont été récupérés
Progression : 1,4 % (1/72) | Domaine 1/24 : example.com | Durée estimée : il reste 4,7 min
...
Traitement de 318 événements uniques de rapports agrégés
Envoi d'un lot de 318 événements dmarc:aggregate (318/318)
Résumé HEC pour dmarc:aggregate — envoyés : 318, échecs : 0, total : 318
Traitement des journaux d'audit...
Récupération des journaux d'audit du 30 janvier 2026 au 6 février 2026
15 entrées du journal d'audit ont été récupérées au total
Traitement de 15 événements uniques du journal d'audit enregistrés au cours des 7 derniers jours
Résumé HEC pour dmarc:audit — envoyés : 15, échecs : 0, total : 15
============================================================
L'intégration s'est déroulée avec succès
============================================================
Le premier cycle sera le plus long, car il collecte l'intégralité de la fenêtre de rétrospective. Les cycles suivants ignorent tout ce qui a déjà été ingéré (voir Déduplication).
Planifier l'exécution automatisée
Linux/Unix (cron)
sudo crontab -u dmarc -e
Par heure :
0 * * * * set -a; . /etc/dmarc/splunk.env; set +a; /usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py >> /var/log/dmarc/run.log 2>&1
Le script affiche ses messages dans la sortie standard ; c'est donc la redirection ci-dessus qui permet de récupérer le journal d'exécution. Ajoutez un règle pour /var/log/dmarc/run.log en environnement de production.
Définition de l'intervalle. Le script espace ses appels API d’environ 2 secondes afin de respecter la limite de débit imposée par PowerDMARC, et il effectue trois requêtes cumulées par domaine. Une estimation approximative du temps de collecte cumulé est de domaines × 3 × 4 secondes — soit environ 5 minutes pour 25 domaines, mais près de 2 heures pour 500. Si votre compte compte plus d’une centaine de domaines, une planification horaire entraînera des chevauchements. Vous avez alors deux options :
Fractionnez la planification : lancez la collecte des journaux d'audit toutes les heures et la collecte agrégée une fois par jour, ou
Ajouter un fichier de verrouillage (flock) afin que les exécutions qui se chevauchent se terminent correctement :
0 * * * * /usr/bin/flock -n /tmp/dmarc-splunk.lock -c 'set -a; . /etc/dmarc/splunk.env; set +a; /usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py' >> /var/log/dmarc/run.log 2>&1
Linux (minuterie systemd)
Pour ce type de tâche, il est généralement préférable d'utiliser une minuterie systemd plutôt que cron : elle gère le fichier d'environnement de manière native, empêche les exécutions de se chevaucher et envoie les résultats vers le journal.
/etc/systemd/system/dmarc-splunk.service:
[Unité]
Description=Intégration de PowerDMARC dans Splunk
After=network-online.target
[Service]
Type=oneshot
Utilisateur=dmarc
Groupe=dmarc
EnvironmentFile=/etc/dmarc/splunk.env
ExecStart=/usr/bin/python3 /opt/dmarc/dmarc_to_splunk.py
/etc/systemd/system/dmarc-splunk.timer:
[Unité]
Description=Exécuter l'importation de données de PowerDMARC vers Splunk toutes les heures
[Minuterie]
OnCalendar=hourly
Persistent=true
[Installer]
WantedBy=timers.target
Activer cette option :
sudo systemctl daemon-reload
sudo systemctl enable --now dmarc-splunk.timer
sudo systemctl list-timers dmarc-splunk.timer
journalctl -u dmarc-splunk.service -f
Windows (Planificateur de tâches)
Ouvrir le Planificateur de tâches et cliquez sur Créer une tâche
Onglet « Général » :
Nom : Intégration PowerDMARC Splunk
Options de sécurité : Exécuter que l'utilisateur soit connecté ou non
Onglet « Déclencheurs » : Nouveau → Début : selon un calendrier → Quotidien, répétition toutes les 1 heure
Onglet « Actions » : Nouveau → Lancer un programme
Programme : python.exe
Arguments : C:\dmarc\dmarc_to_splunk.py
Cliquez OK
Sous Windows, définissez les valeurs de configuration dans le fichier dictionnaire ou définissez les variables d'environnement au niveau de la machine, puis modifiez le output_dir / state_file par des chemins Windows tels que C:\dmarc\logs et C:\dmarc\state\state.json.
Valider l'ingestion des données dans Splunk
Journaux d'audit
index=powerdmarc sourcetype=dmarc:audit
| trier - _time
| rubrique 20
| table _time, user_name, action, ip_address, admin_username
Champs qui devraient s'afficher :
nom_utilisateur — utilisateur ayant effectué l'action
action — description de l'action effectuée
adresse_IP — Adresse IP de l'utilisateur
nom_d'utilisateur_admin — compte administrateur, le cas échéant
horodatage — heure de l’événement PowerDMARC d’origine
Rapports agrégés
index=powerdmarc sourcetype=dmarc:aggregate
| stats sum(email_volume) sous le nom « volume », avg(dmarc_pass_percentage) sous le nom « avg_pass » par domain_name
| trier - volume
Les événements agrégés fournissent les nombres et les pourcentages, par domaine et par source d'envoi, pour les protocoles DMARC, SPF et DKIM, ainsi que la politique effectivement appliquée.
Exemples de structures d'événements
dmarc:audit
{
« sourcetype »: « dmarc:audit »,
« horodatage »: « 04/02/2026 14:29:24 »,
« user_name »: « John Doe »,
« action »: « Mise à jour des domaines associés »,
« ip_address »: « 12.111.67.123 »,
« admin_username »: « N/A »,
« other_info »: « N/A »
}
dmarc:agrégé (abrégé)
{
« sourcetype »: « dmarc:aggregate »,
« horodatage »: « 06/02/2026 »,
« report_date_from »: « 30/01/2026 »,
« date_de_déclaration »: « 06/02/2026 »,
« domain_id »: 1234,
« nom_de_domaine »: « example.com »,
« sending_source »: « Google »,
« statut »: « conforme »,
« volume_d'e-mails »: 4821,
« dmarc_pass_count »: 4810,
« dmarc_pass_percentage »: 99,77,
« spf_align_percentage »: 99,77,
« dkim_align_percentage »: 100.0
}
Horodatages des événements
Le script définit le HEC champ « time » à partir de l'horodatage propre à chaque événement, lorsqu'il est en mesure de l'analyser, de sorte que _time reflète le moment où l’événement s’est produit plutôt que celui de son ingestion. Cela est important lors de la première exécution : sans cela, un remplissage rétrospectif de sept jours se retrouverait entièrement dans la minute en cours et apparaîtrait de manière erronée dans tous les graphiques de séries chronologiques.
Déduplication
Le script gère un fichier d'état (par défaut /var/lib/dmarc/state.json) contenant les empreintes SHA-256 de chaque événement déjà traité. À chaque exécution, les événements correspondant à une empreinte déjà enregistrée sont ignorés. Les empreintes datant de plus de 14 jours sont automatiquement supprimées afin d’éviter que le fichier ne grossisse indéfiniment.
Les empreintes digitales ne sont enregistrées une fois que réussite de la livraison ; ainsi, un POST HEC ayant échoué rend ces événements éligibles à une nouvelle tentative lors de la prochaine exécution, plutôt que de les ignorer sans avertissement.
Deux conséquences opérationnelles :
Le fichier d'état doit être conservé d'une exécution à l'autre et après les redémarrages. Ne le placez pas dans /tmp ni dans une couche de conteneur qui sera supprimée.
La suppression du fichier d'état entraîne la réimportation de l'intégralité de la fenêtre de rétrospective lors de la prochaine exécution. C'est la bonne méthode pour forcer un remplissage rétroactif, mais attendez-vous à des doublons dans Splunk si les données s'y trouvent déjà.
Autre option : Importation via File Monitor
Si l'accès sortant au port HEC n'est pas disponible, définissez DMARC_OUTPUT_MODE=file (ou les deux). Le script écrit des données JSON délimitées par des sauts de ligne dans output_dir, à raison d’un fichier par exécution et par ensemble de données :
/var/log/dmarc/dmarc_aggregate_20260206_140312.json
/var/log/dmarc/audit_logs_20260206_140312.json
Configurez un forwarder Splunk pour surveiller ce répertoire. Dans $SPLUNK_HOME/etc/system/local/inputs.conf:
[monitor:///var/log/dmarc/dmarc_aggregate_*.json]
désactivé = faux
index = powerdmarc
sourcetype = dmarc:aggregate
[monitor:///var/log/dmarc/audit_logs_*.json]
désactivé = faux
index = powerdmarc
sourcetype = dmarc:audit
Et dans props.conf, afin que les événements soient répartis sur chaque ligne et horodatés correctement :
[dmarc:aggregate]
INDEXED_EXTRACTIONS = json
KV_MODE = none
SHOULD_LINEMERGE = false
TIME_PREFIX = "report_date_to":\s*"
TIME_FORMAT = %Y-%m-%d
[dmarc:audit]
INDEXED_EXTRACTIONS = json
KV_MODE = none
SHOULD_LINEMERGE = false
TIME_PREFIX = "timestamp":\s*"
TIME_FORMAT = %Y-%m-%d %H:%M:%S
L'utilisateur Splunk doit disposer d'un accès en lecture au répertoire — ajoutez-le au fichier groupe dmarc , ou assouplissez le mode du répertoire en le définissant sur 0755. Créez une tâche de nettoyage (find /var/log/dmarc -name '*.json' -mtime +7 -delete) afin d'éviter l'accumulation d'anciens fichiers de sortie.
Dépannage
Aucune donnée n'apparaît dans Splunk
Exécuter avec --test pour déterminer si le problème provient de HEC ou de PowerDMARC
Vérifiez que le jeton HEC est correct et activé (Paramètres → Entrées de données → Collecteur d'événements HTTP)
Vérifiez que les index autorisés pour le jeton incluent powerdmarc
Vérifiez que l'index existe et que votre rôle dispose des droits d'accès nécessaires pour effectuer une recherche dans celui-ci
Vérifiez que les règles du pare-feu autorisent les connexions HTTPS sortantes depuis l'hôte du script vers le point de terminaison HEC.
Consultez le journal d'exécution de HEC a renvoyé HTTP … — le corps de l’erreur de Splunk indique le problème spécifique
Code HTTP 403 « Jeton non valide » de la part de HEC
The token value is wrong, disabled, or belongs to a different Splunk stack. Note that the header format is Authorization: Splunk <token> — not Bearer.
HTTP 400 « Index incorrect »
Le jeton n'autorise pas l'index ciblé par le script. Veuillez ajouter powerdmarc à la liste des index autorisés du jeton, ou modifiez SPLUNK_INDEX par un index déjà autorisé par le jeton.
Erreurs liées aux certificats SSL
Installez un certificat reconnu par l'hôte du script : c'est la solution appropriée. À titre de mesure temporaire, et uniquement dans les environnements hors production, définissez SPLUNK_VERIFY_SSL=false. Ne procédez jamais ainsi en production ; cela désactive la protection qui donne tout son sens à HEC sur TLS.
Échecs d'authentification de l'API PowerDMARC
Vérifiez que le jeton API est valide et qu'il n'a pas expiré
Vérifiez que le jeton dispose des autorisations nécessaires pour accéder à la fois aux journaux d'audit et aux rapports agrégés.
Vérifiez que l'URL de base de l'API est accessible depuis l'hôte
Le script s'exécute, mais aucun journal n'a été récupéré
Vérifiez si des journaux d'audit existent effectivement pour la période considérée.
Augmenter DMARC_DAYS_TO_FETCH temporairement
N'oubliez pas que la déduplication supprime les événements déjà importés — un rapport d'exécution « 0 événement unique de journal d’audit traité » après une exécution précédente réussie est normal et ne constitue pas une erreur
Autorisation refusée au démarrage
Le compte de service ne peut pas créer de fichiers ni écrire dans /var/lib/dmarc ni /var/log/dmarc. Créez au préalable ces deux répertoires, puis attribuez-leur au compte sous lequel le script s'exécute, comme indiqué à l'étape 5.
L'exécution dure plus longtemps que l'intervalle prévu
Consultez les remarques concernant les tailles dans la rubrique Planifier l'exécution automatisée. Ajoutez flock ou divisez le calendrier de collecte.
Prochaines étapes
Grâce à ce flux de données, vous pouvez :
Créer des tableaux de bord personnalisés pour suivre l'évolution de la conformité DMARC par domaine et par source d'envoi
Alertes concernant les événements d'audit, tels que les modifications de politiques ou les connexions provenant de plages d'adresses IP inattendues
Alerte concernant les baisses de conformité — une source d'envoi dont le dmarc_pass_percentage baisse fortement d'une semaine à l'autre
Mettre en corrélation les données PowerDMARC avec d'autres journaux de sécurité (passerelle de messagerie, identité, EDR)
Créer des rapports de conformité et des rapports destinés à la direction à partir de l'ensemble de données agrégées
Améliorations recommandées
Points de terminaison API supplémentaires : étendez le script pour récupérer des rapports d'analyse ou des données de configuration par domaine
Rotation des fichiers journaux : ajoutez un fichier règle logrotate pour le journal d'exécution du script en production
Notifications d'échec : encadrez le script dans un appel qui déclenche une alerte en cas de code de sortie différent de zéro, ou déclenchez une alerte dans Splunk en cas d'absence du volume d'événements horaire attendu
Intégrer sous forme de module complémentaire technologique Splunk (TA) : regroupez les entrées, les propriétés et la configuration au moment de l'indexation sous la forme d'un module complémentaire technologique afin de faciliter la distribution
Gestion des secrets : remplacer le fichier d'environnement par un gestionnaire de secrets (Vault, AWS Secrets Manager, systemd credentials) lorsqu'un tel gestionnaire est disponible
Considérations relatives à la sécurité
Enregistrez les identifiants en dehors du script. Utilisez le fichier d'environnement (mode 640, appartenant à root:dmarc) ou un gestionnaire de secrets. Ne commitez jamais les jetons dans le système de contrôle de version.
Veillez à ce que la vérification TLS reste activée. SPLUNK_VERIFY_SSL est défini par défaut sur true par défaut pour une bonne raison.
Exécuter sous un compte dédié sans privilèges. L'intégration ne nécessite pas de droits root.
Limiter l'utilisation du jeton HEC. Limitez-le à la index .
Remplacer les deux jetons selon un calendrier défini — le jeton de porteur PowerDMARC et le jeton HEC de Splunk.
Surveiller l'exécution. Générer des alertes en cas d'échecs d'exécution et de lacunes inattendues dans l'ingestion.
Vérifiez les contrôles d'accès à Splunk. Les données du journal d'audit identifient les utilisateurs et les adresses IP sources ; limitez l'accès à l'index aux rôles qui en ont besoin.
Assistance et ressources
Documentation de l'API PowerDMARC : https://api.powerdmarc.com/
Documentation Splunk HEC : https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector
Splunk Answers : https://community.splunk.com/