Wählen Sie das Absender-Verifizierungsmodell bewusst aus
Für die eigene Domäne einer Organisation ist die SMTP2GO-Absenderdomänenüberprüfung der dokumentierte Weg zur Kundendomänenauthentifizierung. Die Einzel-E-Mail-Verifizierung ist eine andere Option und bietet nicht das Gleiche SPF Und DKIM Ausrichtung. Beginnen Sie mit den Domänen und Adressen, die Anwendungen verwenden, anstatt den schnellsten Verifizierungsbildschirm auszuwählen. SMTP2GO-Verifizierungsoptionen, Absenderdomäne und Einzelsender-E-Mail.
Listen Sie die tatsächlichen Quellen auf: Anwendungs-API-Aufrufe, SMTP Relay-Clients, Geräte und Integrationen. Notieren Sie jedes Konto oder Unterkonto, die beabsichtigte Absenderdomäne und den operativen Eigentümer. Eine gemeinsam genutzte Domäne bedeutet nicht, dass jede Route dieselben Anmeldeinformationen oder dieselbe Konfiguration verwendet. Schließen Sie Fallback-Routen explizit ein und betrachten Sie deren erfolgreiche Zustellung nicht als Test der primären Route.
SMTP2GO dokumentiert verifizierte Absender nach Bedarf und protokolliert Versuche von nicht verifizierten Absendern als abgelehnt. Die Einführungsankündigung erklärt auch dies Rückweg Subdomain-Modell und warum vorhandener Root SPF Einträge muss nicht erweitert werden. Ankündigung des verifizierten Absenders von SMTP2GO.
Erfassen Sie die drei für das Konto ausgestellten Datensätze
Fügen Sie unter Senden > Verifizierte Absender > Absenderdomänen die gewünschte Domäne hinzu und erfassen Sie die drei CNAME Aufzeichnungen. Der dokumentierte Satz umfasst die Return-Path-/ SPF -Funktion, DKIM und Tracking. Veröffentlichen Sie die aktuell ausgegebenen Werte anstelle allgemeiner Beispiele. Der Leitfaden bietet manuelle DNS -Änderungen oder einen automatisierten DNS Fluss. SMTP2GO-verifizierte Absender, Schritte eins und zwei.
Der Sender-Domain-Leitfaden ermöglicht es bestehenden DNS Subdomains, unter einer verifizierten Top-Level-Domain zu senden. Dabei handelt es sich um eine Sendeerlaubnis, nicht um einen Nachweis einer strikten Ausrichtung für jede Subdomain. Wenn die Richtlinien CNAMEs verbieten, bietet der Leitfaden auf Anfrage TXT / MX Konfiguration an; Holen Sie sich diese unterstützte Alternative, anstatt Datensätze selbst zu übersetzen.
Wählen Sie die Methode im Rahmen des Änderungsprozesses der Organisation aus. Ein automatisierter Ablauf kann Zugriff auf DNS anfordern. Überprüfen Sie daher genau, welche Zugriffe und Änderungen er vorschlägt, bevor Sie ihn gewähren. Bei der manuellen Veröffentlichung sollte weiterhin derselbe überprüfte Datensatz verwendet werden. Gewähren Sie keinen umfassenderen Zugriff, nur um das Verständnis eines Namenskonflikts zu vermeiden.
Speichern Sie für jeden Datensatz den vollständigen Eigentümer, das Ziel und die TTL. Überprüfen Sie die bestehende Verwendung der vorgeschlagenen Namen, einschließlich anderer CNAMEs, Zertifikate, Tracking-Dienste und E-Mail-Verarbeitung. Fragen Sie den Kontoadministrator nach einem unterstützten alternativen Hostnamen, wenn es zu einer Kollision kommt. Erfinden Sie kein neues Ziel und überschreiben Sie den vorhandenen Dienst nicht.
Halten Sie SPF und Tracking getrennt
Der Kundendomänen-Rückpfad von SMTP2GO ist die relevante SPF Identität. Das Hinzufügen eines Include zur Unternehmens-Root-Richtlinie ersetzt nicht den ausgegebenen Return-Path CNAME . Diese Unterscheidung ist besonders nützlich, wenn die Root-Richtlinie bereits mehrere unabhängige Dienste autorisiert. Behalten Sie diese vorhandenen Berechtigungen bei, es sei denn, eine separat überprüfte Änderung erfordert dies.
SPF prüft die in der Transaktion verwendete SMTP Identität. Seine Auswertungsregeln übertragen eine Richtlinie nicht automatisch von der sichtbaren Von-Domäne in eine andere Umschlagdomäne. RFC 7208 , Abschnitte 2.4 und 4.
Der Tracking- CNAME dient einem separaten Zweck. SMTP2GO dokumentiert die Bereitstellung des HTTPS-Zertifikats für diesen Tracking-Namen nach der Überprüfung. Ein Tracking-Problem sollte gesondert untersucht und nicht als Beweis dafür interpretiert werden, dass der DKIM Schlüssel fehlt. SMTP2GO-verifizierte Absender, Tracking-Domäne.
Erfassen Sie die Nachverfolgungsprüfung und den Zertifikatsstatus separat im Arbeitsblatt. Wenn Datenschutz- oder Kommunikationsrichtlinien die Nachverfolgung einschränken, lassen Sie diese Anwendungseinstellungen vom zuständigen Eigentümer überprüfen. Die Authentifizierungsarbeit sollte nicht stillschweigend eine unabhängige Analysefunktion aktivieren.
Überprüfen Sie den öffentlichen DNS und Kontozugriff
Überprüfen Sie die öffentlichen CNAME Antworten des autorisierenden DNS Dienstes und vergleichen Sie sie mit den ausgegebenen Datensätzen. Stellen Sie sicher, dass der DNS Editor die Domäne nicht zweimal angehängt oder das Ziel geändert hat. Wenn die Ergebnisse auf den autorisierenden Servern unterschiedlich sind, beheben Sie diese Inkonsistenz, anstatt die Domäne in SMTP2GO wiederholt neu zu erstellen.
Der Anbieterleitfaden unterstützt die Gewährung von Zugriff auf eine im Hauptkonto verifizierte Domain für ausgewählte Unterkonten. Bestätigen Sie, dass das tatsächlich sendende Unterkonto über diesen Zugriff verfügt. Gehen Sie nicht davon aus, dass eine im Hauptkonto angezeigte Domain automatisch überall nutzbar ist. Der Leitfaden identifiziert zugewiesene Domänen im Unterkonto mit einem nicht editierbaren Master-Tag; Notieren Sie diesen Nachweis für das tatsächlich sendende Konto. SMTP2GO-verifizierte Absender, Unterkontozugriff.
Notieren Sie, welchem Konto die Domäne gehört, welche Unterkonten autorisiert sind und wer diese Berechtigungen ändern kann. Behalten Sie für die Verwendung durch Kunden oder mehrere Marken die Autorisierung für die spezifische Domäne und den Absenderzweck bei. DNS Steuerung regelt nicht, ob eine bestimmte Anwendung unter dieser Marke senden darf.
Testen Sie SMTP und API-Pfade separat, sofern verwendet
In der API-Dokumentation werden API-Schlüsselauthentifizierung und Absenderüberprüfung als separate Anforderungen behandelt. Ein gültiger Schlüssel allein berechtigt nicht zur Autorisierung einer ungeprüften From-Identität. SMTP2GO-API-Leitfaden, Authentifizierung und Absenderüberprüfung.
Verwenden Sie harmlose Inhalte für kontrollierte externe Postfächer und senden Sie sie über alle Materialwege. Bewahren Sie Anwendungskennungen, UTC-Zeiten, Nachrichten-IDs und entsprechende Aufzeichnungen über Anbieteraktivitäten auf. Testen Sie ein Gerät oder eine Integration von diesem Gerät oder dieser Integration aus und nicht nur vom separaten Testskript eines Entwicklers. Behalten Sie das beobachtete From bei, auch wenn erwartet wurde, dass die Anwendung etwas anderes verwendet.
Zeichnen Sie beim Empfänger Return-Path , die vertrauenswürdige SPF Identität und das Ergebnis, jeden DKIM d- und -s-Wert und die auf DMARC Ergebnis. Überprüfen Sie den öffentlichen Schlüssel Wähler tatsächlich verwendet; Ein verifizierter, aber nicht verwendeter Selektor beweist nicht, dass die Nachricht damit signiert wurde. RFC 6376 , Abschnitte 3.5 und 6.1.
Bestimmen Sie, welche authentifizierte Domäne mit dem sichtbaren Absender übereinstimmt. Ein Subdomänen-Rückpfad kann eine lockere SPF Ausrichtung erfüllen, ohne eine strikte exakte Domänenausrichtung zu erfüllen. Ein Passing-Alignment-Mechanismus ist für DMARC ausreichend, obwohl separate Anbieter- oder Organisationsanforderungen möglicherweise beide Mechanismen erfordern. RFC 9989 , Identifier Alignment erklärt und DMARC Bewertung.
Behalten Sie DMARC Richtlinie im Besitz der Domain
DMARC Einrichtungsseite von SMTP2GO platziert die Richtlinienveröffentlichung im DNS der Domäne und nicht auf der sendenden Plattform. Behandeln Sie dies als separate Änderung auf Domänenebene, die sich auch auf andere Absender auswirkt. SMTP2GO DMARC -Anleitung, So richten Sie DMARC ein.
Verwenden Sie die aktuelle Protokolldefinition für die Pass-Entscheidung. Einige erläuternde Formulierungen des Anbieters fassen die Authentifizierung und Übermittlung in einer einfacheren Geschichte zusammen. Es sollte die Unterscheidung zwischen Ausrichtung, Richtlinie und der unabhängigen Filterung eines Empfängers nicht außer Kraft setzen. Verringern Sie nicht eine bestehende Durchsetzungsrichtlinie, nur um eine nicht verifizierte Route über eine einzelne E-Mail nutzbar zu machen.
Wenn E-Mails vor Abschluss der Übermittlung abgelehnt werden, überprüfen Sie die Absenderbestätigung, den Kontoumfang und die tatsächliche Absenderadresse. Wenn die Nachricht mit einer unerwarteten Identität zugestellt wird, überprüfen Sie die Außerkraftsetzungen und die Kontoauswahl der Integration. Wenn die Authentifizierung erfolgreich ist, die Spam-Platzierung jedoch weiterhin schlecht ist, untersuchen Sie die Reputation, die Erwartungen des Empfängers und den Inhalt separat. Das wiederholte Ändern von CNAMEs ist keine allgemeine Abhilfe für die Zustellbarkeit.
Dokumentieren Sie den Rollout- und Wiederherstellungsweg
Verwenden Sie das SMTP2GO-Domänen- und Anwendungsarbeitsblatt (erstellen Sie einen separaten Überprüfungsdatensatz mit den hier beschriebenen Feldern). Es trennt die drei DNS Funktionen, die Unterkontoberechtigung und den routenspezifischen Empfängernachweis. Erfassen Sie den genauen Grund für jede fehlgeschlagene Abnahmeprüfung und nicht nur einen roten oder grünen Status.
Unterbrechen Sie den betroffenen Anwendungsverkehr oder leiten Sie ihn über einen genehmigten, zuvor getesteten Pfad um, wenn ein Rollout fehlschlägt. Bewahren Sie Datensätze auf, die für E-Mails in der Warteschlange und funktionierende Integrationen benötigt werden. Bevor Sie eine Domäne außer Betrieb nehmen, stellen Sie sicher, dass kein Gerät, kein Client-Konto oder keine Fallback-Route mehr von ihr abhängt. Erneut testen, nachdem der DNS Host, die Anwendungsidentität oder der Unterkontozugriff geändert wurde.
Fiktiver Diagnosefall mit falschem Konto
Nur fiktiver schriftlicher Fall: S2G-01 geht davon aus, dass das Hauptkonto service.example verifiziert hat, eine Anwendung, die alerts@service.example sendet, jedoch ein Unterkonto ohne die erforderliche Domänenzuweisung verwendet und eine Übermittlungsablehnung erhält. Für diesen abgelehnten Versuch ist kein Empfänger SPF , DKIM oder DMARC Ergebnis vorhanden. Der Anwendungseigentümer muss die Kontoauswahl überprüfen und die Genehmigung für eine eng begrenzte Domänenzuweisung einholen und dann dieselbe Route testen. Ein Beispiel für ein Hauptkonto schließt das Problem mit dem Unterkonto nicht. Es wurde kein API-Schlüssel, keine Mandantenberechtigung oder keine Nachricht verwendet.
Die Annahme steht noch aus
Akzeptieren Sie nur, wenn die tatsächlichen Routen die genehmigte Domäne verwenden, ausgegebene DNS Einträge aufgelöst werden, der relevante Kontobereich überprüft wird und die Ergebnisse vertrauenswürdiger Empfänger die erforderliche Ausrichtung herstellen. Für diesen unveröffentlichten Entwurf stehen noch Live-Mandanten-, DNS und Nachrichtenprüfungen, Akzeptanz im Originalbereich, unabhängige technische Prüfung, visuelle Prüfung und menschliche KMU-Genehmigung aus.
Trennen Sie eine vorübergehende Nachricht von der Durchsetzungsbereitschaft
RFC 9989 Abschnitt 7.4 erfordert gültiges DKIM für eine Domain-Veröffentlichung p=reject und warnt vor der Interoperabilität indirekter E-Mails. Ein einzelnes abgestimmtes SPF Ergebnis allein rechtfertigt nicht die Einführung einer Ablehnungsrichtlinie. Überprüfen Sie alle legitimen Routen und Richtlinieneigentümer getrennt von dieser Anbietereinrichtung.