Ein Domänenalias ändert, wie eine Adresse innerhalb eines Dienstes verwendet oder empfangen werden kann. Es definiert nicht allein die Domäne, die in einem Outbound platziert wird DKIM Signatur. Bevor Sie einen Alias für Kunden-E-Mails verwenden, prüfen Sie eine über die vorgesehene Route gesendete Nachricht und ermitteln Sie, welche Identität der Dienst signiert.
Alias ist ebenfalls ein überladener Produktbegriff. Es kann eine alternative Postfachadresse, eine an einen Mandanten angehängte Domäne oder eine Absenderidentität auf Anwendungsebene beschreiben. Dieser Workflow gilt für die resultierende Nachricht und DNS -Beweis. Konsultieren Sie die aktuelle Dokumentation für die jeweilige Alias-Funktion, bevor Sie davon ausgehen, dass sie das Senden oder benutzerdefinierte Domänen unterstützt DKIM.
Trennen Sie die Empfangskonfiguration von der Sendeidentität
Stellen Sie zunächst fest, wozu der Alias dienen soll. Eine Adresse, die Nachrichten in einem vorhandenen Postfach empfängt, darf niemals für die ausgehende Verwendung autorisiert werden. Wenn das Senden unterstützt wird, bestimmen Sie, ob der Dienst den Alias in „From“ behält, ihn in die primäre Adresse umschreibt oder ihn über einen anderen Absender weiterleitet.
Notieren Sie die sichtbare Absenderadresse nach der Zustellung, nicht nur die im Erstellungsfenster ausgewählte Adresse. Erfassen Sie auch alle Absenderfelder und Umschlagidentitäten, verwechseln Sie diese jedoch nicht mit der SD-Domäne von DKIM . RFC 6376 §3.5 Definiert die d-Signaturdomäne, die sich von der Adresse des Nachrichtenautors unterscheidet. RFC 9989 §4.4 verwendet die Autorendomäne und authentifizierte Identifikatoren für Ausrichtung.
Lesen Sie jede Signatur einer kontrollierten Nachricht
Senden Sie einen Test vom Alias über denselben Client, dieselbe API oder dieselbe delegierte Postfachroute wie in der Produktion. Exportieren Sie die empfangene Nachricht, ohne sie zu bearbeiten. Identifizieren Sie jede DKIM-Signature , ihre d- und s-Werte und das Ergebnis des vertrauenswürdigen Empfängers. Ein Dienst kann sowohl eine Anbietersignatur als auch eine Kundendomänensignatur hinzufügen. Das erste, das von einem Tool angezeigt wird, ist möglicherweise nicht dasjenige, für das es relevant ist DMARC.
Bewerten Sie für jede bestandene Signatur die Übereinstimmung mit der empfangenen Von-Domäne. Für den strengen Modus ist eine genaue Domänenübereinstimmung erforderlich RFC 9989 §3.2.10. Der entspannte Modus ermöglicht dasselbe Organisationsbereich unter RFC 9989 §4.10.2. Zwei unterschiedliche registrierte Domänen stimmen nicht überein, nur weil eine in einem Verwaltungsportal ein Alias der anderen ist.
Verwenden Sie ein kleines Identitätsarbeitsblatt
Veranschaulichender Fall unter der Annahme unterschiedlicher Organisationsdomänen und einer anwendbaren DMARC Richtlinie: Die primäre Adresse ist person@company.example , während der ausgehende Alias person@newbrand.example ist. Der Empfänger sieht From bei newbrand.example und eine vorübergehende Signatur mit d=company.example. Diese Signatur stimmt nicht mit newbrand.example überein. Wenn eine andere Passsignatur d=newbrand.example, stellt diese zweite Signatur einen ausgerichteten DKIM Pfad bereit.
Zeichnen Sie beide Ergebnisse auf, anstatt die gesamte Nachricht als unsigniert zu bezeichnen oder zu sagen, dass DKIM fehlerhaft ist. Eine gültige Signatur unter der primären Domäne ist weiterhin gültiges DKIM . Die fehlende Eigenschaft ist die Ausrichtung für den Alias. Auswerten SPF separat, bevor das gesamte DMARC -Ergebnis zugewiesen wird. Dieses Arbeitsblatt ist ein synthetisches Beispiel und kein Beweis für das Alias-Verhalten eines Dienstes.
Fordern Sie die unterstützte Lösung an
Fragen Sie, ob der Anbieter Alias-Mails mit der Alias-Domain signieren kann und ob dies das Hinzufügen der Domain als eindeutige Absenderidentität erfordert. Rufen Sie die aktuellen DNS Eintragsnamen, Eintragstypen und Werte ab. Überprüfen Sie, wer die DNS Zone kontrolliert und ob die vorgeschlagene Änderung im Widerspruch zu einer bestehenden steht Wähler.
Kopieren Sie einen öffentlichen Schlüssel der Primärdomäne nicht manuell und gehen Sie nicht davon aus, dass der Dienst einen neuen d-Wert verwendet. DNS Veröffentlichung kann einen beliebigen Unterzeichner nicht anweisen, seine Identität zu ändern. Die Sendekonfiguration und das veröffentlichte Verifizierungsmaterial müssen übereinstimmen.
Behalten Sie den Alias in Lebenszyklusüberprüfungen bei
Wiederholen Sie den Test für Antworten, mobile Clients und von der Anwendung generierte Nachrichten, wenn diese Routen verwendet werden. Bewahren Sie beim Geschäftsinhaber des Alias eine Karte vom Selektor zum Anbieter und ein datiertes Muster auf. Überprüfen Sie bei der Migration oder Außerbetriebnahme, ob andere Identitäten immer noch auf denselben Anbieter angewiesen sind, bevor Sie delegierte Datensätze entfernen.
Die Abschlussanweisung sollte angeben, welcher Alias und welche Route getestet wurden, welche D-Domäne übergeben wurde und ob sie ausgerichtet war. Wenn ein Produkt die erforderliche Identität nicht bereitstellen kann, dokumentieren Sie diese Einschränkung und wählen Sie ein unterstütztes Sendedesign, anstatt den Alias ohne Einschränkung als authentifiziert zu melden.
Notieren Sie die nächste Entscheidung
Verwenden Sie eine Zeile pro tatsächlicher Route: angeforderter Alias, empfangener Absender, jedes D/S-Paar, vertrauenswürdiges Ergebnis, Ausrichtungsmodus und verbleibende Lücke. Ein primärer Domänendurchgang mit einem nicht verwandten Alias „From“ ist ein gültiger DKIM , aber kein ausgerichteter DKIM . Bezeichnen Sie die gesamte Nachricht nicht als DMARC Fehler, bis SPF und die anwendbare Richtlinie ausgewertet wurden. Hier wird keine anbieterspezifische Alias-Fähigkeit oder ein Live-Ergebnis geltend gemacht.