Configuration DNS de Zarfio : MX, SPF, DKIM et DMARC

Étapes

1. Ouvrez un compte et ajoutez le domaine. Créez un compte Zarfio et ajoutez le domaine dont vous êtes titulaire. L'interface liste les enregistrements dont ce domaine a besoin.
2. Vérifiez le domaine. Publiez chez votre hébergeur DNS l'enregistrement de vérification que l'interface affiche, puis confirmez-le dans l'interface.
3. Créez les boîtes aux lettres. Créez chaque adresse que vous utilisez aujourd'hui avant de déplacer les MX. Les boîtes existantes chez Google Workspace ou Yandex 360 peuvent être migrées.
4. Abaissez le TTL des MX et basculez les MX. Sur un domaine qui reçoit déjà des e-mails, abaissez d'abord le TTL des MX. Remplacez ensuite les anciens enregistrements MX par ceux de l'interface.
5. Publiez SPF, DKIM et DMARC. Copiez les valeurs SPF et DKIM depuis l'interface, exactement telles qu'elles sont affichées. Si un autre service envoie aussi pour le domaine, gardez un seul enregistrement SPF et ajoutez-y l'include: de ce service.
6. Contrôlez avec OrbitProbe. Lancez les vérifications MX, SPF, DKIM et DMARC de cette page jusqu'à ce que chacune lise les valeurs de l'interface.

DMARC

DMARC est identique chez tous les fournisseurs : un enregistrement TXT sous _dmarc.example.com. Commencez par p=none et une adresse de rapport, afin de recevoir des rapports sans affecter la livraison.

Lisez les rapports pendant quelques semaines. Lorsque chaque expéditeur légitime réussit SPF ou DKIM avec un domaine aligné, passez à p=quarantine, puis à p=reject. Passer à reject avant que DKIM soit activé pour tous les expéditeurs est la façon habituelle de perdre des e-mails légitimes.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Facultatif : MTA-STS, TLS-RPT et BIMI

MTA-STS demande aux serveurs expéditeurs d'exiger TLS lorsqu'ils vous livrent des e-mails. Il lui faut un enregistrement TXT et un fichier de politique servi en HTTPS sous mta-sts.example.com ; la politique doit lister exactement les hôtes MX de votre fournisseur.

TLS-RPT demande aux expéditeurs de signaler les échecs de livraison TLS à une adresse que vous choisissez. Un seul enregistrement TXT, sans effet sur la livraison.

BIMI permet à certains fournisseurs de messagerie d'afficher votre logo. Il exige DMARC en quarantine ou en reject, et la plupart des fournisseurs exigent aussi un certificat de marque vérifiée.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Clients de messagerie : autodiscover et autoconfig

Les boîtes Zarfio fonctionnent avec le webmail et avec les clients IMAP, SMTP et ActiveSync standard. Pour une configuration manuelle, utilisez les noms de serveur affichés dans l'interface Zarfio.

Conseils sur le TTL

Avant de modifier les enregistrements MX d'un domaine qui reçoit déjà des e-mails, abaissez leur TTL à 300 secondes et attendez que l'ancien TTL soit écoulé. Les résolveurs prennent alors en compte les nouveaux enregistrements en quelques minutes.

Quand la nouvelle configuration fonctionne depuis quelques jours, remontez le TTL : 3600 secondes est une valeur courante. Les enregistrements SPF, DKIM et DMARC changent rarement et peuvent rester à 3600.

Combien de temps prennent les modifications ?

Vos serveurs de noms faisant autorité répondent avec le nouvel enregistrement dès que votre hébergeur DNS l'a publié. Un résolveur qui a mis l'ancienne réponse en cache la garde jusqu'à l'expiration de l'ancien TTL ; un nom qui n'existait pas auparavant peut être mémorisé comme absent pendant la durée de cache négatif de votre enregistrement SOA.

Il n'existe aucun moment où une modification est présente partout à la fois. L'outil de propagation montre ce que répond un ensemble fixe de résolveurs publics au moment de la vérification, sous forme d'un décompte tel que « 9 résolveurs sur 12 », et rien de plus.

Les fournisseurs recontrôlent vos enregistrements à leur propre rythme ; un bouton de vérification dans l'interface peut donc rester rouge un moment alors que le DNS est déjà correct.

Erreurs fréquentes

• Basculer les MX avant que les boîtes aux lettres existent : les e-mails destinés à des adresses pas encore créées sont alors rejetés.
• Deux enregistrements SPF. Un domaine ne peut avoir qu'un seul enregistrement TXT commençant par v=spf1 ; un second fait échouer SPF avec une erreur permanente. Fusionnez les mécanismes include: dans un seul enregistrement.
• Laisser les enregistrements MX de l'ancien fournisseur à côté des nouveaux. Les e-mails sont alors livrés à l'un ou à l'autre, selon la priorité et le hasard.
• Saisir le nom complet dans un champ d'hôte qui ajoute le domaine, ce qui produit google._domainkey.example.com.example.com. Recherchez l'enregistrement après l'avoir enregistré.
• Une clé DKIM coupée en deux. Les valeurs TXT longues doivent être découpées en chaînes entre guillemets de 255 caractères au plus ; la plupart des hébergeurs DNS le font pour vous, certains non.
• Plus de dix requêtes DNS dans SPF après l'ajout de plusieurs mécanismes include:. La vérification SPF les compte.
• Un enregistrement MX qui pointe vers un CNAME ou vers une adresse IP. Il doit pointer vers un nom d'hôte qui possède des enregistrements A ou AAAA.