SPF, DKIM och DMARC: e-postautentisering som håller
De stora e-postleverantörerna kräver autentiserad e-post, men din egen DMARC har stått på p=none i åratal och ingen vet vilka system som skickar under företagets domän. Jag för domäner till en tillämpbar policy på ett kontrollerat sätt: först den fullständiga inventeringen, sedan skärpning i steg, utan att förlora legitim e-post.
Rådgivningen sker på tyska eller engelska.
- SPF
- DKIM
- DMARC
- p=reject
- DMARC-rapporter
- Skydd mot förfalskning
- Leveransbarhet
Varför detta är mer än tre DNS-poster
Att publicera posterna är den snabba delen. Det verkliga arbetet ligger i frågan om vem som legitimt skickar under domänen: affärssystemet, nyhetsbrevstjänsten, ärendehanteringssystemet, multifunktionsskrivarna, den externa lönetjänsten. Varje bortglömd källa innebär förlorad e-post när policyn väl tillämpas. Därför börjar alla mina DMARC-projekt med en inventering av de faktiska sändande källorna utifrån DMARC-rapporter och e-postloggar, inte med att redigera DNS-zonen.
Tjänster
- Inventering av sändande källorIdentifiera varje system som skickar under dina domäner, även de bortglömda; utifrån rapporter, loggar och analyser av tenanten.
- Utformning av posternaSPF inom uppslagsgränsen, DKIM-signering per sändande källa, DMARC med en genomtänkt alignment-strategi, underdomäner och parkerade domäner inräknade.
- Stegvis plan till p=rejectSkärpning via none, quarantine och pct-steg, med rapportanalys före varje steg och definierade avbrottskriterier.
- De svåra fallenVidarebefordran, sändlistor, gateways framför Microsoft 365, ARC-försegling: de fall som DMARC-projekt oftast faller på.
Exempel från praktiken
- Guide för DNS-administratörer: MX, SPF, DKIM, DMARC: de vanliga misstagen när posterna publiceras.
- DNS-kontroll för e-post: kontrollera SPF, DKIM, DMARC, MTA-STS och DANE för en domän, direkt i webbläsaren.
- Analys av e-posthuvuden: spåra autentiseringsresultaten och DMARC-alignment för ett specifikt meddelande.
