SPF, DKIM og DMARC: e-postautentisering som holder
De store e-postleverandørene krever autentisert e-post, men din egen DMARC har stått på p=none i årevis, og ingen vet hvilke systemer som sender under bedriftens domene. Jeg fører domener frem til en håndhevbar policy på en kontrollert måte: først den fullstendige kartleggingen, deretter innstramming i trinn, uten å miste legitim e-post.
Rådgivningen foregår på tysk eller engelsk.
- SPF
- DKIM
- DMARC
- p=reject
- DMARC-rapporter
- Beskyttelse mot forfalskning
- Leveringsevne
Hvorfor dette er mer enn tre DNS-poster
Å publisere postene er den raske delen. Det egentlige arbeidet ligger i spørsmålet om hvem som legitimt sender under domenet: ERP-systemet, nyhetsbrevtjenesten, saksbehandlingssystemet, multifunksjonsskriverne, den eksterne lønnsleverandøren. Hver glemt kilde betyr tapt e-post når policyen håndheves. Derfor begynner hvert av mine DMARC-prosjekter med en kartlegging av de faktiske avsenderkildene ut fra DMARC-rapporter og e-postlogger, ikke med å redigere DNS-sonen.
Tjenester
- Kartlegging av avsenderkilderIdentifisere hvert system som sender under domenene dine, også de glemte; ut fra rapporter, logger og analyser av tenanten.
- Utforming av posteneSPF innenfor oppslagsgrensen, DKIM-signering per avsenderkilde, DMARC med en fornuftig alignment-strategi, underdomener og parkerte domener inkludert.
- Trinnvis plan til p=rejectInnstramming via none, quarantine og pct-trinn, med rapportanalyse før hvert steg og definerte avbruddskriterier.
- De vanskelige tilfelleneVideresending, e-postlister, gatewayer foran Microsoft 365, ARC-forsegling: tilfellene DMARC-prosjekter som regel feiler på.
Eksempler fra praksis
- Guide for DNS-administratorer: MX, SPF, DKIM, DMARC: de vanlige feilene når postene publiseres.
- DNS-sjekk for e-post: sjekke SPF, DKIM, DMARC, MTA-STS og DANE for et domene, direkte i nettleseren.
- Analyse av e-posthoder: spore autentiseringsresultatene og DMARC-alignment for en bestemt melding.
