Definieren Sie zunächst die Outreach-Identität
Eine Pressekampagne kann im Editor korrekt aussehen, beim Verlassen jedoch eine unerwartete Absenderidentität aufweisen. Bevor Sie DNS ändern, notieren Sie die Organisation, die beabsichtigte Absenderadresse, die für die Öffentlichkeitsarbeit verantwortliche Person und ob es sich bei der Route um eine Kampagne oder einen individuellen Pitch handelt. Beziehen Sie vorhandene Entwürfe und Integrationen in diese Bestandsaufnahme ein. Die Wahl des Absenders ist Teil des Akzeptanztests und kein Detail, das aus dem Erscheinungsbild der Nachrichtenredaktion abgeleitet werden kann.
Prezly bietet eine gebrauchsfertige prezlymail.com -Adresse und unterstützt verifizierte Unternehmensdomänenadressen. Es ist Absender-Adress-Leitfaden Beschreibt das Hinzufügen der Adresse, das Auswählen der Domain und das Veröffentlichen von drei oder vier ausgegebenen CNAME Aufzeichnungen und Ausführen der Statusprüfung. Verwenden Sie die für die ausgewählte Domäne angezeigten Werte. Die Beispiele in einem öffentlichen Artikel geben Aufschluss über das Design des Dienstes. Es handelt sich nicht um Datensätze, die in die Zone einer anderen Organisation kopiert werden können.
Halten Sie Website- und E-Mail-Konfiguration getrennt
Ein funktionierender Hostname der Nachrichtenredaktion ist kein Beweis für die Authentifizierung der Kampagnen-E-Mail. Prezly trennt darin ausdrücklich die Einrichtung einer benutzerdefinierten Website-Domäne von der Bereitschaft der Absenderdomäne Entwicklerhandbuch. Geben Sie der DNS Änderung einen bestimmten Zweck: Autorisieren Sie die genehmigte Outreach-Domain, anstatt jeden Marken-Hostnamen in einem Vorgang zu reparieren.
Erfassen Sie die aktuellen Zonenwerte bei jedem vorgeschlagenen Datensatzeigentümer. Notieren Sie, ob der DNS Editor eine relative Bezeichnung oder einen vollständig qualifizierten Namen erwartet. Bitten Sie den Administrator, den resultierenden Namen des öffentlichen Eigentümers mit der Anweisung zu vergleichen, bevor Sie fortfahren. Wiederholte Suffixe, ein Rekord in der falschen Zone platziert oder ein vorhandener CNAME bei einem inkompatiblen Besitzer kann zu einem plausibel aussehenden Eintrag führen, der die beabsichtigte Prüfung nicht besteht. Bewahren Sie normale Geschäftsmail-Datensätze und nicht verwandte TXT Werte auf.
Bereiten Sie für eine Organisation mit mehr als einer öffentlichen Marke eine Änderungszeile pro Domäne vor. Gehen Sie nicht davon aus, dass die Validierung der eigenen Domäne der Agentur alle Kundenidentitäten autorisiert. Der Kontoinhaber sollte genehmigen, welche Personen die jeweilige Identität verwenden dürfen und welches Postfach Antworten erhält. Diese operative Entscheidung sollte aufgezeichnet werden, bevor ein neuer Standard ausgewählt wird.
Veröffentlichen Sie die ausgegebene Delegation, ohne sie zu erweitern
Prezly-Dokumente a Rückweg Subdomain und CNAME-basierte Authentifizierungsdelegation. Es heißt auch ein Vorhandenes DMARC Eintrag muss nicht neu erstellt werden und Cloudflare -Einträge müssen für dieses Setup den Nur-DNS-Modus verwenden. Überprüfen Sie das Vorhandene DMARC Lesen Sie die Richtlinie durch, bevor Sie dem Eigentümer etwas hinzufügen. Ersetzen Sie eine strengere genehmigte Richtlinie nicht durch eine Beispielüberwachungsrichtlinie, nur um eine Übereinstimmung mit dem Assistenten herzustellen. Der Anweisungen zur Absenderadresse erfordern auch, dass die Absenderdomäne vorhanden ist MX Einträge; Stellen Sie sicher, dass die Antworten das vorgesehene Postfach erreichen, anstatt eingehende E-Mails einfach umzuleiten.
Behandeln Sie jeden CNAME als fortlaufende Delegation. Halten Sie Anbieterziel, Geschäftszweck, Eigentümer und Wiederherstellungsanweisungen zusammen. Eine zukünftige DNS Bereinigung muss einen nicht verwendeten Website-Alias von einer E-Mail-Authentifizierungsabhängigkeit unterscheiden. Wenn ein vorgeschlagener Eigentümer mit einem anderen Dienst in Konflikt steht, stoppen Sie diese Datensatzänderung und holen Sie Anweisungen für das genaue Konto ein. Errate ein neues Wähler or target ist keine sichere Konfliktlösungsmethode.
SPF wertet die für die Nachricht verwendete SMTP Identität und nicht den benutzerfreundlichen Anzeigenamen aus. Wenn tatsächlich eine SPF Richtlinie erforderlich ist, behalten Sie eine Richtlinie bei diesem Eigentümer und überprüfen Sie deren vollständige DNS-Suchkosten. Sehen RFC 7208. Fügen Sie der Stammdomäne keine umfassende Autorisierung hinzu, nur weil in einer Testnachricht eine externe Übermittlungsplattform erwähnt wird.
Überprüfen Sie die Bereitschaft der Schnittstelle und der Integrationen
Speichern Sie die Domain-Statusprüfung mit Zeitstempel und der verwendeten Anweisungsrevision. Auf einen grünen Anwendungsstatus sollte ein kontrollierter Versand folgen. Es bestätigt einen Teil der Konfiguration, während die empfangene Nachricht Hinweise darauf liefert, was der Dienst tatsächlich genutzt hat.
Überprüfen Sie bei Integrationen die vorgesehene Absender-ID, Adresse, Genehmigungsstatus und Domänengültigkeit. Prezly warnt davor, dass sein serialisiertes is_verified-Feld derzeit immer wahr ist und kein Beweis für die Genehmigung oder DNS Bereitschaft ist. Es ist API-Anleitung empfiehlt außerdem explizite Absender-IDs, anstatt davon auszugehen, dass eine Standardänderung bestehende Entwürfe neu schreibt. Lassen Sie den Integrationseigentümer die ausgewählte Identität bestätigen, ohne API-Anmeldeinformationen in Screenshots oder Überprüfungsdateien preiszugeben.
Wenn eine Standardeinstellung geändert wird, testen Sie eine neu erstellte Kampagne und den entsprechenden vorhandenen Entwurf separat. Ein gespeichertes Objekt behält möglicherweise seine eigene Identität. Achten Sie bei allen Wiederherstellungsverfahren auf Präzision: Stellen Sie die Auswahl des genehmigten Absenders wieder her oder pausieren Sie die betroffene Kontaktaufnahme, anstatt alle Authentifizierungsdatensätze zu löschen, während Sie eine Anwendungseinstellung diagnostizieren.
Lesen Sie die Nachricht, die der Empfänger erhalten hat
Senden Sie eine harmlose Kampagne und einen harmlosen Pitch an kontrollierte externe Postfächer. Fügen Sie ein internes Postfach als separaten Test hinzu, wenn die interne Verteilung wichtig ist. Erfassen Sie Nachrichten-ID, UTC-Zeit, Von, Return-Path , DKIM Signaturdomäne und Selektor sowie die vertrauenswürdigen Authentifizierungsergebnisse des endgültigen Empfängers. Schwärzen Sie Empfängerdetails und Kampagneninhalte, die nicht überprüft werden müssen.
Ein DKIM Pass beweist die Validierung für die signierende Domäne. DMARC erfordert zusätzlich eine ausgerichtete Pass SPF oder DKIM Identität relativ zur sichtbaren Von-Domäne. RFC 6376 definiert die Signaturfelder und RFC 9989 definiert DMARC Ausrichtung. Notieren Sie den aktuellen Ausrichtungsmodus. Eine verwandte Subdomain ist bei strikter Ausrichtung nicht automatisch ausreichend.
Verwenden Sie nicht das Ergebnis einer Posteingangsplatzierung als gesamtes Authentifizierungsurteil. Eine Nachricht kann authentifiziert werden und dennoch aufgrund von Reputation, Empfängerregeln, Inhalt oder Sendeverhalten ungünstig gefiltert werden. Umgekehrt kann eine Nachricht auf der Zulassungsliste in einem Posteingang erscheinen, ohne dass nachgewiesen werden kann, dass die öffentliche Authentifizierungsroute korrekt ist.
Arbeitsblatt zur Prezly-Akzeptanz
Füllen Sie separate Zeilen für Kampagnen, Pitches und jede Integrationsroute aus:
- Organisation, Domäne, Geschäftsinhaber und Route: ____.
- Beabsichtigter Absender, Antwortpostfach und ggf. explizite Absender-ID: ____.
- Vorhandener Entwurf oder neu erstellter Test: ____; Standardauswahl geprüft: ____.
- Ausgegebene CNAME Besitzer und Zielreferenzen: ____; Konflikte gelöst: ____.
- Bestehende DMARC Richtlinie beibehalten oder genehmigte Änderungsreferenz: ____.
- Öffentliche DNS Antworten, Anwendungsstatus und Überprüfungszeiten: ____.
- Kontrollierter Empfänger, Nachrichten-ID und UTC-Sendezeit: ____.
- Return-Path , DKIM d= und s=, vertrauenswürdige SPF / DKIM / DMARC Ergebnisse: ____.
- Beobachteter ausgerichteter Mechanismus und Ergebnis der internen Filterung: ____.
- Release-Eigentümer, Wiederherstellungsaktion und nächster Überprüfungsauslöser: ____.
Bei einem leeren Identitäts- oder Empfängerfeld bleibt die Route unbestätigt. Erweitern Sie das Pilotprojekt nur dann, wenn der Kommunikationseigentümer und der E-Mail-Administrator sich einig sind, dass die getestete Identität diejenige ist, die für eine tatsächliche Kontaktaufnahme vorgesehen ist.
Fiktive Diagnose eines fehlgeschlagenen internen Tests
Nur fiktives Beispiel: Alder Press sieht seinen internen Test als Junk an und schlägt vor, die SPF Richtlinie der Domain zu ersetzen. Die externe Kopie verfügt über DKIM und einen DMARC Pass. Der interne Empfänger identifiziert die Nachricht mithilfe einer internen Absenderadresse als extern stammende E-Mail. Prezlys Anleitung zur Zustellbarkeit diskutiert dieses interne Testmuster. Das Team untersucht die Richtlinien dieses Empfängers, bevor es das öffentliche DNS ändert.
Eine eingeschränkte, überprüfte Empfängerausnahme kann für einen dokumentierten Geschäftsweg angemessen sein, sie darf jedoch nicht als Authentifizierungsreparatur oder Garantie einer externen Zustellung dargestellt werden. Das Team prüft außerdem die Unterdrückung und den Bounce-Beweis, wenn eine Adresse nichts empfängt. Diese Diagnose ist illustrativ; Es wurde kein Alder-Konto, keine DNS Zone oder keine Nachricht beobachtet.
Halten Sie die Akzeptanzgrenze sichtbar
Überprüfen Sie die E-Mail erneut, wenn sich der Absender ändert, DNS Migrationen durchgeführt werden, Integrationen die Identitätsauswahl ändern oder der Verifizierungsstatus verloren gegangen ist. Halten Sie den Datensatzbestand und die redigierten Header zusammen, damit ein anderer Administrator die Schlussfolgerung reproduzieren kann. Die öffentliche Dokumentation unterstützt dieses Verfahren, aber Live-Mieterinspektion, vom Konto ausgegebene Werte, DNS Tests, Nachweis empfangener Nachrichten, durchgeführte visuelle Überprüfung, menschliche KMU-Genehmigung und Veröffentlichung stehen noch aus.
Machen Sie die Integrationsübergabe explizit
Behalten Sie für eine integrationsgesteuerte Kampagne die numerische Absender-ID im Freigabedatensatz bei. Genehmigung und Domänengültigkeit sind separate Felder; Weder eine erfolgreiche Objekterstellung noch is_verified=true ist ein Ersatz. Ein Integrationsbetreiber sollte diese Zustände aufzeichnen, ohne Anmeldeinformationen zu exportieren, und dann die tatsächlich ausgewählte Identität in einer kontrollierten Kampagne überprüfen. Dies ist eine vorgeschlagene Akzeptanzprüfung und kein API-Aufruf für diesen Artikel.
Trennen Sie die Nachrichtenannahme vom Richtlinien-Rollout
Ein bestandenes, abgestimmtes SPF Ergebnis kann einer Nachrichtenbewertung genügen, rechtfertigt jedoch nicht allein das Verschieben einer gesamten Domäne in die Ablehnung. RFC 9989 Abschnitt 7.4 erfordert gültiges DKIM für die Veröffentlichung von Domains p=reject und warnt vor der Interoperabilität indirekter E-Mails. Führen Sie eine Bestandsaufnahme aller legitimen Absender und indirekten Routen durch, bevor der Richtlinieneigentümer die Durchsetzung genehmigt. Für diesen Artikel wurde keine DNS Änderung, kein Mandantenbetrieb oder kein Test der empfangenen Nachrichten durchgeführt.