Dernière mise à jour : juillet 2026
En bref : après ce guide, chacun de tes domaines Mailcow publie un enregistrement SPF correct — et les prérequis d’accompagnement (PTR, IPv6) sont eux aussi en place.
Prérequis
- Un serveur Mailcow en fonctionnement avec un
MAILCOW_HOSTNAMEfixe (par ex.mail.example.com) - L’accès à la gestion DNS de ton (tes) domaine(s)
- L’accès à la gestion PTR de ton fournisseur de serveur
Qu’est-ce que SPF ?
SPF (Sender Policy Framework) est un enregistrement TXT dans le DNS de ton domaine. Il liste les serveurs de messagerie autorisés à envoyer des e-mails avec ton domaine comme expéditeur. En auto-hébergement, tu es responsable des deux côtés : ton Mailcow vérifie le SPF entrant des autres domaines — et tes propres domaines ont besoin d’enregistrements propres pour que Gmail, Outlook & co. acceptent tes e-mails.
Pour situer les choses : SPF seul n’est pas une protection complète. Ce n’est qu’associé à DKIM et DMARC qu’il devient une base solide — la documentation de Mailcow recommande les trois.
Le point de départ chez Mailcow
Mailcow ne définit lui-même aucun enregistrement DNS — il ne le peut pas, puisque ta zone DNS se trouve chez ton fournisseur de domaine/DNS. Mais la documentation de Mailcow définit précisément ce qu’elle attend. L’enregistrement SPF recommandé :
v=spf1 mx a -allCela signifie que seul ce serveur (le MX de ton domaine) peut envoyer — tout le reste est rejeté fermement. Pour un serveur auto-hébergé, c’est exactement ce qu’il faut : tu connais tes chemins d’envoi.
Important : chaque domaine que tu crées dans Mailcow a besoin de son propre jeu d’enregistrements — MX plus SPF, pas seulement le domaine principal.
Guide étape par étape
1. Vérifier les enregistrements PTR (le prérequis sous-estimé)
Avant même que SPF soit utile : le PTR de l’IP de ton serveur doit correspondre au MAILCOW_HOSTNAME — la documentation de Mailcow place cela en tête des exigences DNS. Tu définis le PTR chez le fournisseur dont provient l’IP (Hetzner, Netcup, …). Et : séparément pour IPv4 et IPv6, si ton serveur envoie sur les deux.
dig -x 203.0.113.25 +short # doit renvoyer mail.example.com.2. Vérifier si SPF est déjà actif
dig TXT example.com +short | grep spf1Autre possibilité : entre ton domaine dans le scanner MXAudit gratuit — il vérifie SPF et la correspondance PTR de tes IP MX en une seule fois.
3. Définir l’enregistrement SPF chez ton fournisseur DNS
Pour chaque domaine Mailcow, crée un enregistrement TXT sur le domaine principal (@) :
v=spf1 mx a -allmx autorise les serveurs derrière tes enregistrements MX (c’est-à-dire ton Mailcow), a en plus l’IP derrière l’enregistrement A/AAAA propre au domaine. L’endroit exact où saisir l’enregistrement dépend du fournisseur DNS — voir nos guides pour IONOS, Strato, All-Inkl, Netcup et Hetzner DNS.
4. Ajouter des expéditeurs supplémentaires (si nécessaire)
Si un service de newsletter envoie aussi pour le domaine à côté de Mailcow, son include va dans le même enregistrement :
v=spf1 mx a include:spf.newsletter-dienst.de -allPar domaine, la règle tient : un seul enregistrement SPF. Deux entrées TXT avec v=spf1 provoquent un permerror.
5. Faire DKIM en même temps
La documentation de Mailcow recommande vivement de générer une clé DKIM dans l’interface Mailcow et de définir l’enregistrement TXT correspondant dans le DNS. SPF authentifie le serveur, DKIM signe le message — avec DMARC, cela devient une configuration complète.
6. Attendre que la modification soit en ligne
Les modifications DNS prennent du temps : selon le TTL et la mise en cache, il peut s’écouler quelques heures avant que chaque serveur dans le monde voie le nouvel enregistrement.
Les composants en détail
| Composant | Signification |
|---|---|
v=spf1 | identifiant de version, toujours au début |
mx | autorise les serveurs derrière les enregistrements MX — ton Mailcow |
a | autorise en plus l’IP derrière l’enregistrement A/AAAA du domaine |
-all | hardfail : tout le reste est rejeté — le bon choix quand les chemins d’envoi sont connus |
Vérifier le résultat
Vérifie ta configuration avec le scanner MXAudit gratuit — il montre d’un coup d’œil la syntaxe SPF, la consommation de lookups et la correspondance PTR de tes IP MX.
Ou directement dans le terminal :
dig TXT example.com +short | grep spf1La sortie doit contenir exactement un enregistrement avec v=spf1.
Erreurs fréquentes
PTR manquant ou pointant ailleurs. Le classique de l’auto-hébergement : SPF est juste, mais le DNS inverse de l’IP du serveur ne correspond pas au nom d’hôte — beaucoup de destinataires rejettent sur cette seule base. Corrige le PTR chez le fournisseur de l’IP.
IPv6 oubliée. Si ton serveur envoie sur IPv6, l’adresse IPv6 a aussi besoin d’un PTR — et les enregistrements AAAA doivent correspondre à ton enregistrement. Sinon, ce sont précisément ces livraisons qui échouent chez les destinataires modernes qui préfèrent IPv6.
Seul le domaine principal est pris en charge. Chaque domaine créé dans Mailcow a besoin d’enregistrements MX et SPF. Un second domaine oublié envoie sinon sans protection.
Deux enregistrements SPF. Deux entrées TXT avec v=spf1 provoquent un permerror — toutes les sources doivent tenir dans un seul enregistrement.
+all à la fin. Un +all autorise n’importe quel serveur à envoyer et rend tout l’enregistrement inutile — ne le copie pas.
Le transfert échoue. Si un destinataire fait suivre automatiquement ton e-mail, SPF échoue souvent chez le destinataire final — le serveur de transfert ne figure pas dans ton enregistrement. En auto-hébergement, tu peux activer SRS côté transfert ; en tant qu’expéditeur, DKIM et DMARC couvrent le cas.
Pour aller plus loin
- Docs Mailcow : configuration DNS (consulté le 10 juillet 2026)
- RFC 7208 — Sender Policy Framework (SPF)