Publisering av a DMARC rekord endrer retningslinjene og rapporteringsinformasjonen som deltakende mottakere kan finne for et domene. Den konfigureres ikke SPF, legg til DKIM signaturer, lagre legitime avsendere eller tvinge hver mottaker til å ta den samme leveringsbeslutningen.
Behandle DNS endringen som ett trinn i et kontrollert program. Den sikre endringen avhenger av bevis fra domenets reelle senderruter.
Skille publisering fra beredskap
Protokollreferanser: RFC 9989 §4.5, RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.8. Driftssjekklister og vedtak nedenfor er redaksjonell veiledning.
En DMARC -post publiseres med et aktuelt _dmarc DNS navn. Dens policy kan be om ingen, sette i karantene eller avvise håndtering for meldinger som mislykkes DMARC vurdering. Posten kan også be om rapporter og angi andre aktive parametere.
Publisering gjør ikke en avsender justert. SPF justering avhenger av den autentiserte konvoluttidentiteten og Fra-domenet. DKIM justering avhenger av en bestått signaturs d=-domene og From-domenet. Minst én passerende justert bane kan tilfredsstille et resultat på meldingsnivå. Full deltakelse krever både justert SPF og DKIM under RFC 9989 §8; avvise domener MÅ IKKE stole utelukkende på SPF og MÅ bruke gyldige DKIM signaturer under RFC 9989 §7.4.
En rekord som ber om avslag før legitime ruter er klare, kan utsette disse rutene for mottakerhandling. En post som ikke ber om policyspesifikk håndtering kan støtte overvåking, men rapporter er ikke garantert å dekke hver melding eller mottaker.
Bygg en avsender-for-sender-beredskapsmatrise
Følgende er en illustrativ driftsmal, ikke en påstand om et virkelig miljø:
- Avsender: Bedriftspost; Bedriftseier: Arbeidsplass IT; Fra domene: example.com ; Justert SPF observert: Ja; Justert DKIM observert: Ja; Representativ test: Aktuell; Håndhevelsesberedskap: Bevis tilgjengelig; gjenstand for full beredskapsvurdering
- Avsender: Faktureringsplattform; Bedriftseier: Økonomisystemer; Fra domene: billing.example.com ; Justert SPF observert: Nei; Justert DKIM observert: Ja; Representativ test: Aktuell; Håndhevelsesberedskap: Justert bane på meldingsnivå observert; bredere beredskap trenger gjennomgang
- Avsender: Legacy varsling; Bedriftseier: Infrastruktur; Fra domene: example.com ; Justert SPF observert: Nei; Justert DKIM observert: Nei; Representativ test: Aktuell; Håndhevingsberedskap: Ikke klar
- Avsender: Sesongundersøkelse; Bedriftseier: Markedsføring; Fra domene: news.example.com ; Justert SPF observert: Ukjent; Justert DKIM observert: Ukjent; Representativ test: Mangler; Håndhevingsberedskap: Hold og undersøk
"Ja" skal komme fra bevis for mottatt melding, ikke en påstand fra kontrollpanelet. "Ukjent" er ikke det samme som "Nei". Det betyr at endringseieren mangler nok bevis til å ta håndhevingsbeslutningen.
Registrer policydiff
Registrer det eksakte DNS eierens navn, tidligere verdi, foreslått verdi, resolverobservasjoner, endring av eier og godkjenning. En enkel fiktiv forskjell kan være:
- Felt: Eier; Før: _dmarc.example.com ; Foreslått: _dmarc.example.com
- Felt: Policy; Før: p=none; Foreslått: p=quarantine
- Felt: Samlet rapportering; Før: Eksisterende autorisert destinasjon; Forslag: Uendret
- Felt: Underdomenepolicy; Før: Nedarvet fra p; Foreslått: Eksplisitt gjennomgått
- Felt: Testflagg; Før: Ikke tilstede; Foreslått: Ikke tilstede
Poenget er ikke å fremme en bestemt målpolitikk. Det er for å synliggjøre enhver semantisk endring. Hvis posten også endrer rapporteringsdestinasjoner, justeringsmoduser, underdomenebehandling eller et testflagg, må du gjennomgå disse avgjørelsene separat.
Forstå hva policyen ber om
Protokollreferanser: RFC 9989 §4.7, RFC 9989 §5.4. Driftssjekklister og vedtak nedenfor er redaksjonell veiledning.
En policy er domeneeierens forespurte vurdering for e-post som ikke oppfyller DMARC . Mottakere beholder skjønn og kan bruke lokale retningslinjer, ytterligere bevis og unntak. En publisert p=reject verdi garanterer derfor ikke at hver feilmelding blir avvist, og en p=none verdi garanterer ikke levering.
Mottakeren avgjør også om den implementerer den relevante spesifikasjonen og rapporteringsatferden. Overvåk faktiske resultater i stedet for å konvertere en DNS streng til et universelt løfte.
RFC 9989 inkluderer det aktive t-testflagget. Når t=y brukes, er dens definerte effekt en reduksjon på ett nivå i den erklærte p-, sp- eller np-vurderingen: avvisning behandles som karantene, og karantene som ingen. Det er ikke en vilkårlig prosentvis utrulling, og det endrer ikke en erklært ingen-vurdering. Implementering av mottaker er fortsatt viktig.
Vet hva publikasjonen ikke fikser
Å publisere DMARC gjør ikke:
- slå sammen flere SPF policyer;
- legg til en DKIM signatur til en søknad;
- endre en tjenestes konvolutt eller signeringsdomene;
- bevise at hver observert kilde er legitim;
- beskytte visningsnavn på ikke-relaterte domener;
- reparer videresending eller transformasjoner av postlister;
- levering av garantirapporter;
- etablere innboksplassering;
- autorisere en forretningstransaksjon.
Hvert gap trenger sin egen eier. DMARC posten beskriver en domenepolicy; det er ikke en orkestreringskommando for hver applikasjon som sender.
Godkjenne håndhevelse fra representativt bevis
En nyttig godkjenningspost navngir domenene som er omfattet av omfanget, avsenderens beholdningsversjon, bevisdato, uløste unntak, målpolicy, tilbakestillingskriterier og ansvarlig godkjenner. Inkluder lavvolum, planlagte og nødsendere. En uke uten observert feil er ikke tilstrekkelig hvis kvartals- eller årlige systemer aldri ble brukt.
Bruk en representant mottatt melding fra hver rute. Registrer Fra-domenet, konvoluttidentiteten, DKIM d=-verdier, klarerte resultater og justering. Samlede rapporter kan hjelpe med å identifisere mønstre, men de erstatter ikke eierbekreftelse eller testing på meldingsnivå.
Indirekte poststrømmer fortjener separat oppmerksomhet. Videresending og meldingsendring kan påvirke SPF og DKIM annerledes. Ikke løs et kjent videresendingsunntak ved å svekke en urelatert senders autentisering uten bevis.
Bekreft etter DNS endringen
Etter publisering:
- Spør etter det nøyaktige eiernavnet gjennom uavhengige løsere.
- Bekreft at én sammenhengende DMARC -policypost kan oppdages.
- Tillat DNS bufring før du tolker blandede observasjoner.
- Send kontrollerte tester gjennom representative ruter.
- Sjekk mottakerresultater, ikke bare utgående applikasjonslogger.
- Sammenlign feil med den godkjente avsenderbeholdningen.
- Se bedriftsstøttekanaler for forsinkede eller uregelmessige ruter.
Observasjonsvinduet bør dekke meningsfulle konjunkturer. Angi eksplisitte stoppbetingelser i stedet for å vente på et vilkårlig antall dager.
Definer tilbakeføring før håndhevelse
Protokollreferanser: RFC 9990 §4. Driftssjekklister og vedtak nedenfor er redaksjonell veiledning.
Tilbakerulling er en kontrollert DNS endring, ikke sletting uten analyse. Registrer den tidligere verdien og tilstanden som rettferdiggjør en policyreduksjon. En tilbakeføring kan redusere policyen mens den berørte avsenderen repareres, men den bør bevare bevis og unngå å introdusere flere poster.
Hvis rapporteringsdestinasjoner er eksterne i forhold til policydomenet, sørg for at nødvendig autorisasjon finnes. En rapporteringssvikt bør undersøkes, men fravær av rapporter alene beviser ikke at policyen ikke blir evaluert.
Behandle publisering som en styrt beslutning
DNS eieren utfører endringen. E-postoperasjoner validerer autentisering. Appeiere bekrefter legitime ruter. Sikkerhet aksepterer gjenværende etterligning og leveringsrisiko. Bedriftseiere godkjenner effekten på kritisk kommunikasjon.
Denne separasjonen forhindrer en enkelt TXT -redigering fra å ta ansvar for applikasjoner den ikke kan konfigurere og mottakerbeslutninger den ikke kan kontrollere.
Bruk bevisene uten å overdrive det
I den fiktive beredskapsmatrisen, hold arven og sesongmessige ruter for etterforskning. Billings justerte DKIM observasjon viser en mulig bane på meldingsnivå, ikke fullstendig deltakelse eller eiergodkjenning. Registrer de manglende bevisene før du velger policy. Ingen av de illustrerte DNS endringene eller sendingene ble utført.