Ein Anbieter kann gültig ausgeben DKIM Signaturen ohne Unterstützung der Signaturdomäne Ihrer Organisation. Diese Einschränkung ist wichtig, wenn die Signatur des Dienstes nicht mit der Domäne übereinstimmt, die Kunden in „Von“ sehen. Legen Sie die genaue Einschränkung fest, bevor Sie DNS ändern oder den Dienst ersetzen.
Bestätigen Sie, was der Anbieter tatsächlich unterstützt
Fordern Sie aktuelle Unterlagen zu der von Ihnen verwendeten Kontostufe, Sendeschnittstelle und dem Domänentyp an. Eine verifizierte Absenderadresse, eine benutzerdefinierte Tracking-Domain oder ein gebrandeter Rückpfad sind kein Beweis für die benutzerdefinierte DKIM Unterstützung. Erhalten Sie eine rohe empfangene Nachricht von der tatsächlichen Route und zeichnen Sie die d- und s-Werte jeder Signatur sowie die Verifizierungsergebnisse des vertrauenswürdigen Empfängers auf.
RFC 6376 definiert d als Signaturdomäne und verwendet s mit dieser Domäne, um Verifizierungsdaten zu finden. Das Veröffentlichen eines Schlüssels unter Ihrer eigenen Domäne kann keine Änderungen an einer Signatur vornehmen, die der Anbieter erstellt. A CNAME benötigt ebenfalls eine vom Anbieter unterstützte Signaturkonfiguration; Ein DNS Alias allein weist einen Dienst nicht an, für Sie zu signieren.
Prüfen Sie, ob ein anderer ausgerichteter Pfad existiert
Mit einer anwendbaren Richtlinie und keinem ungelösten Bewertungsfehler, DMARC kann entweder durch eine vorbeiziehende Linie hindurchgehen SPF oder DKIM Ergebnis. Bewerten Sie die tatsächliche Leistung des Dienstes POST VON Domain- und SPF -Ergebnis separat. Ein unterstützter benutzerdefinierter Rückpfad kann einen angepassten SPF bereitstellen, selbst wenn benutzerdefiniertes DKIM nicht verfügbar ist. Überprüfen Sie die Ausrichtung Modus- und Domänenbeziehung; Ein anbietereigener Rückgabepfad stimmt nicht, nur weil Sie für das Konto bezahlen.
Illustrativer Fall: Mail verwendet From= notices@brand.example und übergibt DKIM mit d=vendor.example. Seine MAIL FROM-Domäne ist bounce.brand.example und SPF Pässe. Unter der Annahme, dass die Beziehung zwischen Organisation und Domäne geeignet ist, kann eine entspannte SPF Anpassung DMARC erfüllen. Bei strikter SPF Ausrichtung ist die Subdomain keine exakte Übereinstimmung. Dies ist ein synthetisches Entscheidungsbeispiel, keine Behauptung über einen Anbieter.
RFC 9989 Die Abschnitte 7.4 und 8 erfordern die Veröffentlichung von Domänen p=reject sich für einen DMARC -Pass nicht ausschließlich auf SPF zu verlassen und gültige DKIM Signaturen anzuwenden. Ein SPF -Durchgang mit direkter Zustellung ist daher kein vollständiges p=reject Bereitstellungsdesign. Beheben Sie den fehlenden Aligned-DKIM-Pfad, bevor Sie diesen Dienst als für diese Richtlinie bereit betrachten.
Beschreiben Sie SPF nicht als identischen Ersatz für ausgerichtetes DKIM . Die Weiterleitung kann die Verbindungs-IP ändern und SPF stören, während eine intakte Ausrichtung gewährleistet ist DKIM Signatur kann überleben. Bewerten Sie die für Ihre Benutzer wichtigen Routen, anstatt sich auf einen Direktzustellungstest zu verlassen.
Vergleichen Sie unterstützte Alternativen
Die praktischen Möglichkeiten bestehen darin, den Dienst mit einem dokumentierten SPF-Pfad beizubehalten, der mit der Domänenrichtlinie und den akzeptierten Einschränkungen kompatibel ist, das Senden an einen Dienst zu verlagern, der die erforderliche DKIM Identität unterstützt, oder ein unterstütztes autorisiertes Relay zu verwenden, das die endgültige Nachricht signiert. Für jedes sind Tests und ein Eigentümer erforderlich. Ein Relay muss das erforderliche Anwendungsverhalten beibehalten und nach der Verarbeitung von Inhaltsänderungen signieren. Das bloße Hinzufügen einer unabhängigen Signatur löst die Ausrichtung nicht.
Das Ändern der sichtbaren Absenderdomäne ist eine weitere Produktentscheidung und keine versteckte technische Lösung. Dies wirkt sich auf die Erkennung und Antworten aus und die Ersatzdomäne benötigt weiterhin eine gültige Authentifizierung. Vermeiden Sie es, die DMARC Richtlinie der gesamten Organisation zu schwächen, nur um einen undokumentierten Sendepfad zu verbergen.
Notieren Sie die akzeptierte Einschränkung
Bewahren Sie die Leistungserklärung des Anbieters, den Nachweis der empfangenen Nachricht, den gewählten Ausrichtungspfad, den Geschäftsinhaber und den Überprüfungsauslöser auf. Testen Sie für den Dienst relevante Transaktionsnachrichten und Weiterleitungsszenarien. Bleibt eine Einschränkung bestehen, geben Sie die Expositions- und Migrationsentscheidung explizit an. Der Abschluss bedeutet eine verifizierte unterstützte Route oder eine eigene Ausnahme, kein grüner DNS Screenshot.
Verwenden Sie einen gefüllten Entscheidungsdatensatz
Betrachten Sie diese explizit fiktive Zwei-Routen-Matrix. Abrechnungs-API A hat From= brand.example , d=vendor.example, Wähler Vendor1, MAIL FROM= bounce.brand.example , Roh- SPF -Pass und Roh- DKIM Pass. Gehen Sie von einer entspannten SPF -Ausrichtung und der angegebenen Freigabe aus Organisationsbereich: Sein erfolgreicher Weg ist nur auf SPF ausgerichtet. Ersatz-Relay B hat From= brand.example , d=brand.example, Selector Relay2 und MAIL FROM= vendor.example , wobei beide Rohprüfungen bestanden wurden: Sein erfolgreicher Pfad ist nur DKIM ausgerichtet. Jede Fähigkeit und jedes Ergebnis wird hier vorausgesetzt und nicht von einem Anbieter beobachtet.
Diese Feldvergleiche erklären die angenommenen Ergebnisse; Es wird keine Spielausführung oder Anbieterverifizierung beansprucht. Die Abrechnungs-API A zeigt ein reines SPF-Ergebnis, keinen akzeptablen alleinigen Pfad für eine p=reject Bereitstellung. Bevor Sie eines der Designs bereitstellen, besorgen Sie sich datierte routenspezifische Anweisungen des Anbieters, generierte DNS Werte, unformatierte empfangene E-Mails und ein Ergebnis eines vertrauenswürdigen Empfängers. Vergleichen Sie beabsichtigte und beobachtete Identitäten, testen Sie kritische Formate und relevante Weiterleitungen und dokumentieren Sie, dass der Eigentümer etwaige verbleibende Einschränkungen akzeptiert. Diese realen Akzeptanzfelder stehen noch aus.
Wählen Sie den unterstützten nächsten Schritt
- Unbekannte Funktion: Aktuelle Anweisungen zur genauen Kontostufe und Versandroute erhalten; Erraten Sie keine DNS Werte.
- Nur angepasster SPF verfügbar: Direktzustellungslimits und die aktuelle Richtlinie erfassen; Verwenden Sie es nicht als einzigen DMARC Pfad für p=reject.
- Unterstütztes Signatur-Relay verfügbar: Überprüfen Sie das Anwendungsverhalten, den endgültigen Inhalt, das ausgerichtete D= und die Schlüsselverwahrung vor der Migration.
- Kein geeigneter Weg: Anbieter wechseln oder eine explizite Produktentscheidung über die From-Identität treffen.
- Abschluss: Speichern Sie den Nachweis der empfangenen Nachricht, die verbleibenden Einschränkungen, den verantwortlichen Eigentümer und den Auslöser für die nächste Überprüfung.