A väljare monitor kan berätta att verifieringsdata har ändrats eller försvunnit. Den kan inte fastställa att en tjänst fortfarande sänder, att dess privata nyckel matchar den publicerade nyckeln eller att dess meddelanden kommer med aligned DKIM. Bygg separata kontroller för publicerad konfiguration och observerat meddelandebeteende.
Börja med kända sändningsrutter
Skapa en inventering från auktoriserad avsändarkonfiguration och representant mottagna meddelanden. För varje ruttpost företagsägaren, d-domänen, väljaren, DNS ägaren, förväntad TXT eller CNAME arrangemang, senast observerade signeringstid och livscykelstatus. Anta inte att gissande vanliga väljare upptäcker varje undertecknare. DKIM tillhandahåller väljaren i varje signatur istället för att definiera en komplett DNS uppräkningstjänst.
För en signatur med s=invoice2 och d=brand.example, inspektera invoice2._domainkey.brand.example under RFC 6376 §3.6.2.1. Följ en förväntad CNAME till dess verifieringsdata. Lagra en observationstidsstämpel och ett fingeravtryck med offentlig nyckel så att en förändring kan jämföras med en godkänd rotation. Samla aldrig in privata nycklar i övervakningssystemet.
Separera monitorns resultat
Ett saknat svar, DNS timeout, återkallad nyckel och ändrad nyckel är olika händelser. RFC 6376 §6.1.2 skiljer nyckelfrågefel från en frånvarande nyckel, och ett tomt p-värde representerar återkallelse under RFC 6376 §3.6.1. Registrera svarsdetaljer istället för att översätta varje fel till ett allmänt avbrott.
En aktuell nyckel behöver fortfarande syntax- och algoritmkontroller. RFC 8301 §3.1 förbjuder rsa-sha1-signering och verifiering; RFC 8301 §3.2 uppdateringar RSA-storlekskrav: undertecknare måste använda minst 1024 bitar och bör använda minst 2048. Produktsupport och nuvarande organisatoriska kryptografiska policy kan vara strängare. Enbart en fingeravtrycksändring kan inte berätta om en rotation var auktoriserad.
Lägg till en levande bevisloop
Skicka kontrollerade meddelanden genom varje viktig produktionsväg till en brevlåda vars råmeddelande och pålitliga autentiseringsresultat du kan inspektera. Anteckna observerade d och s, verifieringsresultat och inriktning med From. Utöva de meddelandevarianter som nedströmsbehandling kan påverka, som HTML och bilagor.
Illustrativ övervakare: DNS fortsätter att leverera faktura2, men ett nytt meddelande innehåller nej DKIM-Signature. Publiceringskontrollen godkänns medan signeringskontrollen misslyckas. I ett annat fall finns signaturen men dess body hash misslyckas efter en gateway-sidfotsändring. Ingen av incidenterna löses genom att förklara DNS posten frisk. Dessa är syntetiska testfall, inte uppmätta serviceincidenter.
Syntetiska tester har också gränser. En daglig sond bevisar inte varje meddelande mellan sonder som skickas. Kombinera det med mottagarrapporter och incidentbevis, samtidigt som du bekräftar rapporteringstäckning och förseningar.
Dirigera handlingsbara varningar
Bifoga varningar till en rutt och ägare. Undertryck endast ett uttryckligen godkänt underhållsfönster, bevara händelsehistoriken och bekräfta den nya undertecknaren med ny post efter rotation. Eskalera oväntade nyckeländringar som möjliga säkerhetshändelser utan att deklarera kompromisser från enbart en förändring.
Ta bort inaktuella lagerrader medvetet. En gammal offentlig nyckel kan finnas kvar för fördröjd meddelandeverifiering även när ny signering har stoppats. Skilj det planerade tillståndet från en övergiven delegation. Instrumentpanelen ska säga vad som observerades, när och med vilken metod, så att DNS hälsan aldrig maskerar sig som bevis på livesignering.
Återskapa varningsbeslutet
Använd fyra syntetiska sonder för att hålla varningsskikten åtskilda. En signatur med d=brand.example och s=invoice2 mappar till invoice2._domainkey.brand.example . Om dess publika nyckel finns men det angivna mottagarresultatet är ett body-hash-fel, aktivera en meddelandeverifieringsvarning. Om nyckeln saknas, höj en varning om nyckelfrånvaro. Om den förväntade posten finns men meddelandet inte har någon signatur, skicka en varning om saknad-signering. En närvarande nyckel plus ett tillhandahållet godkänt resultat ger ingen varning enbart för den sonden.
Dessa fyra beslut är en illustrativ beslutsmodell med uppfunna DNS tillstånd och levererade mottagarresultat. Ingen live DNS fråga, signeringstest eller kryptografisk verifiering utfördes för denna granskning. För att ta i bruk monitorn, ersätt dem med daterade offentliga svar och råmeddelanden med resultat från din betrodda mottagningsgräns. Bevara det länkade beviset innan du beskriver en rutt som operativt verifierad.
Bevis som behövs för nästa beslut
För en body-hash-varning, bevara det angivna resultatet och undersök kroppsrepresentation, c/l-inställningar, bh-värde och implementeringsbeteende; en missmatchning ensam bevisar inte ett gateway-modifierat innehåll. Markera en rutt utan ny sond som oobserverad, även om dess nyckel är närvarande. Anteckna separat om justeringen har kontrollerats, eftersom DKIM pass enbart inte är justerat pass.