Une application d'envoi et une boîte de réception peuvent utiliser des domaines différents. Les enregistrements qui acheminent les réponses n'ont pas besoin de figurer sur chaque sous-domaine utilisé pour l'envoi.
Comment un serveur expéditeur utilise-t-il les enregistrements MX ?
Le serveur expéditeur interroge le domaine du destinataire pour trouver les serveurs qui acceptent son courrier entrant.
Pour person@example.org, il recherche les enregistrements MX de example.org. Chaque enregistrement désigne un serveur de destination dont le nom d'hôte se résout en adresse IP.
RFC 5321 définit ce processus de recherche pour SMTP.
Le serveur expéditeur signale une erreur lorsque le domaine du destinataire n'existe pas. Après un échec de recherche temporaire, il met le message en file d'attente pour une tentative ultérieure.
Que se passe-t-il lorsqu'un domaine n'a pas d'enregistrement MX ?
Si aucun enregistrement MX n'existe, SMTP traite le domaine lui-même comme destination et essaie ses enregistrements d'adresse.
Ce MX implicite a la préférence zéro. Il n'existe pas de liste MX explicite pour le surpasser, donc la livraison s'effectue vers l'adresse propre du domaine lorsqu'elle est utilisable.
Ce repli s'applique à une liste MX vide. Il ne sauve pas un domaine dont les enregistrements MX publiés sont inutilisables.
Un null MX est une instruction différente : RFC 7505 définit un enregistrement explicite déclarant que le domaine n'accepte aucun courrier. Un enregistrement absent autorise le repli. Un null MX refuse la livraison.
Que signifient les numéros de préférence MX ?
Les valeurs de préférence les plus basses identifient les destinations qu'un expéditeur doit essayer en premier.
Avec les valeurs 10, 20 et 30, la destination à 10 est préférée. Les autres fournissent des alternatives si la livraison ne peut pas aboutir à cette adresse. Attribuer la même valeur à toutes les destinations permet une répartition entre des choix de préférence égale.
Selon RFC 5321, les serveurs expéditeurs doivent traiter les destinations de même préférence dans un ordre aléatoire, sauf s'il existe une raison claire d'en privilégier une. Des préférences égales ne garantissent pas une répartition exacte du trafic.
Faites pointer votre enregistrement MX vers un nom d'hôte dont vous publiez l'adresse, afin que les expéditeurs puissent se connecter. Utilisez un enregistrement A pour son adresse IPv4 ou un enregistrement AAAA pour IPv6. N'utilisez pas un alias CNAME comme destination. L'alias empêche le DNS d'inclure l'adresse dans sa réponse MX. Cela ajoute des recherches, comme l'explique RFC 2181.
Les clients SMTP doivent pouvoir essayer des destinations alternatives. La spécification recommande d'essayer au moins deux adresses lorsqu'elles sont disponibles. Un échec sur la première n'a alors pas besoin de mettre fin aux tentatives de livraison.
Faut-il un enregistrement MX pour envoyer ?
SMTP n'exige pas d'enregistrement MX explicite sur votre domaine pour simplement émettre un message.
La recherche de livraison utilise le domaine du destinataire. Votre domaine d'envoi a toujours besoin d'un DNS valide et d'une authentification adaptée aux exigences du récepteur. Un récepteur peut appliquer ses propres vérifications au domaine de l'expéditeur.
L'absence d'enregistrement MX ne signifie donc pas qu'un domaine d'expéditeur injoignable soit acceptable pour tous les récepteurs.
Où vont les échecs de livraison ?
Les échecs de livraison sont envoyés à l'expéditeur d'enveloppe, l'adresse fournie pour les avis d'échec lors de la livraison SMTP.
Où vont les réponses ?
Les réponses utilisent normalement Reply-To lorsqu'il est présent, sinon l'adresse From visible.
Un sous-domaine d'envoi n'a pas besoin d'héberger toutes les boîtes aux lettres de l'entreprise. Par exemple, news.example.com peut envoyer tandis que les réponses arrivent à une adresse fonctionnelle sur example.com. Rendez ce choix de routage explicite dans les adresses du message.
Où vont les rapports opérationnels ?
Les adresses opérationnelles telles que postmaster@ et abuse@ offrent aux autres opérateurs un moyen de signaler des problèmes de livraison ou d'abus.
Selon RFC 5321, un serveur SMTP qui relaie ou distribue du courrier doit accepter postmaster@ pour les domaines qu'il dessert. Cela fournit un contact pour les problèmes de service de messagerie.
RFC 2142 exige des organisations qu'elles prennent en charge les boîtes aux lettres de rôle lorsque la fonction correspondante existe. Par exemple, un fournisseur de services Internet doit prendre en charge abuse@ sur son domaine organisationnel. Cela achemine les plaintes vers l'équipe responsable.
Comment recevoir des e-mails avec Bird ?
Vous activez la réception pour un domaine et publiez les enregistrements MX que Bird renvoie.
Le champ inbound.enabled de API accepte true pour activer la réception ou false pour la désactiver. Publier les enregistrements seuls n'active pas la fonctionnalité.
Après vérification, le courrier adressé à ce domaine devient des messages entrants. Utilisez un sous-domaine de réception dédié, car remplacer les enregistrements MX du domaine de votre entreprise modifie la destination de son courrier existant.
L'enregistrement return-path de Bird gère les avis d'échec de livraison séparément de ces enregistrements MX entrants. Le guide de réception explique la configuration du domaine. Le guide du domaine de rebond explique la gestion des échecs.
En bref
Les enregistrements MX acheminent le courrier entrant.
Le serveur expéditeur interroge le domaine du destinataire pour trouver une destination.
En l'absence d'enregistrements MX, un repli sur les enregistrements d'adresse est possible.
Lorsqu'aucun enregistrement MX n'existe, le serveur expéditeur peut utiliser les enregistrements d'adresse du domaine.
Les valeurs de préférence les plus basses sont essayées en premier.
Les destinations de même préférence sont traitées dans un ordre aléatoire lorsqu'il n'y a pas de raison d'en privilégier une.
L'envoi et la réception nécessitent des décisions distinctes.
Le courrier sortant exige toujours une gestion appropriée des échecs de livraison, des réponses et des adresses de contact opérationnelles.