An organisasjonsdomene er en grense som brukes i DMARC behandling. Det hjelper en mottaker med å finne policy når et synlig From-domene ikke har noen egne registreringer, og det hjelper til med å sammenligne autentiserte identiteter i avslappet justering. Dette er relaterte operasjoner, men de er ikke det samme spørsmålet.
Snarveien "ta de to siste etikettene" er upålitelig. Et navn under et offentlig suffiks i flere deler, for eksempel co.uk , viser allerede hvorfor det å telle to etiketter kan velge suffikset i stedet for organisasjonen. Den nåværende spesifikasjonen legger til en ytterligere grunn til å unngå snarveier: RFC 9989 definerer DNS -trevandring i stedet for å stole på en offentlig suffiksliste alene.
Skriv ned de tre spørsmålene hver for seg
Begynn med det faktiske domenet i meldingens Fra-adresse, kalt forfatterdomenet. Spør så:
- Hvilken DMARC policypost gjelder for dette forfatterdomenet?
- Hvilket organisasjonsdomene etablerer den gjeldende oppdagelsesprosessen for hver identitet som sammenlignes?
- Gjør bestått SPF eller DKIM identitet oppfyller den valgte justeringsmodusen?
En gyldig post direkte på forfatterdomenet vinner policyvalg. Det beviser ikke automatisk at forfatterdomenet er organisasjonsdomenet som brukes for avslappet justering. Behandle en DNS kontroller som bare viser ett "domene"-felt som en startvisning, og samle inn de faktiske navnene og svarene som trengs for å forklare konklusjonen.
De identitetskjedeguide hjelper med å identifisere From-, envelope- og DKIM domenene før oppdagelsen begynner.
Følg et merket eksempel
Følgende er et syntetisk DNS øyeblikksbilde. Den illustrerer et fiktivt register under det reserverte .example-navnerommet; det er ikke et direkte søkeresultat eller en påstand om et ekte offentlig suffiks.
Anta at det eksisterende forfatterdomenet er invoice.harbour.registry.example . Budskapet har en forbigående DKIM signatur med d=sign.harbour.registry.example. SPF passerer for et eget tjenestedomene som ikke stemmer overens.
| Søksmål | Illustrerende respons | Konsekvens |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | Ingen DMARC -policypost | Fortsett oppdagelsen |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Etabler denne eksplisitte organisatoriske grensen og stopp turen |
| _dmarc.registry.example | Ikke spurt etter stoppet | Ingen ytterligere respons er nødvendig for denne vandringen |
Den valgte policyen er posten på harbour.registry.example . Fordi invoice.harbour.registry.example eksisterer og er et underdomene, er den gjeldende vurderingspolicyen karantene gjennom sp. Organisasjonsdomenet er harbour.registry.example fordi posten eksplisitt signaliserer psd=n.
For DKIM identiteten returnerer det illustrative oppslaget på _dmarc.sign.harbour.registry.example ingen post, etterfulgt av den samme psd=n grenseposten. Den autentiserte signeringsidentiteten og forfatterdomene deler derfor et organisasjonsdomene. Med avslappet DKIM justering gir den beståtte DKIM signaturen en justert bane. Streng justering vil kreve nøyaktig identitetslikhet, noe disse to forskjellige navnene ikke har.
Eksemplet holder bevisst policyvalg, grenseoppdagelse, autentisering og justering synlig som separate resultater. Endring av policyverdien vil ikke gjøre de ulike domenestrengene til et eksakt samsvar.
Forstå hva som stopper turen
RFC 9989 Seksjon 4.10 spesifiserer spørringer, postfiltrering og grenser. En gyldig post med psd=n identifiserer en organisasjonsgrense. En gyldig post med psd=y identifiserer en offentlig suffiksgrense, med reglene for valg av organisasjonsdomene som står for domenet én etikett under den når det er aktuelt.
Hvis ingen av signalene løser grensen, gir spesifikasjonen valg- og reserveregler. Det begrenser også oppdagelse av lange navn for å unngå at en angriper tvinger ubegrensede oppslag. En produksjonsimplementering trenger den komplette algoritmen, inkludert ugyldige eller flere poster og DNS feil; å fjerne etiketter til et kjent navn dukker opp er ikke en erstatning.
Ikke kopier psd=y inn i en ordinær organisasjons journal. Den beskriver en suffiksrolle. psd=n kan støtte tilsiktede organisasjonsgrenser, inkludert delegerte undertrær, men bør følge en dokumentert navneromsbeslutning i stedet for en universell sjekkliste.
Undersøk forskjeller mellom verktøy og mottakere
En eldre implementering kan bruke tilnærmingen med offentlig suffiks knyttet til RFC 7489. En nyere implementering kan følge RFC 9989 trevandring. DNS svar, cacher og implementeringsstøtte kan derfor ha betydning når resultatene er uenige.
For en nyttig sammenligning, ta vare på de fullstendige identitetsnavnene, spørringssvarene med tidsstempler, oppdaget policyoppføring, justeringsinnstillinger og mottakerresultat. Spør verktøyleverandøren hvilken oppdagelsesmodell den implementerer. Ikke utlede universell bruk fra en publiseringsdato eller endre DNS utelukkende for å få to dashbordetiketter til å stemme overens.
Skille en genuin grense-uenighet fra et ubehandlet autentiseringsproblem. En manglende DKIM signatur, mislykket signatur eller ikke-godkjent senderute vil ikke bli gyldig fordi organisasjonsdomeneberegningen er korrigert.
Gjør grensen til en operasjonell rekord
For domener med flere forretningsenheter eller delegerte DNS team, registrer hvem som kan publisere under hver grense og hvilke tjenester som kan autentisere e-post der. Gå tilbake til den posten når en applikasjon får et underdomene, en forretningsenhet endrer DNS administrasjon eller en leverandør blir trukket tilbake.
Bruk verifisering av underdomenepolicy for å sjekke hvilken policy som gjelder, og justering sammenligningen når du bestemmer hvilke domenerelasjoner som er akseptable.
Det nyttige resultatet er en reproduserbar kjede: disse var meldingsidentitetene, disse DNS svarene etablerte de relevante grensene, denne policyen ble brukt, og denne passerende identiteten stemte overens eller ikke. En gjettet domeneetikett kan ikke gi dette beviset.
Bruk et grensevedtakskort
Bruk dette kortet for valg av organisasjonsdomene, ikke som en erstatning for policyoppdagelse. Sjekk først Author Domain for sin egen policy. En direkte policy kan gjelde selv når justering krever en annen grenseberegning.
| Observasjon under den angitte gåturen | Grensevedtak |
|---|---|
| En gyldig post inneholder psd=n | Stoppe; den postens domene er organisasjonsdomenet. |
| En gyldig post inneholder psd=y borte fra startdomenet | Stoppe; velg domenet én etikett under det offentlige suffikset. |
| psd=y is at the starting domain | Turen stopper, men regelen "one label below" gjelder ikke for den startrekorden. Bruk utvalgsreglene i stedet for å finne opp et underordnet domene. |
| Gyldige poster eksisterer uten et avgjørende grensesignal | Velg den gyldige posten ved navnet med færrest etiketter. Ikke velg den første stamfarposten automatisk. |
| Ingen organisasjonsdomene er bestemt | Bruk det opprinnelige måldomenet som organisasjonsdomene. Denne reserven oppretter ikke en policypost. |
| Emnenavnet har mange etiketter | Bruk grensen for åtte spørringer: behold den første spørringen, og forkort deretter som spesifisert. Ikke spør alle stamfarene til et vilkårlig langt navn. |
Disse radene oppsummerer RFC 9989 avsnitt 4.10–4.10.2; postfiltrering og DNS-feilhåndtering gjelder fortsatt. Ingen policy funnet under policyoppdagelse betyr at DMARC ikke gjelder, selv om justeringsalgoritmen har en reservegrense.
Som et annet fiktivt spor, anta at turen for a.mail.example.com finner gyldige poster på mail.example.com og example.com , verken med psd=n eller psd=y, og ingen andre steder. Det valgte organisasjonsdomenet er example.com . Hvis mail.example.com i stedet signaliserer psd=n, stopper turen der og den mer spesifikke grensen vinner. Behold DNS øyeblikksbildet med resultatet slik at en annen operatør kan gjengi sammenligningen.