Identifiera rutten
TOPdesk kan använda sina SaaS e-postservrar eller en organisations e-postserver. Denna procedur täcker SaaS-rutten; om din organisation vidarebefordrar via sin egen server, skaffa serverns autentiseringsinstruktioner istället. Spela in sändningsarbetsflödet och avsedd Från-domän innan du redigerar DNS . Ingen kontokonfiguration eller livetest utfördes för den här guiden.
Auktorisera SaaS-sändning
TOPdesks nuvarande källa uppmanar administratörer att slå samman include:spf.topdesk.net med befintliga SPF istället för att lista enskilda servrar. Begär domänspecifik DKIM och en domänbegränsning via My TOPdesks förfrågningsformulär. Domänbegränsning begränsar användningen av din domän till dina TOPdesk-miljöer. Få de resulterande kontoinstruktionerna för DNS och aktivering; denna offentliga sida tillhandahåller inte en universal väljare eller nyckel. Improvisera inte en uppladdning av privat nyckel baserat på ett äldre recept från tredje part. Se TOPdesk-källan nedan.
Original design för servicedesk-acceptans
Använd en manuellt utlöst biljettavisering och en automatisk arbetsflödesavisering, var och en endast adresserad till en kontrollerad testbrevlåda. Registrera vilken rutt som skickades varje meddelande. Jämför faktiska From-värden med den godkända listan; anta inte ett operatörsmeddelande och en bakgrundsautomatisering delar en avsändare. Bevara de returnerade DKIM -installationsinstruktionerna tillsammans med DNS bevisen utan att avslöja autentiseringsuppgifter.
En separat säkerhetskontroll hör till biljetten: identifiera alla legitima TOPdesk-miljöer som måste använda domänen innan du begär begränsning. En ofullständig miljöinventering kan störa ett verkligt servicedesk-arbetsflöde. Acceptansdesignen frågar efter den inventeringen och för begärans resultat, men hävdar inte att begränsningen har tillämpats eller testats.
Bestäm vad ett misslyckande betyder
Ett SPF -pass för en leverantörsdomän upprättas inte av sig självt inriktning med servicediskens From. Om DKIM godkänns med en icke-relaterad signeringsdomän, samla in råhuvudena och jämför dem med den domänspecifika konfigurationsbegäran. Om båda autentiserade identifierarna skiljer sig från den avsedda Från, stoppa releasen och be tjänsteägaren att lösa rutten. Använd inte en hel domän DMARC dispens som första reparation.
Om ett test lyckas genom organisationens relä men misslyckas genom SaaS, är det bevis på två olika vägar, inte intermittent DNS . Behåll ruttspecifika resultat och återställningsinstruktioner. En kontrollerad switch tillbaka till ett redan validerat relä kan vara ett återställningsalternativ först efter att ägaren har bekräftat att den stöder det nödvändiga arbetsflödet.
Bevisa identiteten hos mottagaren
Använd en kontrollerad extern brevlåda och skicka igenom produktionsarbetsflödet, med ofarligt innehåll och utan kunddata. Spara råmeddelandet, tidsstämpeln och det mottagande systemets Authentication-Results. Ignorera autentiseringspåståenden som infogats av en otillförlitlig avsändare. Spela in den synliga Från-domänen, Return-Path eller autentiserad kuvertidentitet, och varje DKIM d= och s= par. Ett visningsnamn eller svarsadress är inte DMARC identiteten.
SPF passet auktoriserar den anslutande servern för den utvärderade kuvertidentiteten. DKIM pass validerar en signatur för sin signeringsdomän. DMARC behöver en överföringsmetod vars domän är i linje med den synliga From: strikt justering kräver samma domän; avslappnad anpassning tillåter den tillämpliga organisation-domän-relationen. En leverantörsägd signatur kan passera utan att autentisera din synliga Från. En passning inriktad DKIM signatur kan uppfylla DMARC även när en annan signatur misslyckas. Dessa protokollregler kommer från RFC 7208 , RFC 6376 och RFC 9989, listad nedan.
Kontrollera auktoritativ DNS innan du diagnosticerar cacher. Fråga en auktoritativ server om det exakta namnet och typen och jämför sedan en rekursiv resolver efter dess cachade livstid. För DKIM , följ någon CNAME till dess TXT -svar med publik nyckel. Publicera aldrig en privat nyckel. Behåll en SPF policy vid varje utvärderat namn och kontrollera gränsen för tio DNS-lookup-orsakande termer för kapslade inkluderar. Ersätt inte en delad SPF -policy med ett leverantörsexempel.
Återhämtning och acceptans
Pausa det påverkade arbetsflödet om tester visar en ny regression. Jämför den ändrade posten med den sparade versionen och ångra endast den ändringen efter att ha kontrollerat andra avsändare. Kontrollera DNS igen och skicka om efter återställning; att återställa ett värde rensar inte varje resolver omedelbart. Håll gamla DKIM -verifieringsposter tillgängliga medan tidigare signerade meddelanden fortfarande kan vara på väg, om inte en säkerhetsincident kräver återkallelse.
Acceptera ändringen endast när DNS , applikationsstatus och ett riktigt mottaget meddelande överensstämmer. Registrera flödesägaren, bevistidsstämpel och nästa granskningsutlösare. Enbart inkorgsplacering är inte bevis på autentisering, och framgångsrik autentisering garanterar inte placering i inkorgen. Skärp inte en delad domäns DMARC policy på grundval av en leverantörs test. Inventera de andra legitima källorna först.
Inventera miljöerna innan domänbegränsning
Skriftligt fall TD-01 antar att support@example.org används av två legitima SaaS-miljöer, produktion och utbildning. Den föreslagna begäran om begränsning listar endast produktion; ingen av miljöns resulterande restriktionstillstånd har observerats. Tjänsteägaren måste stämma av båda miljöerna med säkerhetsägaren innan den begär den avsedda gränsen, och planera ofarliga manuella och automatiserade aviseringskontroller för var och en. DNS administratören behöver fortfarande det domänspecifika DKIM svaret; ingen väljare eller nyckel är uppfunnen här. Alla meddelandeautentiseringsresultat förblir okända. Ingen begäran, begränsning, nyckeluppladdning eller biljettmeddelande utfördes.
Bevara verkställighetsgränsen
RFC 9989 avsnitt 7.4 kräver giltig DKIM , inte enbart SPF , för domänpublicering p=reject, och varnar för interoperabilitet med indirekt e-post och e-postlistor. Ett enda framgångsrikt test för direktmeddelanden är inte ett bevis på att varje legitim väg är redo för en starkare politik. Behåll befintligt godkänt skydd medan du diagnostiserar det faktiska gapet; varje policyändring behöver ett eget beslut.