A DMARC Een wijzigingsverzoek moet een andere persoon in staat stellen precies te bepalen wat er gaat veranderen, op welke diensten dit van invloed kan zijn en hoe succes zal worden aangetoond. Een screenshot van het gewenste beleid is niet voldoende. Behoud de basislijn en de voorgestelde RRset en koppel deze vervolgens aan goedgekeurde bedrijfsstromen en een herstelbesluit.
Leg de basislijn nauwkeurig vast
Leg het DNS -provideraccount of de tenant, de zone, de naam van de eigenaar, het recordtype, de volledige waarde en TTL vast. Vermeld het tijdstip en de bron van de waarneming. Leg de huidige DMARC beleidsdetectie vast voor getroffen auteurdomeinen, plus de goedgekeurde afzenders en eventuele onopgeloste uitzonderingen. Behoud authenticatie-ID's in plaats van een test te reduceren tot een dashboardkleur.
DMARC kan een uitgelijnd succes passeren SPF of DKIM resultaat. Het zichtbare Van-domein van een bericht en de geverifieerde identificatiegegevens zijn daarom belangrijker dan een algemene verklaring die SPF doorgeeft. RFC 9989. Voor het publiceren van domeinen p=reject, RFC 9989 secties 7.4 en 8 vereisen afzonderlijk geldige DKIM handtekeningen en verbieden het uitsluitend vertrouwen op SPF ; Succes op berichtniveau betekent niet dat er geen ontplooiing nodig is. Een authenticatiepas certificeert het zakelijke verzoek niet en garandeert geen plaatsing in de inbox.
Beschrijf het beoogde verschil
Vermeld de exacte voor-en-na RRsets en betrokken namen. Leg uit waarom de verandering nu nodig is, welke diensten zijn getest en welk bewijs onvolledig blijft. Houd niet-gerelateerde DNS -bewerkingen buiten de aanvraag, zodat een goedkeurder niet per ongeluk een bredere bewerking goedkeurt. Identificeer de technische implementator, de zakelijke goedkeurder en de escalatiecontactpersoon.
Als rapportagebestemmingen of gedelegeerde services veranderen, beoordeel dan de informatiestroom en afhankelijkheid afzonderlijk. Behoud de rapportage-innameconfiguratie die nodig is voor de beoogde monitoring. Geaggregeerde rapporten zijn ontvangerwaarnemingen met dekkingsbeperkingen, en kunnen dus niet het enige acceptatiesignaal zijn voor een tijdkritische legitieme stroom. RFC 9990.
Schrijf waarneembare acceptatiecriteria
Gebruik criteria die kunnen falen: de gezaghebbende RRset is gelijk aan de goedgekeurde waarde; representatieve kritische berichten gebruiken de beoogde identiteiten en authenticeren zoals verwacht; de zakelijke ontvanger bevestigt het verwachte resultaat; en de rapportintake gaat door. Registreer observatietijden en onderscheid direct beschikbare tests van latere rapportbeoordeling. Een rapport dat nog niet is binnengekomen, is geen geslaagde test.
Definieer hersteltriggers vóór implementatie. Als een kritieke stroom mislukt en de diagnose deze koppelt aan de goedgekeurde wijziging, roep dan het goedgekeurde herstelplan op. Behoud de oude staat en leg de beperkingen ervan uit. Als u een beleid herstelt, wordt de in de cache opgeslagen DNS niet onmiddellijk ongedaan gemaakt of worden reeds afgewezen berichten teruggehaald. Plan observatie buiten het nominale onderhoudsvenster.
Test of een aanvraag daadwerkelijk kan worden afgesloten
Stel dat een hypothetisch verzoek alleen het beleid voor een salarisadministratie Van-domein wijzigt p=none naar p=quarantine met behoud van de rapportagebestemming en TTL. De beoordeling moet nog steeds bindend zijn voor de volledige basislijn en de voorgestelde RRset, doelaccount en domein, goedgekeurde loonsomvang en herstelplan. Hier wordt geen echte payload, goedkeuring of DNS wijziging gegeven.
Stel dat een geautoriseerde observatie na de wijziging overeenkomt met de goedgekeurde DNS status en dat een representatief salarisbericht wordt geverifieerd zoals verwacht, maar dat de zakelijke ontvanger de ontvangst nog niet heeft bevestigd en dat het volgende verzamelrapport nog niet beschikbaar is. Registreer configuratie- en authenticatiecontroles afzonderlijk van de openstaande resultaten. Wijs de opvolging van de ontvangsten toe aan de salariseigenaar en de uitgestelde beoordeling van de intake aan de rapporterende eigenaar; sluit niet alle acceptatiecriteria af op basis van een matchingrecord. Dit zijn hypothetische bevindingen, geen uitgevoerde controles.
De bovenstaande wijzigingsworkflow is een operationele aanbeveling en geen protocolvereiste. NIST SP 800-53 Rev. 5 controles CM-3 en CM-5 bieden een algemene basis voor het beoordelen, goedkeuren en beperken van wijzigingen; de exacte payloadbinding, rollen en overdrachtsvelden zijn hier de voorgestelde implementatie. NIST -controlecatalogus.