[ Guides de service d'envoi ]
Authentifier les e-mails envoyés via Braze : configuration et vérification
Faites correspondre l'authentification Braze à l'architecture de messagerie fournie, conservez les identités de chemin de retour et d'expéditeur distinctes et validez l'accès à l'espace de travail avant l'envoi.
Par l’équipe de recherche EmailAuth · 4 minutes de lecture
[ Points clés ]
- Faites correspondre le provisionnement à l’architecture ESP réelle.
- Gardez les identités d'envoi, de rebond et de suivi distinctes.
- Vérifiez l’accès à l’espace de travail et les deux états de préparation du domaine.
Sur cette page
[ Emporter ]
Vérifiez l’accès à l’espace de travail et les deux états de préparation du domaine.
[ Par rôle ]
Qu'est-ce que cela signifie pour vous
Choisissez votre rôle pour les prochaines étapes pratiques.
Administrateur informatique/courrier
Vérifier l'itinéraire réel
Réconciliez l'architecture ESP exacte, le jeu d'enregistrements DNS et les autorisations de l'espace de travail.
Prochaines étapes
- Faites correspondre les enregistrements à l’architecture ESP provisionnée.
- Testez l’identité et le suivi de l’expéditeur uniquement lorsque les deux domaines sont prêts.
- Retestez après un changement de domaine d’envoi ou de fournisseur DNS.
RSSI / SecOps
Contrôler la limite d'autorisation
Limitez l’accès au domaine et examinez la portée de la délégation plutôt que de traiter tous les espaces de travail de manière équivalente.
Prochaines étapes
- Accordez la portée minimale de l’espace de travail.
- Coordonnez la suppression de domaine dirigée par le support avec les dépendances de campagne actives.
- Conserver les décisions approuvées de reprise et de retrait des fournisseurs.
Fondateur / Non technique
Posséder la décision d'envoi
Choisissez la hiérarchie de domaines avant l'intégration, car les identités soumises ne sont pas des modifications occasionnelles.
Prochaines étapes
- Approuvez la hiérarchie du domaine avant de la soumettre.
- Planifiez l'accès à l'espace de travail avec les propriétaires de campagne.
- Exiger l’enregistrement d’acceptation des messages contrôlés avant le lancement.
[ FAQ ]
Questions fréquemment posées
Chaque client existant peut-il utiliser le flux libre-service cité ?
La documentation s'étend à l'intégration de nouveaux clients avec les autorisations et l'infrastructure répertoriées. Confirmez votre itinéraire.
Le domaine d'envoi et le courrier proviennent-ils du même champ ?
Non. L’un contrôle l’identité visible de From ; l'autre est l'identité de l'enveloppe utilisée pour les rebonds et SPF .
Dois-je ajouter Braze SPF à la racine de l’entreprise ?
Utilisez l’architecture de chemin de retour provisionnée. Le guide DNS de Braze place cette autorisation sur un sous-domaine dédié.
Puis-je copier les cibles CNAME d'un autre compte ?
Non. Utilisez des enregistrements mappés à votre propre architecture et environnement.
Les sous-domaines frères satisferont-ils à un alignement SPF strict ?
Non. Un alignement strict nécessite que le domaine authentifié par SPF soit exactement égal au domaine visible From.
Pourquoi le suivi est-il toujours en attente alors que l'envoi est prêt ?
Il s'agit de configurations de domaine distinctes et peuvent être validées à des moments différents.
Puis-je modifier un domaine d'envoi soumis ?
La documentation en libre-service indique qu'elle ne peut pas être modifiée après la soumission ; coordonner la suppression avec le support.
Qu'est-ce qui prouve qu'un espace de travail est prêt ?
Le domaine prévu est disponible pour cet espace de travail et un message contrôlé affiche l'expéditeur, l'alignement et les liens de travail corrects.
[ Sources ]
Sources
- Libre-service de courrier électronique Braze
Sections Prérequis · Considérations · Étapes 1 à 3 · Étape 5 : Testez votre envoi d'e-mails · Foire aux questions : quatre lignes d'enregistrement NS
- Architectures DNS Braze
Sections Principes fondamentaux de l'authentification des e-mails · Architecture DNS spécifique à ESP : SparkPost , SendGrid , Amazon SES
- RFC 7208 SPF
Sections §2.4 Vérification de l'autorisation · §3.2 Enregistrements DNS multiples · §4.6.4 Limites de recherche DNS
- RFC 6376 DKIM
Sections §3.5 En-tête DKIM-Signature · §3.6.2 Liaison DNS · §6 Actions du vérificateur
- RFC 9989 DMARC
Sections §4.4 Alignement des identifiants · §4.10 Parcours de l'arborescence DNS · §5.3.5 Déterminer la réussite ou l'échec DMARC
- Concepts DNS RFC 1034
Sections §3.6.2 Alias et noms canoniques · §4.2 Comment la base de données est divisée en zones
[ Glossaire ]
Glossaire
- Alignement
- La relation requise entre un domaine d'authentification de passage et le domaine From visible pour DMARC .
- Sélecteur
- L'étiquette DKIM utilisée avec le domaine signataire pour localiser sa clé publique dans DNS .
- DNS faisant autorité
- Le service de serveur de noms responsable de la publication des enregistrements de zone pertinents.
- Return-Path
- La trace des messages reçus du chemin inverse SMTP , utile lors de l'enquête sur l'identité de l'enveloppe.
Provenance de l'entreprise
Pourquoi les principales institutions financières et gouvernements ont retiré leurs tableaux de bord de sécurité de messagerie.
Les plateformes traditionnelles d'authentification de courrier électronique vous vendent un tableau de bord et demandent à vos ingénieurs de faire le travail. Dans les environnements à enjeux élevés, la surveillance manuelle entraîne des retards dans l’application, des dérives de configuration et des domaines fantômes non surveillés.
EmailAuth est la plateforme agent de provenance des e-mails. Nos agents appliquent p=reject, gardez les expéditeurs tiers alignés et déplacez vos domaines au maximum RFC 9989 conformité, la nouvelle norme DMARC , avec une auditabilité humaine dans la boucle.
SaaS · Location dédiée · Air-gappé sur site · Chiffrement BYOK