Trennen Sie die SEND-Domänenauswahl von Concep von der Signaturaktivierung
Conceps Beamter Leitfaden zur Domainauswahl, aktualisiert am 18. September 2020, unterscheidet Unternehmens-Sendedomänen von Subdomänen. Es ist Signieren mit DKIM Guide, aktualisiert am 2. Juli 2020, beschreibt einen vom Support unterstützten Schlüssel- und Aktivierungsworkflow. Diese datierten Anweisungen bieten einen konkreten Ausgangspunkt, die aktuelle Anwendbarkeit des Produkts bleibt jedoch offen. Dieser Artikel behauptet nicht, dass jedes heutige Concep SEND-Konto dieselbe Infrastruktur oder dieselben Kontrollen verwendet.
Die erste Entscheidung besteht darin, welche Domain die Kampagne in ihrer Absenderadresse verwenden wird und ob für gehostete Links ein separater Markenname erforderlich ist. Im Domain-Leitfaden heißt es, dass sowohl Unternehmensdomains als auch Subdomains zum Senden verwendet werden können, während in der dokumentierten Anordnung nur Subdomains Kampagnenlinks hosten können. Ohne diese Subdomain-Auswahl werden Links auf emailcc.com gehostet. Betrachten Sie einen erfolgreichen Markenlink nicht als Beweis dafür, dass die Absenderdomäne authentifiziert ist.
Bereiten Sie eine Bestandsaufnahme mit der beabsichtigten sendenden Domäne, der Linkdomäne, dem Konto und dem zuständigen DNS Administrator vor. Identifizieren Sie bestehende Verwendungen des vorgeschlagenen Namens, bevor Sie sich darauf festlegen. Eine Domäne, die mit Mitarbeiter-Mail oder einem anderen Marketingsystem geteilt wird, erfordert Koordination; Es sollte nicht einfach deshalb neu konfiguriert werden, weil ein Kampagnenbesitzer eine Absenderadresse bearbeiten kann. Für dieses Manuskript wurde kein Zugriff auf Konto- oder DNS Einstellungen vorgenommen.
Sehen Sie sich die historischen Anweisungen für Subdomains und Unternehmensdomains an
Für die Subdomain-Anordnung spezifiziert der Leitfaden 2020 a CNAME zeigt auf emailcc.com . Für eine Unternehmens-Sendedomäne wird Folgendes angegeben: SPF Autorisierung mit include:emailcc.com. Behalten Sie die Unterscheidung bei, anstatt den Subdomain-Alias an der Zonenspitze der Organisation zu platzieren oder davon auszugehen, dass derselbe Datensatz beiden Zwecken dient. Bestätigen Sie die aktuelle, vom Anbieter ausgegebene Konfiguration, bevor Sie eine Produktionsänderung vornehmen. Leitfaden zur Domainauswahl von Concep
Der Wortlaut des Leitfadens zum Anhängen eines vollständigen SPF Beispiels sollte nicht wörtlich als Anweisung zum Verketten zweier v=spf1 -Richtlinien verstanden werden. Unter RFC 7208 , Abschnitt 3.2, darf eine Domäne nicht mehrere Datensätze veröffentlichen, die dazu führen, dass mehr als eine SPF Richtlinie ausgewählt wird. Führen Sie die genehmigte Autorisierung in die bestehende Richtlinie ein und behalten Sie andere legitime Absender bei. Fügen Sie keine zweite Versionsmarkierung ein und ersetzen Sie nicht stillschweigend den Terminal-Qualifizierer.
Ein CNAME Besitzer benötigt außerdem eine Konfliktprüfung. Der vorgeschlagene Datensatz stellt keine Berechtigung zum Überschreiben bestehender E-Mail-, Website- oder Verifizierungsabhängigkeiten dar. Notieren Sie den vollständigen Eigentümer und das Ziel und vergleichen Sie diese mit der Namenskonvention des DNS Editors. Ein Editor, der den Zonennamen anhängt, kann ein unbeabsichtigtes doppeltes Suffix erzeugen, wenn die Eingabe kopiert wird, ohne ihre Interpretation zu überprüfen.
Bestätigen Sie die sendende Domäne, bevor Sie DKIM anfordern
Der DKIM In der Anleitung heißt es, dass vor der DKIM -Anfrage bereits eine Subdomain oder Unternehmensdomain bei Concep eingerichtet werden muss. Der Support stimmt sich dann mit der IT ab, um einen Schlüssel zu generieren, den das DNS Team des Kunden als veröffentlicht TXT Eintrag. Der Artikel ist nicht wiederverwendbar Wähler oder öffentlicher Schlüssel für alle Kunden. Verwenden Sie den tatsächlich bereitgestellten Eigentümer und Wert für die beabsichtigte Domäne und behalten Sie die dieser Änderung beigefügte Anforderungsreferenz bei. Konzeptunterzeichnung mit DKIM
Eine sinnvolle vorgeschlagene Übergabe identifiziert die sendende Domäne, den Kontoumfang, DNS Betreiber und den erwarteten Abschlussnachweis. Es müssen keine Kampagnenempfänger, vertraulichen Inhalte oder Anmeldeinformationen enthalten sein. Das Senden einer Supportanfrage ist eine externe Kommunikation und erfordert einen autorisierten Operator; Dieser Leitfaden erstellt weder ein Ticket noch impliziert er, dass eines eingereicht wurde. Die aktuelle Berechtigung der Domain für den dokumentierten Prozess bleibt bis zur Bestätigung ungeklärt.
Überprüfen Sie die vorhandenen Daten vor der Veröffentlichung im angeforderten Selektor. Ein älterer Schlüssel bedient möglicherweise weiterhin aktiven Datenverkehr und ein Ersatz erfordert möglicherweise eine Koordination. Der öffentliche DNS Schlüssel ist keine Anfrage nach dem privaten Signaturschlüssel des Anbieters. Halten Sie die Unterscheidung explizit, damit eine Support-Übergabe nicht zu einer unnötigen Weitergabe von Anmeldeinformationen oder einer nicht überprüften Änderung der Signaturverantwortung führt.
Behalten Sie den anbieterseitigen Aktivierungsschritt bei
Der historische DKIM Workflow endet nicht, wenn der TXT Datensatz gespeichert wird. Es heißt, dass der Kunde den Support nach der Veröffentlichung informiert; Concep überprüft die Verbreitung und schaltet die relevanten Konten auf seine dedizierte DKIM Mailserver-Anordnung um. Anschließend wird eine Provider-Testnachricht von einem Konto und eine Prüfung auf dkim=pass. Betrachten Sie dies als dokumentierte Abfolge und nicht als Beweis dafür, dass ein Girokonto diese Aktionen ausgeführt hat. Konzeptunterzeichnung mit DKIM
Zeichnen Sie die Abschlussbestätigung des Anbieters getrennt von DNS Veröffentlichung auf. Die Unterscheidung ist wichtig, da ein korrekt veröffentlichter Schlüssel nicht dazu führen kann, dass ein unabhängiges sendendes System damit signiert. Wenn der Anbieter angibt, dass der aktuelle Workflow abweicht, aktualisieren Sie den Implementierungsplan anhand dieser kontospezifischen Beweise, anstatt die historische Reihenfolge einer neuen Produktversion aufzuzwingen. Erfinden Sie kein Enable Signing-Steuerelement, das der zitierte Workflow nicht dokumentiert.
Die Testbeschreibung des Anbieters legt einen nützlichen DKIM Prüfpunkt fest, dkim=pass allein beweist dies jedoch nicht Ausrichtung mit der sichtbaren Autorendomäne der Kampagne. RFC 6376 , Abschnitt 3.5 Identifiziert die d=-Signaturdomäne und den s=-Selektor der Signatur. Erfassen Sie diese Werte durch einen autorisierten Beweisprozess und verknüpfen Sie sie mit der genehmigten Konfiguration. Eine erfolgreiche Signatur, die zu einer anderen Dienstidentität gehört, ist ein anderes Ergebnis.
Überprüfen Sie SPF und DMARC auf der tatsächlichen Route
SPF wertet die SMTP Identität aus, nicht nur die vom Kampagneneditor angezeigte Adresse. RFC 7208 , Abschnitt 2.4 beschreibt die POST VON Identität, während Abschnitt 4.6.4 Grenzen für ausgewertete DNS-abhängige Begriffe festlegt. Überprüfen Sie die tatsächliche Umschlagdomäne und die vollständige Richtlinie, einschließlich verschachtelter Abhängigkeiten. Eine sichtbare Include-Zeichenfolge ist weder ein Beweis dafür, dass ein Empfänger diese Richtlinie verwendet, noch eine vollständige Evaluierungsbudgetbewertung.
RFC 9989 , Abschnitt 4.4 Fügt eine Ausrichtung zwischen der Autorendomäne und einer vorübergehend authentifizierten Identität hinzu. Durch das Bestehen eines angepassten SPF oder eines angepassten DKIM kann diese Authentifizierungsbedingung erfüllt werden. Behaupten Sie nicht, dass der historische Anbietertest von Concep jeden schließt DMARC Voraussetzung ist oder dass alle Domains in einem Multi-Marken-Konto das gleiche Ergebnis liefern. Jede beabsichtigte Identität benötigt ihre eigene Evidenzgrenze.
Die umfassende Zusicherung der Quelle hinsichtlich der Nicht-Spam-Zustellung ist keine Garantie. Authentifizierung, SMTP Akzeptanz, Ordnerplatzierung und Engagement sind unterschiedliche Beobachtungen. Eine Kampagne ohne aufgezeichnete Aufrufe gilt somit nicht als unauthentifiziert oder blockiert. Nutzen Sie tatsächliche Diagnosebeweise und vermeiden Sie weitreichende Anfragen auf eine Zulassungsliste für Empfänger als Ersatz für die Identifizierung des Fehlers. Eine solche Anfrage oder Prüfung wurde hier nicht gestellt.
Fiktive Diagnose: veröffentlichter Schlüssel, unvollendeter Anbieterwechsel
Ein fiktiver Berufsverband, Alder Council, erhält vom Support einen DKIM Wert und bittet sein DNS Team, ihn zu veröffentlichen. Der Kampagneninhaber markiert das Projekt als abgeschlossen, sobald das Änderungsticket geschlossen wird. Eine spätere Bereitschaftsprüfung ergibt keine Bestätigung dafür, dass die anbieterseitige Kontoumstellung oder der beschriebene Test stattgefunden hat. Das Team erfasst DNS Veröffentlichung daher als vollständigen Beweis innerhalb des fiktiven Falles, lässt die Sendebereitschaft jedoch ungeklärt.
Der vorgeschlagene nächste Schritt besteht darin, eine Bestätigung des autorisierten Anbieters einzuholen und dann harmlose Nachrichtenbeweise auf die beabsichtigte Absenderidentität zu prüfen. Es geht nicht darum, den Schlüssel wiederholt auszutauschen oder davon auszugehen, dass allein durch Warten das Signieren aktiviert wird. Dieses Beispiel ist fiktiv: Es stellt kein echtes Ticket, DNS Beobachtung, keine Kontomigration oder empfangene Nachricht dar.
Leeres Akzeptanzarbeitsblatt und Freigabegrenze
- Girokonto, Produktweg und Anwendbarkeit der datierten Leitfäden: ______
- Sendende Domain versus Link-Hosting-Domain und bestehende Abhängigkeiten: ______
- Genehmigte SPF -Autorisierung in einer kohärenten Richtlinie zusammengefasst: ______
- Supportanfrage-Referenz und Domäneneinrichtungsvoraussetzung: ______
- Ausgestellter DKIM Eigentümer, öffentlicher Wert und DNS Veröffentlichungsnachweis: ______
- Aktivierungs- oder Übergangsbestätigung des Anbieters: ______
- Autorisierte Nachricht d=, s=, Umschlagdomäne und vertrauenswürdige Ergebnisse: ______
- DMARC -Ausrichtungsbewertung, verbleibende Ausnahmen und Eigentümerentscheidung: ______
Die ursprünglichen Implementierungsnachweise des Katalogs, die menschliche Überprüfung, die Anwendbarkeit der Quelle, die Produktionswege, die visuelle Zugänglichkeit und die Freigabe durch den Eigentümer bleiben offen. Der historische öffentliche Workflow unterstützt diesen Dokumentarentwurf; Es stellt weder die aktuelle Mandantenausführung her, noch autorisiert es Veröffentlichungen, Supportanfragen oder DNS Änderungen.