SPF, DKIM et DMARC réglés depuis le panneau de l'hébergeur
Ou : trois lignes de texte dans une zone DNS, et c’est la troisième qu’on oublie.
La réponse courte : SPF, DKIM et DMARC sont trois enregistrements de la zone DNS de votre domaine, et la plupart des panneaux d’hébergeur posent les deux premiers sans qu’on le leur demande. Chez o2switch, la FAQ sur l’authentification des e-mails précise que SPF et DKIM sont activés par défaut sur l’hébergement, dans l’outil « Authentification » du cPanel. Infomaniak installe v=spf1 include:spf.infomaniak.ch -all à la création d’un Service Mail et active DKIM quand la zone DNS est chez lui. Plesk signe en DKIM après une case à cocher et place un SPF dans son modèle de zone. DMARC, lui, reste souvent à écrire. Ces réglages font partie de ce qu’il faut savoir pour un mail à son nom de domaine qui arrive à destination.
Le vrai travail commence avec le deuxième expéditeur : la newsletter, le logiciel de facturation, le formulaire du site. Chacun doit entrer dans le même enregistrement SPF, car un domaine qui en publie deux obtient une erreur permanente, et le tout ne doit pas dépasser dix requêtes DNS, limite fixée par la norme SPF.
Pour qui : une petite structure qui veut des adresses dont SPF et DKIM sont posés d’office, avec un outil pour suivre DMARC.
À partir de : 1,50 € par mois hors TVA pour une à cinq adresses avec l’hébergement mail Infomaniak, au même montant en paiement mensuel ou annuel (tarif affiché le 12 novembre 2026).
Pour démarrer : commander l’hébergement mail Infomaniak avec la zone DNS du domaine chez Infomaniak, laisser SPF et DKIM se poser, puis écrire la politique DMARC.
Configurer SPF, DKIM et DMARC sur son domaine, panneau par panneau
| Panneau | SPF | DKIM | DMARC |
|---|---|---|---|
| cPanel chez o2switch | activé par défaut ; outil « Authentification », Gérer puis Personnaliser pour ajouter un include | activé par défaut, à activer ou désactiver seulement ; clé personnalisée par l’éditeur de zone | non traité par la FAQ : un TXT _dmarc à créer dans l’éditeur de zone |
| Manager Infomaniak | include:spf.infomaniak.ch -all posé à la création du Service Mail ; tous les includes dans un seul TXT | actif par défaut si la zone est chez Infomaniak ; sinon, l’enregistrement fourni à recopier chez l’hébergeur DNS | outil de sécurité globale, ou TXT _dmarc dans la zone |
| Plesk | TXT du modèle de zone DNS, modifiable dans les paramètres DNS du domaine | case « Use DKIM spam protection system to sign outgoing email messages » dans les paramètres de messagerie ; zone externe : deux enregistrements à copier | _dmarc en v=DMARC1; p=none par défaut, selon la documentation de Plesk |
Documentation officielle lue le 12 novembre 2026.
Le deuxième expéditeur, et le dixième
La RFC 7208, qui définit SPF, compte comme une requête DNS chaque mécanisme include, a, mx, ptr et exists, ainsi que le modificateur redirect, y compris ceux que contiennent les includes eux-mêmes. Au-delà de dix, le résultat est permerror : SPF échoue pour tous les messages du domaine, pas seulement pour celui qui a ajouté sa ligne.
Le compte se fait vite. Relevé le 12 novembre 2026 par requêtes DNS :
| Include | Requêtes DNS consommées |
|---|---|
_spf.google.com (Google Workspace) | 1 |
spf.protection.outlook.com (Microsoft 365) | 1 |
spf.infomaniak.ch (Infomaniak) | 3, car il inclut un domaine de newsletter qui en inclut un autre |
mx.ovh.com (mail des hébergements OVHcloud) | 3, dont deux mécanismes ptr |
mailgun.org (service d’envoi Mailgun) | 5 |
Des boîtes chez Infomaniak (3), une newsletter via Mailgun (5), les mécanismes a et mx laissés par habitude (2) et un logiciel de facturation qui réclame son propre include (au moins 1) : onze requêtes. Le SPF casse le jour où la dernière ligne s’ajoute, sans message d’erreur visible pour l’expéditeur.
| |
Trois parades évitent le dépassement. Retirer les includes des services abandonnés, qui traînent dans presque toutes les zones. Envoyer la newsletter et la facturation depuis un sous-domaine, qui a son propre SPF et ses propres dix requêtes. Et compter sur DKIM : DMARC passe dès qu’une des deux méthodes est valide et alignée sur le domaine de l’adresse d’expédition, et un service d’envoi bien configuré signe en DKIM avec votre domaine.
DMARC se pose ensuite en trois temps : p=none avec une adresse rua= pour recevoir les rapports, p=quarantine quand les rapports ne montrent plus d’expéditeur légitime en échec, p=reject enfin. Depuis mai 2026, la RFC 9989 remplace la RFC 7489 : elle abandonne le paramètre pct, encore présent dans bien des exemples, au profit d’un mode test t=y, et les enregistrements commencent toujours par v=DMARC1.
Quand le formulaire du site signe au nom du visiteur
Un formulaire de contact qui envoie un message « de la part de » l’adresse du visiteur échoue à SPF comme à DKIM pour le domaine de ce visiteur, et DMARC fait le reste. C’est l’une des causes les plus fréquentes de messages perdus, avec d’autres que recense le diagnostic des mails en spam.
Le cas de la suite bureautique
Google Workspace et Microsoft 365 ajoutent leur include et leurs clés DKIM, cette fois en CNAME chez Microsoft. Les enregistrements exacts et l’ordre des opérations, le site restant chez son hébergeur, sont décrits pour brancher son domaine sur Microsoft 365.
Une redirection qui casse SPF
Faire suivre le courrier d’une adresse vers une messagerie gratuite revient à le renvoyer depuis un serveur que le domaine de l’expéditeur n’a jamais autorisé. La parade s’appelle SRS, et elle n’est pas proposée partout ; elle est expliquée avec les redirections et la réécriture d’expéditeur.