Sign inGet started

Domaine de rebond

Votre domaine de rebond est le nom d'hôte return-path d'un domaine d'envoi. Les rebonds et les retours de livraison arrivent à cette adresse envelope-from. Son CNAME nous permet de traiter les rebonds et fournit l'alignement SPF sans enregistrement SPF à l'apex de votre domaine. Le domaine de rebond est l'un des trois enregistrements qui conditionnent l'envoi.
Cette page traite spécifiquement du return-path. Pour l'ensemble des enregistrements et le cycle de vérification, consultez Domaines d'envoi ; pour ce que chaque enregistrement prouve, consultez DKIM, SPF & DMARC.

L'enregistrement

Le return-path est un CNAME sous votre domaine d'envoi qui résout vers notre infrastructure de rebond dans votre région :
TypeHostValeur
CNAMEsend.example.com<region>.bounce.bird.com
La valeur est propre à la région : us1.bounce.bird.com ou eu1.bounce.bird.com. Copiez-la depuis Email > Domains dans le tableau de bord ou depuis la ressource du domaine. L'hôte est par défaut send. sous votre domaine d'envoi.

Personnaliser le nom d'hôte

Vous choisissez le libellé au moment d'enregistrer le domaine : transmettez-le comme return_path.name et nous composons le nom d'hôte complet sous votre domaine d'envoi :
const domain = await bird.domains.create({
  domain: "mail.acme.com",
  return_path: { name: "bounce" },
});
Cela enregistre bounce.mail.acme.com comme return-path au lieu de la valeur par défaut send.mail.acme.com. Omettez return_path et la valeur par défaut est send. Le nom d'hôte fait partie de la configuration de l'espace de travail du domaine d'envoi.

Pourquoi il couvre SPF

Les récepteurs évaluent SPF par rapport au domaine envelope-from plutôt qu'à l'adresse From: visible. Votre envelope-from est le nom d'hôte return-path. Comme le CNAME vérifié résout vers notre infrastructure de rebond, l'autorisation SPF de cette infrastructure s'applique à vous, et elle s'aligne avec votre domaine parce que le return-path en est un sous-domaine. SPF passe donc et s'aligne avec un seul CNAME, et vous n'avez pas à publier ni à maintenir d'enregistrement include: à votre apex. Le raisonnement complet se trouve dans Où est SPF ?.

Obligatoire pour l'envoi et non supprimable

Le CNAME return-path fait partie du contrôle d'envoi : capabilities.sending ne vérifie que lorsque DKIM, le CNAME return-path et une politique DMARC sont tous en place. Tant que le return-path n'est pas vérifié, le domaine ne peut pas envoyer.
Pour la même raison, le return-path ne peut pas être supprimé. Chaque envoi a besoin d'une destination pour les rebonds, vous pouvez donc changer le nom d'hôte mais jamais le désactiver : une mise à jour qui tente de le passer à null est rejetée. Les changements sont déployés de manière sécurisée. Un nom d'hôte déjà vérifié n'est jamais remplacé par un nom non vérifié. Nous vérifions le nouveau return-path en parallèle de celui qui est actif et ne le promouvons qu'une fois le nouveau CNAME validé, de sorte que l'envoi en production n'est jamais interrompu pendant la migration de l'enregistrement.

Étapes suivantes