La configuration DMARC fait partie de l'entretien d'une messagerie avec son domaine. Elle permet de demander un traitement des messages sans authentification alignée et d'observer des échecs, sans empêcher à elle seule toute usurpation, tout spam ou toute alerte Gmail.
Elle compte pour une boîte comme pour plusieurs domaines clients. Pour revoir l'infrastructure complète, commencez par la messagerie professionnelle pour petites entreprises, puis vérifiez le DNS.
La configuration est accessible, mais des restrictions sans contrôle de SPF, DKIM, transferts et expéditeurs externes peuvent affecter des messages légitimes. Ce guide explique les premiers enregistrements, les champs, la transition et les erreurs fréquentes.
Le rôle de la configuration DMARC
Vous publiez un TXT sous _dmarc.yourdomain.com pour demander comment traiter les messages en échec DMARC. Le destinataire vérifie si SPF ou DKIM réussit et si ce résultat valide s'aligne sur le From visible.
DMARC complète SPF et DKIM. Selon la RFC 7489, au moins l'un doit réussir avec alignement sur le domaine From. Une authentification non alignée ne suffit pas, et une réussite ne prouve pas que le contenu soit sûr.
Google décrit des exigences selon le type d'expéditeur : SPF ou DKIM pour les expéditeurs ordinaires ; les deux et DMARC avec l'alignement applicable pour ceux en masse. Consultez les consignes pour les expéditeurs actuelles.
DMARC communique donc une politique pour les échecs d'authentification alignée. Le destinataire conserve ses exceptions et autres filtres ; cela ne garantit ni confiance ni remise.
Quel enregistrement publier d'abord ?
Si tous les expéditeurs ne sont pas encore vérifiés, commencez par p=none. Demandez des rapports et complétez-les avec inventaire et tests avant les restrictions. Leur envoi dépend des participants.
Cet exemple sous _dmarc utilise l'alignement strict facultatif, pas un point de départ universel :
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100Les options adkim=s et aspf=s exigent une correspondance exacte. Choisissez l'alternative souple si elle convient à vos expéditeurs :
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100Publiez un seul enregistrement. L'alignement souple accepte des identifiants du même domaine organisationnel, pas n'importe quelle relation entre domaine parent et sous-domaine.
Dans TrekMail, vérifiez les données du tableau de bord et consultez Enregistrements DNS requis, Ajouter un domaine et Vérifier l'état DNS. L'exemple documentaire avec p=quarantine ne signifie pas qu'il faille appliquer des restrictions avant l'inventaire d'un domaine actif. Un contrôle DNS ne prouve pas l'authentification de tous les messages.
Les champs DMARC importants
Commencez par la politique, la destination des rapports et l'alignement. Évaluez les autres options après vérification des expéditeurs réels.
| Champ | Fonction | Option pratique |
|---|---|---|
v | Version du protocole | DMARC1 |
p | Politique du domaine principal | none pour observer, puis évaluer quarantine et reject avec des tests |
rua | Destination des agrégés | Boîte ou service surveillé |
adkim | Alignement DKIM | r ou s selon les expéditeurs |
aspf | Alignement SPF | r ou s selon les expéditeurs |
pct | Pourcentage demandé d'application aux échecs | 100, avec application selon le destinataire |
sp | Politique héritée des sous-domaines | Configurer si elle doit différer |
p demande une action et rua des retours. Les rapports sont partiels et nécessitent analyse, contrôles d'accès et autorisation DNS pour les destinations externes.
Selon la RFC 7489, pct permet de demander une application progressive. Ce n'est pas une répartition déterministe respectée par tous. 100 exprime la couverture demandée ; en surveillance, cela n'active pas de restriction.
Configurer DMARC étape par étape
Vérifiez SPF et DKIM, publiez une politique de surveillance, comparez rapports et tests, puis évaluez les restrictions. La politique ne remplace pas les corrections des expéditeurs.
- Inventorier boîtes, CRM, facturation, support, formulaires et marketing utilisant le domaine.
- Vérifier SPF pour le véritable domaine d'enveloppe. N'autoriser que les services nécessaires dans un seul enregistrement et contrôler la limite de dix mécanismes ou modificateurs déclenchant des recherches DNS, y compris dans les évaluations imbriquées.
- Activer et tester DKIM sur chaque expéditeur compatible avec son sélecteur et sa clé réels.
- Publier le premier enregistrement avec
p=none. - Observer les rapports pendant 2 à 4 semaines comme repère, puis prolonger ou tester les flux mensuels, trimestriels et critiques.
- Envisager
p=quarantineaprès correction des échecs légitimes et tests des routes. - Envisager
p=rejectaprès inventaire et tests, sans supposer que les rapports couvrent tout.
Requêtes utiles :
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT dkim._domainkey.example.com +shortCe modèle est illustratif : incluez uniquement les services autorisés pour l'enveloppe réelle, utilisez le sélecteur de l'expéditeur et remplacez la clé abrégée par la complète :
; SPF
example.com. IN TXT "v=spf1 include:spf.trekmail.net include:_spf.google.com -all"
; DKIM
dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
; DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"Pour une nouvelle installation, consultez la messagerie avec son domaine. Pour copier les messages, consultez la présentation de la migration IMAP : cette copie ne modifie ni ne garantit à elle seule les MX, les expéditeurs ou l'authentification sortante.
Quand DMARC réussit ou échoue
DMARC réussit si SPF ou DKIM réussit avec alignement sur From. Il échoue si aucun ne fournit ce résultat, même si l'autre s'authentifie avec un domaine différent.
L'alignement du tableau doit correspondre au mécanisme qui réussit :
| SPF | DKIM | Aligné ? | DMARC |
|---|---|---|---|
| Pass | Fail | Oui | Pass |
| Fail | Pass | Oui | Pass |
| Pass | Pass | Non | Fail |
| Fail | Fail | Non | Fail |
Lors d'un transfert, SPF peut échouer avec l'IP intermédiaire. DKIM peut rester valide si les données signées sont conservées selon la canonicalisation. Ne supposez pas que toutes les listes ou passerelles les préservent.
Vous envoyez depuis
billing@example.comet un client transfère vers Gmail. SPF peut échouer avec la nouvelle route. Si DKIM reste valide avecd=example.comet aligné sur From, DMARC réussit.
Examinez le contexte des échecs SPF avant de les autoriser ou de les ignorer. DKIM valide et aligné peut expliquer une réussite DMARC après transfert.
Consultez le transfert de messages pour les routes indirectes. SRS et ARC peuvent aider dans certains cas, sans garantir alignement original, remise ou acceptation.
Passer de none à quarantine et reject
Commencez par observer, puis évaluez les restrictions. Elles peuvent limiter certaines usurpations mais aussi affecter des expéditeurs oubliés ; les destinataires conservent leurs exceptions.
Options de politique :
p=none: aucune restriction DMARC demandée ; d'autres filtres restent possibles.p=quarantine: traitement des échecs comme suspects, sans garantie d'un dossier précis.p=reject: rejet demandé, selon le jugement local.
Ces phases sont des alternatives successives : publiez uniquement celle qui convient.
; Phase 1
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100
; Phase 2
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100
; Phase 3
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100Utilisez sp= si l'héritage des sous-domaines doit différer. Selon la RFC 7489, dans un domaine organisationnel sp définit cette alternative ; sans ce champ, la politique principale s'applique, sauf enregistrements spécifiques des sous-domaines.
Erreurs courantes de configuration
Les causes concernent souvent SPF, DKIM, noms DNS ou From des prestataires. Identifiez-les avant de modifier la politique.
| Erreur | Risque | Correction |
|---|---|---|
| Restrictions sans vérifier DKIM | Transferts sans autre authentification alignée en échec | Activer et tester DKIM ; none ne cause pas cet échec à lui seul |
| Plusieurs SPF | SPF retourne PermError | Un seul SPF valide |
| Mauvais nom DMARC | Politique attendue introuvable | Publier sous _dmarc, pas à la racine |
| Reject prématuré | Rejets légitimes possibles | Observer avec p=none et tester |
| Alignement ignoré | Authentification valide sans réussite DMARC | Aligner le mécanisme valide sur From |
| Aucun destinataire de rapports | Ce canal manque, pas toute visibilité | Ajouter rua valide et surveillé |
Un alias envoyé par un prestataire signant avec son domaine peut réussir DKIM sans s'aligner sur le vôtre. Si SPF n'apporte pas d'alignement non plus, DMARC échoue. Consultez alias de domaine ou boîte pour la route réelle.
Les états DNS TrekMail aident à détecter des erreurs des enregistrements indiqués, sans prouver l'authentification de tous les expéditeurs. Consultez l'état DNS et testez de vrais messages.
TrekMail : infrastructure dispersée ou coordonnée
Combiner hébergement, transferts et trois SMTP demande de la coordination. TrekMail peut réunir domaines, boîtes, contrôles DNS, transferts et migration selon l'offre, sans supprimer la vérification externe.
| Environnement dispersé | Approche avec TrekMail |
|---|---|
| Facturation par utilisateur dans des outils distincts | Offres multidomaines avec limites et conditions propres |
| Stockage séparé par boîte | Stockage mutualisé selon l'offre, également proposé dans certains plans facturés par utilisateur |
| DNS modifié sans vérification | Contrôles et parcours SPF/DKIM/DMARC |
| Migrations mal coordonnées | Copie IMAP côté serveur ; transition à planifier |
| Transferts sans vérifier l'authentification | Outils pour configurer et vérifier les routes compatibles |
Cela peut aider opérateurs individuels et agences. Un domaine demande du travail ; cinquante exigent des procédures cohérentes, sans garantie de marge ou d'incidents réduits.
Starter est annoncé dès $3.50 par mois. Nano est proposé gratuitement sans carte jusqu'à 10 domaines avec votre propre SMTP selon les termes. Les offres payantes concernées proposent le SMTP géré et peuvent inclure un essai de 14 jours avec carte requise. Consultez les tarifs TrekMail actuels.
Liste finale de configuration DMARC
Publier un TXT ne suffit pas : vérifiez authentification alignée, rapports partiels et flux avant les restrictions. Cela peut réduire certains risques d'usurpation, sans garantir la confiance, la remise ou une protection totale.
- Inventorier tous les expéditeurs du domaine.
- Maintenir un seul SPF valide.
- Activer et tester DKIM lorsque compatible.
- Publier la surveillance DMARC.
- Examiner les rapports pendant 2 à 4 semaines comme repère et couvrir les cycles rares.
- Envisager quarantine après les tests.
- Envisager reject après correction des échecs légitimes et tests critiques.
Le suivi reste nécessaire : routes et services peuvent changer après la configuration.
Pour coordonner l'exploitation, TrekMail propose hébergement multidomaine, stockage mutualisé, migration IMAP et contrôles DNS selon l'offre. Examinez l'option gratuite sur trekmail.net ou les conditions d'envoi géré sur les tarifs.
L'objectif est de réduire les usurpations et les restrictions injustifiées par configuration, tests et surveillance continus.
