En anställds domän stöder mer än meddelanden som skickas från standardskärmen för webbmail. Personal kan skicka genom delegerade brevlådor, CRM-integrationer, godkända mobilklienter, supportsystem eller externa e-postlistor. En policy som endast baseras på ett lyckat test från en brevlåda förbiser den bredare tjänsten.
Börja med hur människor använder domänen. Syftet är att validera legitima sändningar och fatta ett välgrundat policybeslut samtidigt som rutinkorrespondensen fungerar.
Kartlägg identiteter och ansvar
Skapa en post för varje meningsfull rutt. Inkludera sändningsplattformen och kontot, synligt från identitet, kuvertreturadress, signeringsdomän, ägare och godkännandestatus. En delad postlåda och en leverantörsstyrd HR-plattform kan använda samma From-domän samtidigt som det kräver olika konfigurations- och ägarkontroller.
Använd roll- och tjänsteintervjuer för att komplettera rapportanalys. Fråga personal som deltar i yrkesföreningar, forskare som postar till e-postlistor och team som använder delegerade adresser. Undvik att samla in personligt innehåll bara för att upptäcka rutten.
Avsändare-inventeringsguiden tillhandahåller driftsmodellen. Ägarskapet bör identifiera vem som kan ändra eller avbryta tjänsten, inte bara vem som känner igen leverantörens namn.
Håll autentisering och affärsgodkännande åtskilda
Ett programs meddelande kan passera rå autentisering för en orelaterade leverantörsdomän utan att passera DMARC för medarbetaren Från domän. Omvänt, under RFC 9989 §5.4, bekräftar inte ett skickat meddelande att organisationen har godkänt applikationskontot eller att dess innehåll är pålitligt.
Testa den faktiska rutten som stöds. Behåll den synliga From-domänen, SPF-utvärderade identiteten, DKIM d domän och betrodd mottagare resultat under RFC 8601 §7.1. En skärmdump som visar en offentlig DKIM nyckel fastställer inte att alla anställda eller anslutna tjänster använder den.
Under RFC 9989 §5.3.5, en inriktad passning SPF eller DKIM sökväg kan uppfylla ett meddelandes DMARC passvillkor när en tillämplig policy finns. För fullt deltagande, RFC 9989 §8 inkluderar anpassade SPF och DKIM , rapportering och policypublicering. Håll dessa två frågor åtskilda i acceptansprotokollet.
Bygg en beredskapsmatris efter väg
Följande matris är fiktiv och illustrerar beslut, inte en hyresgästbedömning:
- Rutt: Standard brevlåda för anställda; Bevis: Mottagna tester och rutinrapporter stödjer de förväntade identiteterna; Beslut före en policyändring: Behåll baslinjen och övervaka
- Rutt: Delegerad ekonomibrevlåda; Bevis: Direkt test existerar; delegerad applikationssökväg inte testad; Beslut före en policyändring: Verifiera den saknade sökvägen
- Rutt: CRM-sändning som personaladress; Bevis: Raw DKIM pass använder en icke-relaterad leverantörsdomän; Beslut före en policyändring: Rätt stöds inriktning och testa igen
- Rutt: Anställd postar till en föreningslista; Bevis: Listan ändrar det ursprungliga meddelandet; Beslut före en policyändring: Bedöm indirekt flödesbeteende och policylämplighet
- Rutt: Säsongsbetonad HR-applikation; Bevis: Ägare bekräftad; ingen representant som skickar bevis; Beslut före en policyändring: Ordna ett proportionerligt test eller behåll gapet
En frisk första rad stänger inte de andra. En rutt bör inte bli godkänd bara för att den bidrar med liten volym till ett domänövergripande sjökort.
Håll testomfattningen tydlig. Att testa en auktoriserad mobilklient certifierar inte alla möjliga klient-, ombuds- eller tredjepartsintegration.
Ta allmän interoperabilitet på allvar
Nuvarande RFC 9989 §7.4 rekommenderar att domäner som är värd för användare som kan göra inlägg på e-postlistor på Internet inte bör publicera avvisa. Dess vägledning tar upp konsekvenserna av indirekta vägar, inklusive ändrade meddelanden och post som vidarebefordras av andra system.
För sådana domäner som ändå överväger att avvisa, rekommenderar det avsnittet minst en månad vid ingen, sedan en lika lång karantänperiod, med jämförelse av dispositionsresultat. Den rekommenderar också policyer mot användare som gör inlägg på Internet-e-postlistor och/eller informerar användare om att deltagande kan hindras om domänen väljer att avvisa.
Denna vägledning bör påverka policybeslutet innan en utbyggnad. Det är inte ett problem att lösa genom att meddela att all legitim anställd post så småningom måste passera oförändrad genom varje mellanhand.
En separat domän eller underdomän för ett annat sändningsändamål kan ibland förtydliga äganderätt och konfiguration. Bedöm den verkliga upptäckten och anpassningsrelationerna och inverkan på användarna; separation i sig reparerar inte ett programs signering eller gör att en e-postlista bevarar det ursprungliga meddelandet.
Granska en exakt policydiff
Dokumentera vilken domän och underdomäner den föreslagna ändringen påverkar. Registrera den nuvarande fullständiga policyn och det avsedda nya värdet. Förklara om ändringen påverkar begärd hantering, anpassning, rapportering eller annan inställning.
Dra inte åt flera oberoende inställningar bara för att få ett mer restriktivt utseende. Var och en bör ha sina egna bevis och syfte. Använda guiden för val av policy och vägledning för upptäckt av underdomän för att kontrollera omfattningen.
Tilldela godkännande till någon som är ansvarig för den berörda affärskommunikationen. Godkännandeprotokollet bör namnge kända begränsningar, återvinningsägaren och bevisen som skulle utlösa en omprövning.
Verifiera resultat och undersök undantag
Efter en ändring, testa de definierade rutterna och granska tillgänglig mottagarfeedback. Ett mottagande system kan tillämpa sin egen analys och policy; publicering avslag tvingar inte ett universellt hanteringsresultat under RFC 9989 §5.4.
För ett levererat exempel, undersök pålitliga autentiseringsbevis. För ett avslag, behåll den fullständiga returnerade texten och sändningsplattformsinformationen. Skydda brevlådeinnehåll och personalinformation när du delar prover för utredning.
Håll ett undantag kopplat till en rutt, affärsändamål, ägare och granskningsdatum. Ett brett undantag baserat enbart på ett leverantörsnamn kan överleva det ursprungliga problemet och auktorisera mer än avsett. En okänd källa förblir ett undersökningsobjekt tills bevis styrker dess roll.
Behåll domänen när personalens arbetsflöden förändras
Att ingå i ett CRM, ändra en gateway, delegera en underdomän eller aktivera en ny sändningsfunktion kan förändra bevisen. Gör dessa ändringar till en del av tjänsteägarprocessen istället för att vänta på nästa domänövergripande policyprojekt.
Anställdas post lyckas när legitima personer och godkända tjänster kan kommunicera via stödda vägar med tydliga identitetsbevis. Ett användbart DMARC program förbättrar detta bevis kontinuerligt och väljer policy med domänens allmänna roll förstådd.
Håll nästa åtgärd specifik
I anställningsrutten för anställda rensar inte en verifierad standardpostlåda de delegerade ekonomi- eller säsongsbetonade HR-raderna. CRM-identiteten behöver sitt eget anpassningsbevis; föreningslistan behöver granskas om policyn är lämplig, inte ett löfte om att bevara varje signatur. Håll ruttluckor och accepterade begränsningar synliga. Ingen anställd brevlåda, hyresgäst eller lista testades.