Omfattning och förberedelse
Denna procedur täcker utgående Technolutions Slate-post. Skaffa en Slate-administratör och institutionens DNS ägare. Registrera alla avsedda Från-domäner, inklusive antagningar och alumniflöden som kan använda olika domäner. Bevara nuvarande DNS och den gamla konfigurationen innan du ändrar en etablerad rutt. Ingen hyresgäståtkomst eller faktisk meddelandetest utfördes för den här guiden.
Generera och validera domänkonfigurationen
Öppna Databas > DKIM Konfiguration, slå upp e-postdomänen och skapa dess konfiguration. Använd endast den föreslagna slate-mx-underdomänen om den är oanvänd. Spara och skicka sedan varje genererad DNS rad till IT, inklusive eventuella DMARC rad för granskning mot befintlig policy. Återgå till Validera konfiguration efter publicering. Leverantören använder svarta poster för giltiga poster och röda för olösta. Ytterligare domäner utanför det tillåtna omfånget behöver listan över tillåtna tjänstedomäner under konfigurationsnycklar; valideringsfel kan kräva support. Följ den aktuella Slate-konfigurationskällan nedan.
Håll SPF ändringar på rätt identitet
Technolutions säger att den konfigurerade underdomänen tillhandahåller kuvertsändare och har leverantörsstyrd SPF. Utan DKIM installation använder kuvertet mx.technolutions.net . Dess utgående serverartikel säger att SPF -tillägg för överordnad domän är onödiga för den vägen. Hårdkoda inte de listade serverns IP-adresser i institutionens SPF bara för att de förekommer i en källa: leverantören säger att listan kan ändras.
Ursprunglig institutionell testdesign
Skapa separata kalkylbladsrader för antagning och alumnmeddelanden. För varje, registrera den begärda Från, faktiska Från, kuvert, DKIM -signeringsdomän, väljare och betrodda mottagarresultat. En valideringsskärmdump ensam visar inte vilken domän meddelandet använde. Dessa är testinstruktioner, inte infångade Slate-utgångar.
Ett användbart negativt fall är en tillåten domänkonfiguration som ännu inte har blivit tillgänglig i applikationen. Försök att söka igen efter leverantörens dokumenterade spridningsintervall, men särskilj applikationstillgänglighet från DNS cacheförfall. Ta inte bort en fungerande inställning bara för att göra statusändringen. Låt IT-avdelningen identifiera konflikten först och bevara en återställningsväg.
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 det synliga Från: strikt inriktning 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.
Följ en statusbok för ytterligare domäner
Skriftligt fall SL-01 antar att institutionen behöver alumni@example.org , men den domänen ligger utanför instansens tillåtna omfattning. Administratören har sparat example.org i listan över tillåtna tjänstedomäner; den illustrativa förflutna tiden är fem minuter, konfigurationstillgängligheten förblir okänd och ingen DKIM -post har genererats för den. Det dokumenterade 15–20 minuters programutbredningsfönstret skiljer sig från DNS cache. Slate-ägaren bör vänta det intervallet, försöka söka igen och följa arbetsflödet för validering av genererad domän innan han testar alumnipost. Från, kuvert och alla mottagarresultat förblir okända. Ta inte bort en icke-relaterad fungerande antagningskonfiguration. Ingen institutionsdata, konfigurationsnyckel eller meddelande nåddes.
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.