A DMARC rollback bör återställa den avsedda kommunikationen samtidigt som de bevis som behövs för att förklara vad som hände bevaras. Att redigera posten är bara en del av det jobbet. Teamet måste också veta vilken legitim tjänst som misslyckades, vilken policy en mottagare kunde ha sett och vad som motiverar ett nytt försök.
Förbered den återställningsvägen innan ändringen. När en incident inträffar är ett tidigare värde, namngiven ägare och testad godkännanderutt mer användbara än en improviserad sökning genom skärmdumpar.
Registrera det tillstånd som kan behöva återställas
Spara hela postuppsättningen vid det exakta berörda DNS ägarnamnet, tillsammans med dess TTL, auktoritativa servrar och insamlingstid. Bevara tillämpliga policyer för överordnad och underdomän när de är viktiga för upptäckten. Enbart ett kopierat p-värde kan utelämna rapporteringsadresser eller inriktning inställningar som ändrades samtidigt.
Behåll den godkända ändringen som en läsbar diff. Identifiera syftet med varje ändrad tagg och den auktoriserade person som kan återställa den tidigare konfigurationen. Recension upptäckt av underdomänpolicy innan du antar att redigering av en överordnad post ändrar varje barns bedömning.
Lagra bevis för DNS -administration separat från känsliga meddelandeprover. Båda behöver lämplig åtkomst, men en incidentpost behöver inte återge en kunds konfidentiella innehåll.
Definiera en trigger som skiljer misslyckande från misstanke
Välj konkreta återställningskriterier för ändringen: till exempel ett verifierat avslag av ett kritiskt legitimt flöde som kan hänföras till den nya policyn och en oförmåga att reparera det flödet inom det överenskomna svarsfönstret.
Enbart ett stödklagomål startar en utredning; det fastställer inte DMARC som orsak. Fånga hela returnerad SMTP text, tjänst och konto, tid, mottagardomän, synlig från domän och tillgängliga sändningsloggar. För levererad post, behåll ett representativt originalmeddelande och betrodda mottagarautentiseringsresultat under RFC 8601 §7.1.
Enbart en låg sammanlagd genomgångsfrekvens behöver också sammanhang. Otillåten trafik kan misslyckas under en sund distribution. Fråga vilken legitim affärsväg som berörs innan politiken försvagas.
Separera en avsändarreparation från en policyåterställning
Om en applikation har en felaktig signeringsidentitet kan en applikationskorrigering som stöds vara lämplig återställning. Om den breda policyändringen orsakar följdeffekter återställer du den godkända tidigare policyn medan den ansökan utreds.
Undvik att byta SPF, DKIM, DMARC och sändningsplattformen på en gång om inte incidenten kräver det och varje ändring registreras. Flera samtidiga redigeringar gör det svårare att tillskriva förbättring eller misslyckande.
Att återställa policyn reparerar inte den underliggande autentiserings- eller inriktningsdefekten. Håll den defekten öppen med en ägare, bevis och ett omtestkrav.
Öva en kontrollerad återställning
Denna fiktiva övning illustrerar journalföringen, inte ett verkligt produktionstest:
- Tid: 10:00 UTC; Händelse: Godkända policyändringar från ingen till karantän; Bevis bevarat: Komplettera gamla och nya rekord, TTL och godkännande
- Tid: 10:08 UTC; Händelse: Fakturaarbetsflödet får ett policyrelaterat avslag; Bevis bevarat: Returnerat svar, skickande av konto- och meddelandeidentifierare
- Tid: 10:13 UTC; Händelse: Incidentens ägare godkänner den planerade återställningen; Bevarade bevis: Beslut och påverkad omfattning
- Tid: 10:16 UTC; Händelse: Tidigare fullständigt DMARC värde har återställts till samma ägarnamn; Bevis bevarat: Auktoritativt DNS svar och ändringskvitto
- Tid: 10:26 UTC; Händelse: Ett kontrollerat fakturaförsök accepteras hos en testmottagare; Bevis bevarat: Nytt SMTP resultat och mottaget autentiseringsbevis
Den sista raden visar just det nya försöket genom den rutten. Det bevisar inte att varje mottagare har kasserat ett tidigare cachat svar eller att alla kundmeddelanden har återställts.
Under en repetition, utöva den verkliga administrations- och godkännandevägen i en lämplig testmiljö. Registrera vem som kan göra ändringen och vad som händer om den personen eller DNS leverantören inte är tillgänglig.
Räkna med att DNS vyer och rapportperioder överlappar varandra
En resolver kan behålla ett tidigare DNS svar; RFC 8767 §4 tillåter kvalificerande inaktuella svar efter att TTL löper ut, så TTL är inte en garanterad global borttagningsdeadline. Att sänka en TTL efter att en resolver cachade ett tidigare svar med längre livslängd förkortar inte det svarets återstående cachelivslängd retroaktivt.
Efter att ha återställt posten, fråga de auktoritativa servrarna och relevanta rekursiva vyer och testa sedan den berörda e-postrutten igen. Ett nytt auktoritativt svar bevisar zonens aktuella data; det bevisar inte vad varje fjärrmottagare använder för närvarande.
Fortsätt att rapportera aktivt där det är lämpligt. RFC 9990 §3.3 förklarar att en policyändring inom en rapporteringsperiod kan ge en rapport som kombinerar dispositioner under olika policyversioner. Vissa implementeringar kan istället producera flera rapporter. Anteckna incidentens tidslinje istället för att behandla ett enda policyfält som bevis på att varje meddelande under perioden använde den exakta versionen.
Återställ en komplett, giltig konfiguration
Använd det exakta avsedda ägarnamnet och stämma av den befintliga postuppsättningen. Under RFC 9989 §4.10, lägg inte till en andra DMARC policy bredvid den första i ett försök att åsidosätta den. Behåll de godkända rapporteringsdestinationerna och eventuella nödvändiga externa destinationsbehörigheter enligt RFC 9990 §4 om inte återställningen uttryckligen ändrar dem.
Kontrollera hela den resulterande policyn för oavsiktliga ändringar. En återställning som tyst ändrar anpassning eller underdomäns omfattning är ett nytt policybeslut, inte bara återställning.
Använda rekordarbetsflödet för publicering och rapporteringsguiden för tolkning av den efterföljande bevisningen.
Stäng återhämtning och sanering separat
Återställning etableras när de definierade påverkade arbetsflödena uppfyller de överenskomna testerna och konfigurationen verifieras inom dess kända gränser. Åtgärd stänger endast när orsaken är förstådd och sändningsvägen har korrigerats eller den avsedda policyn har omprövats.
Nästa ändring bör inkludera de saknade bevisen som gjorde att det första försöket misslyckades. Interoperabilitetsvägledningen i RFC 9989 §7.4 innebär också att avvisning kan vara olämpligt för en allmän anställd domän. En misslyckad förändring kan avslöja att den föreslagna politiken i sig behöver ett annat beslut.
Behåll de ursprungliga bevisen, misslyckat resultat, återställ beslut och framgångsrikt omtest tillsammans. Det spåret gör nästa godkännande snabbare eftersom det förklarar vad som ändrades, vad som återhämtade sig och vad som förblir olöst.
Håll nästa åtgärd specifik
I den fiktiva tidslinjen är acceptansen 10:26 en återställningsobservation, inte ett bevis på att autentiseringsdefekten reparerades. Håll avsändarens åtgärdande objekt öppet och jämför de faktiska nya metodresultaten separat. Tidslinjen på 26 minuter är inte ett återhämtningslöfte eller ett rekommenderat vänteintervall. Ingen DNS återställning, auktorisering eller meddelandeförsök gjordes för den här artikeln.