Acheminer le courrier Oracle Cloud avant de modifier DNS
Oracle Cloud n'est pas une configuration unique d'envoi d'e-mails. Commencez par identifier le service qui crée et transmet réellement le message. Une application d'infrastructure utilisant OCI Email Delivery, une notification Fusion et une campagne Eloqua peut partager un domaine From d'entreprise tout en ayant différents workflows d'activation. Cet article fournit un plan de routage et d’acceptation. Il n’établit pas un Oracle Cloud universel SPF inclure ou Sélecteur DKIM.
Oracle exclut explicitement Fusion Apps, Cloud Notification Services, IDCS classique, Oracle Integration Cloud Generation 2 et OTMGTM de la livraison de courrier électronique OCI. DKIM procédure de console. Des instructions ou une assistance spécifiques au produit sont requises pour ces itinéraires. Différentes clés de service partageant un domaine nécessitent différents sélecteurs. Voir OCI Email Delivery configuration DKIM.
Constituer un inventaire de produits et de transport
Demandez au propriétaire de l'application le nom exact du produit, l'environnement, la région, le type de message et le paramètre de transport. Une capture d'écran intitulée Oracle Cloud seule est insuffisante. Enregistrez si l'application est soumise à un point de terminaison Email Delivery, émet une notification SaaS gérée ou délègue l'envoi à un autre service. N'utilisez pas d'adresse IP ou de pied de page marketing comme seule preuve du produit.
Capturez un message de base inoffensif du flux de travail en cours d’évaluation. Conserver son horodatage, son destinataire, son ID de message, visible depuis, Return-Path and DKIM d= and s= values. Comparez-les avec la configuration de l'application. Si le propriétaire ne peut pas connecter le message à un environnement particulier, laissez la configuration en attente plutôt que d'élargir les autorisations DNS pour répondre à une supposition.
Attribuer le bon propriétaire de configuration
Pour un itinéraire de livraison de courrier électronique OCI identifié, les ressources de domaine de messagerie et d'expéditeur approuvé appartiennent à ce service. Les expéditeurs approuvés sont des ressources régionales, donc un expéditeur configuré dans une région n'établit pas d'approbation dans une autre. Voir OCI gérant les expéditeurs agréés. Pour Fusion, le processus DKIM documenté est manuel et répété par environnement, et non une opération de console OCI. Voir Les applications Fusion configurent la sécurité de la messagerie.
Créez un enregistrement de modification distinct pour chaque produit et environnement. Le propriétaire DNS doit recevoir le propriétaire, le type et la valeur précis de l'enregistrement du flux de travail applicable. Le propriétaire de l'application doit confirmer séparément l'activation. Ces deux approbations répondent à des questions différentes : si les informations requises sont publiées publiquement et si l'expéditeur prévu les utilise réellement.
Évaluez l’authentification sans confondre les identités
SPF évalue l'autorisation pour son identité SMTP ; DKIM vérifie une signature associée à un domaine de signature. Ni un nom d'affichage familier ni une entrée d'expéditeur approuvé ne prouvent DMARC alignement. Un résultat SPF ou DKIM aligné et réussi est nécessaire pour le succès DMARC , sous réserve du mode d'alignement applicable. Utiliser Cadre de politique de l'expéditeur RFC 7208, Courrier identifié par clés de domaine RFC 6376 et Rapports et conformité de l'authentification des messages basée sur le domaine RFC 9989 pour ces distinctions.
Pour chaque itinéraire, écrivez le domaine From attendu à côté du domaine authentifié observé. Then explain which path supplies alignment. Si un domaine d'enveloppe appartenant à un fournisseur passe SPF mais diffère du domaine From de l'organisation, inspectez DKIM plutôt que de supposer que SPF seul est suffisant. N'affaiblissez pas la politique DMARC de l'organisation pour masquer un itinéraire non identifié.
Feuille de calcul d'itinéraire Oracle Cloud
Créez une ligne par workflow métier, en utilisant ces champs :
- Application and exact Oracle product: ____; environnement ou module : ____ ; région ou royaume : ____.
- Type de message et propriétaire de l'entreprise : ____ ; transport ou point final observé : ____.
- ID de message de base et horodatage UTC : ____ ; récepteur contrôlé : ____.
- Visible à partir de : ____ ; domaine de l'enveloppe : ____ ; DKIM d= et s=: ____.
- Procédure de première partie applicable : ____ ; procédures exclues vérifiées : ____.
- Propriétaire de l'enregistrement DNS et source de la valeur émise : ____ ; propriétaire de l'activation et preuve : ____.
- Mécanisme aligné attendu : ____ ; résultat observé : ____ ; portée non résolue : ____.
- Décision pilote, propriétaire de récupération et approbation humaine : ____.
Conservez les itinéraires non pris en charge sous forme de lignes non résolues distinctes. Un test OCI réussi ne doit pas rendre la ligne Fusion verte. Cette ségrégation empêche qu'un nom de marque partagé soit traité comme une couverture technique partagée.
Diagnostic fictif d'une route Oracle erronée
Exemple fictif uniquement : Northstar Services ajoute un enregistrement DKIM de livraison de courrier électronique OCI après l'échec de l'authentification d'une notification de facture Fusion. Le nouveau sélecteur est résolu correctement, mais la facture porte toujours l'identité de signature d'origine. La recherche DNS prouve la publication, mais pas que Fusion ait adopté la clé. L'équipe identifie l'environnement Fusion et demande sa procédure d'activation prise en charge. Il conserve l'enregistrement OCI uniquement si une application OCI réelle l'exige toujours.
La leçon de diagnostic consiste à réconcilier le message avec le service générateur avant de modifier les enregistrements. Aucun locataire Northstar, zone DNS ou message en direct n’a été testé pour cet article.
Acceptation et portes restantes
Approuvez uniquement le flux de travail nommé après l'accord de la procédure produit correcte, DNS faisant autorité, de l'activation de l'application et de la preuve contrôlée des messages reçus. Testez à nouveau les régions modifiées, les domaines From personnalisés et les types de notification alternatifs en tant qu'itinéraires distincts. Archivez un échantillon rédigé et la révision exacte des modifications, puis surveillez les régressions pendant le projet pilote convenu.
Le vaste sujet initial d'Oracle Cloud reste une portée limitée. Cet article de routage n'est pas un guide de configuration pour chaque service Oracle. L'inspection en direct des locataires, les valeurs émises, les tests DNS et de récepteurs, l'examen visuel, l'approbation humaine de la PME et la publication restent en attente.
Séparer l’acceptation des messages du déploiement de la politique
Un résultat SPF aligné peut satisfaire une évaluation de message, mais ne justifie pas à lui seul le déplacement d'un domaine entier vers le rejet. RFC 9989 La section 7.4 nécessite DKIM valide pour la publication de domaines p=reject et met en garde contre l'interopérabilité du courrier indirect. Inventoriez tous les expéditeurs légitimes et les itinéraires indirects avant que le propriétaire de la politique n’approuve l’application. Aucune modification DNS , opération de locataire ou test de message reçu n’a été exécuté pour cet article.