Begin met de identiteit die de ontvanger zal controleren
Een wijziging in e-mailauthenticatie begint met een naam, een record type en een verantwoordelijke exploitant. “Authentificatie toevoegen aan ons domein” is te breed om de juiste DNS editor of het antwoord dat een ontvanger nodig heeft te identificeren. Een marketingservice kan met één domein ondertekenen, een ander domein gebruiken voor de SMTP envelop en een derde in het veld Van weergeven. Een inventarisatie moet deze verschillen behouden voordat iemand een zone bewerkt.
Voor SPF, verkrijg het domein dat door de SMTP wordt gebruikt MAIL VAN identiteit; de HELO identiteit heeft zijn eigen controle, inclusief het geval van nul-omgekeerd pad. Vraag het toepasselijke domein voor TXT op. Selecteer de SPF eigenaar niet alleen door het zichtbare Van-adres te lezen. RFC 7208 , paragrafen 2.3–2.4 en 3.1.
Voor DKIM, neem de keuzeschakelaar van s= en het ondertekeningsdomein van d= in de handtekening. De naam van de sleutelzoekopdracht is dan selector _domainkeyen vervolgens het ondertekeningsdomein. Voor DMARC, begint beleidsdetectie met een TXT query eronder _dmarc bij het auteurdomein en kan het opgegeven blijven gebruiken DNS -boomwandeling. Het ontbreken van een eerste registratie betekent op zichzelf niet dat er geen beleid van toepassing is. RFC 6376 , sectie 3.6.2; RFC 9989 , secties 4.5 en 4.10.
Scheid de naam van de eigenaar van de mensen die eigenaar zijn van de wijziging
In DNS is de eigenaar van het record een domeinnaam. Bij een wijzigingsticket is de eigenaar vaak een persoon of team. Neem beide op. De domeinregistreerder, de gezaghebbende DNS host, de verzendende platformbeheerder en de goedkeurende domeineigenaar kunnen verschillende partijen zijn. Registratietoegang is geen bewijs dat een bepaalde DNS console het huidige publieke antwoord beheert.
Identificeer de gedelegeerde gezaghebbende servers voor de zone die de aangevraagde naam bevat. Een subdomein kan zijn eigen delegatie hebben, dus de juiste editor kan verschillen van de editor van het bovenliggende domein. Houd de zone, de volledige naam van de eigenaar, het aangevraagde type, de voorgestelde gegevens en de verantwoordelijke operator bij elkaar. DNS delegatie definieert waar de autoriteit verandert; het volgt niet de grenzen van het ondersteuningsteam van een organisatie. RFC 1034 , paragrafen 4.2 en 4.2.1.
Vraag de afzenderbeheerder om door het account uitgegeven waarden op te geven en eventuele aliassen uit te leggen. Van een aanbieder CNAME instructie verwijst een naam naar een andere naam; het is niet dezelfde handeling als het delegeren van een onderliggende zone met NS-records. Leg vast wie het aliasdoel onderhoudt en wie de record aan de klantzijde kan wijzigen.
Lees de gepubliceerde recordset in plaats van het uiterlijk van de redacteur
DNS consoles accepteren vaak een relatief hostlabel en voegen de zonenaam toe. Een gekopieerde, volledig gekwalificeerde naam die in de verkeerde modus is ingevoerd, kan daarom bij een onbedoelde eigenaar terechtkomen. Controleer de uiteindelijke absolute naam, inclusief elk subdomein en onderstrepingsteken. De opgeslagen waarde van een redacteur is voorbereidingsbewijs; een gezaghebbend DNS antwoord is publicatiebewijs.
TXT presentatie heeft ook zorg nodig. Eén enkele TXT bronrecord kan meerdere tekenreeksen bevatten. Voor SPF worden deze tekenreeksen aaneengeschakeld zonder spaties in te voegen. Dat is iets anders dan twee afzonderlijke publiceren SPF records bij dezelfde eigenaar, wat verboden is. Behoud recordgrenzen bij het bekijken van een export of screenshot in plaats van aanhalingstekens te tellen. RFC 1035 , sectie 3.3.14; RFC 7208 , paragrafen 3.2–3.3.
MX records identificeer postwisselaars voor het ontvangen van post. Ze bewijzen niet zelfstandig welke uitgaande dienst geautoriseerd is of welke sleutel een bericht ondertekent. Een SPF beleid kan via een mechanisme naar MX verwijzen, maar die relatie moet voortkomen uit het daadwerkelijke beleid en niet uit de veronderstelling dat alle mailgerelateerde DNS records het verzenden verifiëren. RFC 1035 , sectie 3.3.9; RFC 7208 , sectie 5.4.
Werk door een fictieve eigendomsinventaris
Stel dat een fictieve dienst e-mail verzendt met Van news@example.com, MAIL VAN bounce@mail.example.com, en een DKIM -handtekening bevattend d=example.com; s=nov26. De initiële inventarisatie bevat drie afzonderlijke TXT vragen: mail.example.com, nov26._domainkey.example.com, En _dmarc.example.com. Dit zijn illustratieve namen en identiteiten, geen waargenomen boodschappen of aanbevolen productiewaarden.
De e-mailbeheerder bevestigt de beoogde route en selector. De DNS beheerder controleert welke zone elke naam bevat en of een door de provider vereiste alias het opzoekpad wijzigt. De domeineigenaar keurt het bereik goed. Als de selector is uitgegeven door een leverancier, moet de leverancier de bijbehorende privésleutel behouden; alleen materiaal met een publieke sleutel hoort thuis in DNS . Een privésleutel mag nooit naar het ticket of een openbaar TXT record worden gekopieerd.
In een inventarisrij moet onderscheid worden gemaakt tussen 'geleverd door de service', 'aanwezig in gezaghebbende DNS ' en 'waargenomen in ontvangen e-mail'. Eén van deze kolommen onbekend laten is nuttiger dan het voortijdig aanvinken van een enkel “geverifieerd” vakje.
Verzamel bewijsmateriaal voordat u de wijziging afsluit
Voorgestelde cheques zijn dat wel dig @AUTH_IP nov26._domainkey.example.com . TXT + geen herhaling En dig @RESOLVER_IP nov26._domainkey.example.com . TXT. Vervang de tijdelijke aanduidingen in hoofdletters door goedgekeurde eindpunten. Herhaal dit voor elke daadwerkelijke eigenaar en relevante gezaghebbende server. Bewaar UTC-tijd, serveradres, vraag, responscode, vlaggen, antwoord- en autoriteitssecties, TTL's en eventuele aliasketens. Deze opdrachten zijn voor dit artikel niet uitgevoerd.
Als autoriteit en recursie het niet eens zijn, onderzoek dan de consistentie van de publicatie, caching en het pad van de oplossing voordat u dubbele records toevoegt. Een DNS antwoord kan nog steeds niet bewijzen dat een handtekening wordt geverifieerd, SPF autoriseert het daadwerkelijke verzendende IP-adres of DMARC wordt uitgelijnd. Sluit die vragen af met een gecontroleerd ontvangen bericht en vertrouwde ontvangerresultaten. Gezaghebbende en recursieve transcripties met tijdstempel blijven een open poort voor origineel bewijsmateriaal voor dit documentaire concept.