Omfattning och leverantörsspecifik konfiguration
Atlassian Statuspage separerar en anpassad statussida-webbdomän från en anpassad avisering Från-adress. En fungerande hemsida CNAME autentiserar inte e-post. E-postarbetsflödet har också flera leveransleverantörer, så fyll i alla visade leverantörsposter istället för att sluta vid den första lyckade DKIM inställning.
Gå till Din sida, Anpassa sida och e-post och sedan Anpassa e-post. Ställ in Skicka från e-post, konfigurera om du vill svara på e-post och spara e-postanpassningar. Följ den nya länken eller öppna Din sida, DNS konfiguration. Fånga värdena i avsnittet Avisering Från e-post. Ägarskaps- TXT använder formatet status-page-domain-verification=<ORGANIZATION_CODE>; den faktiska organisationskoden måste komma från kontot.
Den aktuella DNS guiden kräver SPF auktorisering inklusive stspg-customer.com . Inkludera include:stspg-customer.com i den tillämpliga befintliga policyn, inte en sekund SPF rekord. Dess Mailgun exempel är illustrativt och ger inte tillåtelse att lägga till orelaterade tjänster. Publicera DKIM posten för leverantör #1, Mailgun , och de tre CNAME posterna för leverantör #2, SendGrid , med hjälp av kontots aktuella värden. Guiden har en separat migreringsväg från äldre DKIM nycklar till CNAME; ogiltigförklara inte en fungerande post om du inte avsiktligt genomför den godkända migreringen.
En viktig gräns är befintlig Mailgun -användning: Statuspage säger att den inte kan lägga till samma domän en andra gång när en annan tjänst redan använder Mailgun . Den rekommenderade lösningen är en dedikerad Från-underdomän, till exempel notifications.example.com . Denna illustrativa underdomän behöver fortfarande sin egen visade konfiguration och lämplig DMARC utvärdering.
Använd Revalidera alla poster efter publicering. Atlassian säger att autentiserad och signerad sändning börjar inom 24 timmar efter validering, och att poster kontrolleras varje timme och måste förbli närvarande. Med endast en leverantör konfigurerad kan en systemomfattande failover göra att meddelanden använder noreply@statuspage.io . Båda leverantörskonfigurationerna är därför ett kontinuitetsmått, inte redundant röran.
Beslutet som betyder något
Testleverantörens beredskap och kontinuitet för varumärkesavsändare; en konfigurerad leveranspartner är inte den fullständiga installationen.
Verifiera de publicerade posterna och den verkliga sändningsvägen
Registrera byte av ägare, sändande produkt, domän, godkänt underhållsfönster och tidigare DNS svar innan redigering. Hämta de aktuella postvärdena från det namngivna kontot eller dokumenterade leverantörens arbetsflöde. Separera värden som tillhandahålls av leverantören från val som din organisation kontrollerar, såsom DMARC policy och rapporteringsmottagare. Befintlig postlåda MX , orelaterad verifiering TXT poster och aktiva DKIM väljare är inte rensningskandidater bara för att en ny tjänst läggs till.
Fråga de auktoritativa namnservrarna för varje exakt ägare och posttyp efter publicering. Registrera frågetiden, svarande server och komplett svar. Jämför TXT strängar som ett logiskt värde där DNS svaret delar upp dem i teckensträngar. Kontrollera CNAME mål samt startaliaset. Jämför sedan ett rekursivt resolver-svar för att identifiera skillnader i cachelagring. En framgångsrik leverantörsvalidering är ett användbart bevis på konfiguration, men det fastställer inte vad en faktisk mottagare fick.
Skicka endast ett auktoriserat test till en kontrollerad mottagare med den avsedda produktvägen. Behåll det råa meddelandet och det betrodda mottagande systemet Authentication-Results. Spela in den synliga Från-domänen, SMTP MAIL FRÅN eller observerats Return-Path domän, varje DKIM d= och s= värde, SPF och DKIM resultat och mottagarens DMARC resultat. En godkänd SPF eller DKIM kontroll stöder endast DMARC när dess autentiserade domän överensstämmer med den synliga From-domänen enligt tillämplig policy. Reply-To och ett varumärkesvisningsnamn är det inte inriktning identiteter. RFC 7208 , RFC 6376 och RFC 9989 tillhandahålla protokollgrunden för dessa distinktioner.
Acceptans arbetsblad, återhämtning och bevisgränser
Detta är ett originalkalkylblad för godkännande, inte en rapport om livetestning. Markera varje gate som väntar tills bevis finns: kontoomfattning bekräftad; tidigare DNS infångad; exakt ny ägare/typ/värde publicerad; leverantörsverifiering slutförd; avsedd rutt utövad; mottagna identiteter registrerade; justerad autentisering bekräftad; andra avsändare opåverkade. Tilldela en person och bevisfil till varje grind. En röd grind blockerar utrullningen även när leverantörens instrumentpanel är grön.
Om ett test misslyckas, särskilj först saknad publicering, inaktuell cachad data, inaktiv leverantörskonfiguration, fel utgående rutt och ojusterad autentisering. Korrigera den minsta påvisade defekten och testa igen. Försvaga inte DMARC eller radera andra avsändares poster bara för att klara ett test. Om en ändring skadar befintlig e-post, använd den godkända återställningsplanen och den inhämtade konfigurationen före ändring, och koordinera eventuella avsändarbyten på leverantörssidan samt DNS . Behåll gamla nycklar medan meddelanden i kö eller en godkänd överlappning fortfarande kräver dem.
Ingen kundhyresgäst, auktoritativ före/efter ändring eller verkligt mottaget meddelande var tillgängligt för detta manuskript. De bevarade källorna stödjer det dokumentära arbetsflödet; de uppfyller inte den beställda live-evidence gate. Oberoende granskning av kontrollörer och godkännande av mänskliga små och medelstora företag kvarstår. Beskriv inte den här guiden som fältvaliderad eller publicera den som att den har passerat dessa portar.
Använd en kontinuitetsreskontra från leverantör för leverantör
Skriftligt fall SP-01 antar anpassat Från status@notifications.example.com , Mailgun konfigurationen är klar och SendGrid postuppsättningen saknas. Ett föreskrivet Mailgun-levererat prov har betrodd DKIM pass d=notifications.example.com, s=demo1; SPF är okänd. Det provet tillhandahåller exakt DKIM anpassning men etablerar inte varumärkeskontinuitet genom SendGrid . Ägaren av incidentkommunikation måste lösa den saknade leverantörskonfigurationen eller uttryckligen acceptera den dokumenterade reservrisken för standardavsändare innan han gör anspråk på kontinuitet. Framkalla inte ett avbrott eller meddela verkliga prenumeranter att testa detta undervisningsfall. Slutför kontovalidering och använd ett auktoriserat kontrollerat test där det stöds; en oobserverad failover förblir oobserverad. Ingen incident eller failover utfördes.
Bevara verkställighetsgränsen
RFC 9989 avsnitt 7.4 kräver giltig DKIM , inte enbart SPF , för domänpublicering p=reject, och varnar för interoperabilitet med indirekt e-post och e-postlistor. Ett enda framgångsrikt test för direktmeddelanden är inte ett bevis på att varje legitim väg är redo för en starkare politik. Behåll befintligt godkänt skydd medan du diagnostiserar det faktiska gapet; varje policyändring behöver ett eget beslut.