Umfang- und anbieterspezifische Konfiguration
Atlassian Statuspage trennt eine benutzerdefinierte Statusseiten-Webdomäne von einer benutzerdefinierten Absenderadresse für Benachrichtigungen. Eine funktionierende Website CNAME E-Mails werden nicht authentifiziert. Der E-Mail-Workflow verfügt außerdem über mehrere Zustellungsanbieter. Vervollständigen Sie daher alle angezeigten Anbieterdatensätze, anstatt beim ersten erfolgreichen Anbieter anzuhalten DKIM aufstellen.
Gehen Sie zu „Ihre Seite“, „Seite und E-Mail anpassen“ und dann „E-Mail anpassen“. Legen Sie „Von E-Mail senden“ fest, konfigurieren Sie optional „Auf E-Mail antworten“ und speichern Sie E-Mail-Anpassungen. Folgen Sie dem neuen Link oder öffnen Sie Ihre Seite, DNS Konfiguration. Erfassen Sie die Werte im Abschnitt „Benachrichtigung von E-Mail“. Der Eigentums TXT verwendet das Format status-page-domain-verification=<ORGANIZATION_CODE>; Der tatsächliche Organisationscode muss aus dem Konto stammen.
Der aktuelle DNS Leitfaden erfordert SPF Autorisierung einschließlich stspg-customer.com . Integrieren Sie include:stspg-customer.com in die entsprechende bestehende Richtlinie, nicht in eine zweite SPF Eintrag. Das Mailgun Beispiel dient der Veranschaulichung und stellt keine Erlaubnis zum Hinzufügen unabhängiger Dienste dar. Veröffentlichen Sie den DKIM Eintrag für Anbieter Nr. 1, Mailgun , und die drei CNAME Einträge für Anbieter Nr. 2, SendGrid , unter Verwendung der aktuellen Werte des Kontos. Der Leitfaden enthält einen separaten Migrationspfad von älteren DKIM Schlüsseln zu CNAMEs. Machen Sie einen Arbeitsdatensatz nicht ungültig, es sei denn, Sie führen die genehmigte Migration absichtlich durch.
Eine wichtige Grenze ist die bestehende Mailgun Nutzung: Statuspage gibt an, dass dieselbe Domain nicht ein zweites Mal hinzugefügt werden kann, wenn ein anderer Dienst Mailgun bereits verwendet. Die empfohlene Problemumgehung ist eine dedizierte Von-Subdomäne, z. B. notifications.example.com . Diese illustrative Subdomain benötigt noch einen eigenen angezeigten Aufbau und entsprechendes DMARC Auswertung.
Verwenden Sie „Alle Datensätze nach der Veröffentlichung erneut validieren“. Atlassian sagt, dass der authentifizierte und signierte Versand innerhalb von 24 Stunden nach der Validierung beginnt und dass die Aufzeichnungen stündlich überprüft werden und vorhanden bleiben müssen. Wenn nur ein Anbieter konfiguriert ist, kann ein systemweites Failover dazu führen, dass Nachrichten noreply@statuspage.io verwenden. Bei beiden Anbieterkonfigurationen handelt es sich daher um eine Kontinuitätsmaßnahme und nicht um redundantes Durcheinander.
Die Entscheidung, die zählt
Testen Sie die Bereitschaft des Anbieters und die Kontinuität des Markensenders. Ein konfigurierter Lieferpartner ist nicht das vollständige Setup.
Überprüfen Sie die veröffentlichten Datensätze und den tatsächlichen Sendepfad
Notieren Sie vor der Bearbeitung den Änderungseigentümer, das sendende Produkt, die Domäne, das genehmigte Wartungsfenster und frühere DNS Antworten. Erhalten Sie die aktuellen Datensatzwerte vom benannten Konto oder vom dokumentierten Anbieter-Workflow. Trennen Sie die vom Anbieter bereitgestellten Werte von den Auswahlmöglichkeiten, die Ihre Organisation kontrolliert, wie z. B. DMARC Richtlinie und Berichtsempfänger. Vorhandenes Postfach MX , unabhängige Überprüfung TXT Datensätze und aktive DKIM Selektoren sind keine Bereinigungskandidaten, nur weil ein neuer Dienst hinzugefügt wird.
Fragen Sie nach der Veröffentlichung die maßgeblichen Nameserver nach jedem genauen Eigentümer und Datensatztyp ab. Notieren Sie die Abfragezeit, den antwortenden Server und die vollständige Antwort. Vergleichen Sie TXT Zeichenfolgen als einen logischen Wert, wobei die DNS Antwort sie in Zeichenfolgen aufteilt. Überprüfen Sie CNAME Ziele sowie den Startalias. Vergleichen Sie dann eine rekursive Resolver-Antwort, um Caching-Unterschiede zu identifizieren. Eine erfolgreiche Anbietervalidierung ist ein nützlicher Nachweis der Konfiguration, sie stellt jedoch nicht fest, was ein tatsächlicher Empfänger erhalten hat.
Senden Sie nur einen autorisierten Test über den vorgesehenen Produktweg an einen kontrollierten Empfänger. Behalten Sie die Rohnachricht und die des vertrauenswürdigen Empfangssystems bei Authentication-Results. Notieren Sie die sichtbare Absenderdomäne, SMTP POST VON oder beobachtet Return-Path Domäne, alle DKIM d=- und s=-Werte, SPF und DKIM Ergebnisse und das DMARC Ergebnis des Empfängers. Eine bestandene SPF oder DKIM Prüfung unterstützt DMARC nur, wenn ihre authentifizierte Domäne mit der sichtbaren Von-Domäne gemäß der geltenden Richtlinie übereinstimmt. Antwortadressen und Markenanzeigenamen sind nicht vorhanden Ausrichtung Identitäten. RFC 7208 , RFC 6376 und RFC 9989 liefern die Protokollgrundlage für diese Unterscheidungen.
Akzeptanzarbeitsblatt, Wiederherstellung und Beweisgrenzen
Dies ist ein Original-Abnahmearbeitsblatt, kein Bericht über Live-Tests. Markieren Sie jedes Gate als ausstehend, bis Beweise vorliegen: Kontoumfang bestätigt; vorheriger DNS erfasst; genauer neuer Besitzer/Typ/Wert veröffentlicht; Anbieterverifizierung abgeschlossen; beabsichtigte ausgeübte Route; empfangene Identitäten aufgezeichnet; ausgerichtete Authentifizierung bestätigt; andere Absender bleiben davon unberührt. Weisen Sie jedem Tor eine Personen- und Beweisdatei zu. Ein rotes Tor blockiert den Rollout, selbst wenn das Anbieter-Dashboard grün ist.
Wenn ein Test fehlschlägt, unterscheiden Sie zunächst zwischen fehlender Veröffentlichung, veralteten zwischengespeicherten Daten, inaktiver Anbieterkonfiguration, falscher ausgehender Route und nicht ausgerichteter Authentifizierung. Beheben Sie den kleinsten festgestellten Mangel und führen Sie eine erneute Prüfung durch. Schwächen Sie DMARC nicht und löschen Sie nicht die Datensätze anderer Absender, nur um einen Test zu bestehen. Wenn eine Änderung vorhandene E-Mails beeinträchtigt, verwenden Sie den genehmigten Wiederherstellungsplan und die erfasste Konfiguration vor der Änderung und koordinieren Sie alle Absenderänderungen auf Anbieterseite sowie DNS . Behalten Sie alte Schlüssel bei, solange Nachrichten in der Warteschlange oder eine genehmigte Überschneidung diese noch erfordern.
Für dieses Manuskript war kein Kunde, keine maßgebliche Vorher-/Nachher-Änderung oder tatsächlich empfangene Nachricht verfügbar. Die erhaltenen Quellen unterstützen den dokumentarischen Workflow; Sie genügen nicht dem beauftragten Live-Evidence-Gate. Die Prüfung durch einen unabhängigen Prüfer und die menschliche KMU-Genehmigung stehen noch aus. Beschreiben Sie diesen Leitfaden nicht als vor Ort validiert und veröffentlichen Sie ihn nicht so, als hätte er diese Tore passiert.
Verwenden Sie ein Provider-für-Provider-Kontinuitätsbuch
Der schriftliche Fall SP-01 geht davon aus, dass der benutzerdefinierte From status@notifications.example.com , Mailgun Konfiguration abgeschlossen ist und der SendGrid Eintragssatz fehlt. Ein festgelegtes, von Mailgun übermitteltes Beispiel hat den vertrauenswürdigen DKIM Pass d=notifications.example.com, s=demo1; SPF ist unbekannt. Dieses Beispiel liefert eine genaue DKIM Ausrichtung, stellt jedoch keine Markenkontinuität durch SendGrid her. Der Eigentümer der Vorfallkommunikation muss das fehlende Provider-Setup beheben oder das dokumentierte Standard-Absender-Fallback-Risiko ausdrücklich akzeptieren, bevor er Kontinuität beansprucht. Veranlassen Sie keinen Ausfall und benachrichtigen Sie keine echten Abonnenten, diesen Lehrfall zu testen. Schließen Sie die Kontovalidierung ab und verwenden Sie einen autorisierten kontrollierten Test, sofern dies unterstützt wird. Ein unbeobachteter Failover bleibt unbeobachtet. Es wurde kein Vorfall oder Failover ausgeführt.
Behalten Sie die Durchsetzungsgrenze bei
RFC 9989 Abschnitt 7.4 erfordert für die Veröffentlichung von Domains ein gültiges DKIM , nicht nur SPF p=rejectund warnt vor der Interoperabilität von indirekter E-Mail und Mailinglisten. Ein einziger erfolgreicher Direktnachrichtentest ist kein Beweis dafür, dass jede legitime Route für strengere Richtlinien bereit ist. Behalten Sie den vorhandenen zugelassenen Schutz bei, während Sie die tatsächliche Lücke diagnostizieren. Jede politische Änderung erfordert eine eigene Entscheidung.