Start med identiteten mottakeren vil sjekke
En endring av e-postautentisering begynner med et navn, en rekord type og en ansvarlig operatør. "Legg til autentisering til vårt domene" er for bredt til å identifisere riktig DNS editor eller svaret en mottaker trenger. En markedsføringstjeneste kan signere med ett domene, bruke et annet som SMTP konvolutt og vise et tredje i Fra-feltet. En beholdning bør bevare disse forskjellene før noen redigerer en sone.
Til SPF, skaff deg domenet som brukes av SMTP POST FRA identitet; de HELO identitet har sin egen sjekk, inkludert null reverse-path case. Spør etter det aktuelle domenet for TXT . Ikke velg SPF eieren bare ved å lese den synlige Fra-adressen. RFC 7208 , avsnitt 2.3–2.4 og 3.1.
Til DKIM, ta velger fra s= og signeringsdomenet fra d= i signaturen. Navnet på nøkkeloppslag er velger, da _domainkey, deretter signeringsdomenet. Til DMARC, starter policyoppdagelse med en TXT spørring under _dmarc på forfatterdomenet og kan fortsette å bruke det spesifiserte DNS -trevandring. En fraværende første registrering bekrefter ikke i seg selv at ingen retningslinjer gjelder. RFC 6376 , avsnitt 3.6.2; RFC 9989 , avsnitt 4.5 og 4.10.
Skille eiernavnet fra personene som eier endringen
I DNS er postens eier et domenenavn. I en endringsbillett er eieren ofte en person eller et lag. Ta opp begge. Domeneregistratoren, den autoritative DNS verten, sendeplattformadministratoren og den godkjennende domeneeieren kan være forskjellige parter. Registreringstilgang er ikke bevis på at en bestemt DNS konsoll kontrollerer dagens offentlige svar.
Identifiser de delegerte autoritative serverne for sonen som inneholder det forespurte navnet. Et underdomene kan ha sin egen delegering, så riktig editor kan avvike fra hoveddomenets editor. Hold sonen, fullt eiernavn, forespurt type, foreslåtte data og ansvarlig operatør sammen. DNS delegering definerer hvor autoritet endres; den følger ikke en organisasjons støtteteamgrenser. RFC 1034 , avsnitt 4.2 og 4.2.1.
Be avsenderadministratoren om å oppgi kontoutstedte verdier og forklare eventuelle aliaser. En leverandørs CNAME instruksjon peker et navn på et annet navn; det er ikke samme operasjon som å delegere en barnesone med NS-poster. Fang opp hvem som opprettholder aliasmålet, samt hvem som kan endre posten på kundesiden.
Les den publiserte rekorden i stedet for redaktørens utseende
DNS konsoller godtar ofte en relativ vertsetikett og legger til sonenavnet. Et kopiert fullt kvalifisert navn angitt i feil modus kan derfor lande på en utilsiktet eier. Bekreft det endelige absolutte navnet, inkludert alle underdomener og understrekingsetiketter. En redaktørs lagrede verdi er forberedelsesbevis; et autoritativt DNS svar er publiseringsbevis.
TXT presentasjon trenger også omsorg. En enkelt TXT ressurspost kan inneholde flere tegnstrenger. For SPF er disse strengene sammenkoblet uten å sette inn mellomrom. Det skiller seg fra å publisere to separate SPF poster hos samme eier, noe som er forbudt. Bevar postgrenser når du gjennomgår en eksport eller skjermdump i stedet for å telle anførselstegn. RFC 1035 , avsnitt 3.3.14; RFC 7208 , avsnitt 3.2–3.3.
MX poster identifisere postutvekslere for mottak av post. De beviser ikke uavhengig hvilken utgående tjeneste som er autorisert eller hvilken nøkkel som signerer en melding. En SPF policy kan referere til MX gjennom en mekanisme, men det forholdet må komme fra den faktiske policyen, ikke fra en antagelse om at alle e-postrelaterte DNS poster autentiserer sending. RFC 1035 , avsnitt 3.3.9; RFC 7208 , avsnitt 5.4.
Arbeid gjennom en fiktiv eierskapsinventar
Anta at en fiktiv tjeneste sender e-post med From news@example.com, POST FRA bounce@mail.example.com, og en DKIM signatur inneholder d=example.com; s=nov26. Den første beholdningen har tre separate TXT spørsmål: mail.example.com, nov26._domainkey.example.com, og _dmarc.example.com. Dette er illustrative navn og identiteter, ikke observerte meldinger eller anbefalte produksjonsverdier.
E-postadministratoren bekrefter den tiltenkte ruten og velgeren. DNS administratoren sjekker hvilken sone som inneholder hvert navn og om et leverandørkrevende alias endrer oppslagsbanen. Domeneeieren godkjenner omfanget. Hvis velgeren er utstedt av en leverandør, må leverandøren beholde den tilsvarende private nøkkelen; kun materiale med offentlig nøkkel hører hjemme i DNS . En privat nøkkel må aldri kopieres inn i billetten eller en offentlig TXT post.
En beholdningsrad skal skille mellom "levert av tjenesten", "tilstede i autoritativ DNS " og "observert på mottatt e-post." Å la en av disse kolonnene være ukjent er mer nyttig enn å sjekke en enkelt "autentisert" boks for tidlig.
Samle bevis før du lukker endringen
Foreslåtte kontroller er dig @AUTH_IP nov26._domainkey.example.com . TXT +norecurse og dig @RESOLVER_IP nov26._domainkey.example.com . TXT. Bytt ut plassholderne med store bokstaver med godkjente endepunkter. Gjenta for hver faktisk eier og relevante autoritative server. Ta vare på UTC-tid, serveradresse, spørsmål, svarkode, flagg, svar- og autorisasjonsseksjoner, TTL-er og enhver alias-kjede. Disse kommandoene er ikke utført for denne artikkelen.
Hvis autoritet og rekursjon er uenige, undersøk publiseringskonsistens, bufring og løsningsbanen før du legger til dupliserte poster. Et DNS svar kan fortsatt ikke bevise at en signatur bekrefter, SPF autoriserer den faktiske sendings-IP-en, eller DMARC justerer. Lukk disse spørsmålene med en kontrollert mottatt melding og klarerte mottakerresultater. Tidsstemplede autoritative og rekursive transkripsjoner forblir en åpen originalbevisport for dette dokumentarutkastet.