Att ställa in DMARC för en anpassad Microsoft 365 domän, upprätta domänens sändningsrutter, konfigurera lämpligt SPF policy, aktivera anpassad domän DKIM och verifiera ett justerat resultat på mottagen e-post. Publicera en DMARC TXT post är ett steg i den sekvensen.
Den här guiden täcker anpassad domänsändning via Microsoft 365 . Bekräfta Microsofts molnmiljö och eventuella hybrid-, relä- eller utgående gatewayarrangemang innan du använder exemplen. Applications sending outside Microsoft 365 need their own supported authentication configuration, even when they use the same visible From domain.
Bekräfta domänen, DNS värden och Microsoft-miljön
Bekräfta den anpassade domänen, dess auktoritativa DNS värd, Microsoft 365 miljön och den behörighet som behövs för att hantera signering. Spara befintliga SPF , DKIM och DMARC -poster innan du ändrar dem.
Blanda inte ihop offentlig DNS administration med hyresgästens domänlista. Registraren kan också vara DNS värden, men det behöver inte vara det. Kontrollera de delegerade namnservrarna innan du redigerar en zon.
Lista varje rutt som använder domänen. In particular, distinguish ordinary Exchange Online sending from applications using relay, direct send, another SMTP provider or an outbound gateway. Endast produktnamnet identifierar inte den slutliga undertecknaren.
Kartlägg anställdas post och ansökningspost
En flytt till Microsoft 365 flyttar inte automatiskt faktureringsapplikationen, webbplatsens kontaktformulär eller rekryteringsplattformen. Dessa tjänster kan fortfarande visa din domän medan du skickar via en annan leverantör.
Be om en enkel servicekarta: medarbetarpost, applikationspost och utlagd kommunikation, med en ägare bredvid varje rutt. Kräv ett test av mottagna meddelanden för kritiska flöden som lösenordsåterställning och faktureringsmeddelanden. Leveransen fungerar, ansvarig kommunikation, inte en skärmdump av en aktiverad hyresgäst-inställning.
Konfigurera tillämplig SPF policy
Microsofts dokumenterade exempel för en domän som skickar **endast genom dess standard Microsoft 365 -tjänst eller GCC** är:
v=spf1 include:spf.protection.outlook.com -allDetta är ett exempel med omfattning, inte en ersättning för en befintlig policy för blandade tjänster. Microsofts olika dokument inkluderar domäner för GCC High/DoD och för dess tjänst som drivs av 21Vianet. Följ de aktuella instruktionerna för din miljö.
Publicera en tillämplig SPF policy på den utvärderade domänen. Om en giltig policy redan finns, granska och uppdatera den i stället för att lägga till en annan SPF rekord. Inkludera endast motiverade sändningsbehörigheter och kontrollera hela beroendesökvägen mot SPF gränser.
Publicera båda klientgenererade DKIM CNAMEs
Microsoft 365 anpassad domän DKIM använder två CNAME uppgifter. Få deras exakta värden från Defender-portalens DKIM konfiguration eller Exchange Online PowerShell. Do not build a target from an old naming template: Microsoft documents more than one target format, and generated values can contain a tenant-specific component.
I en auktoriserad Exchange Online PowerShell-session hämtar denna skrivskyddade kontroll de konfigurerade målen:
Get-DkimSigningConfig -Identity example.com | Format-lista aktiverad,Status,Väljare1CNAME,Väljare2CNAMEIf the domain has no signing configuration, use Microsoft's documented initial-configuration procedure before expecting those properties to exist. I Defender-portalen är det relevanta området Inställningar för e-postautentisering, sedan DKIM .
Publicera **båda** genererade CNAME poster, verifiera deras offentliga svar och aktivera anpassad domänsignering genom den hyresgästprocedur som stöds. En CNAME post delegerar verifieringsnyckelhantering; det är inte en begäran att klistra in en privat nyckel eller en påhittad TXT nyckel.
Kontrollera DNS redigerarens beteende noggrant. En panel som lägger till zonnamnet kan förvandla ett fullständigt angett värdnamn till ett duplicerat namn. Bevara de exakta publicerade ägar- och målvärdena i ändringsposten.
Lägg till den avsedda DMARC policyn och rapporteringsdestinationen
Om domänen börjar en övervakad distribution visas en illustrativ post på _dmarc.example.com är:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comI exemplet antas en fungerande rapportdestination på samma domän. Byt ut den mot den godkända adressen och verifiera insamlingen. Externa destinationer kan kräva ytterligare rapporteringstillstånd. Försvaga inte en befintlig tillsynspolicy bara för att matcha detta exempel.
Använd guiden för att skapa poster för publicerings- och verifieringssekvensen och DMARCbis beredskapsguide när du granskar äldre lanseringsinställningar.
Verifiera meddelanden efter hela sändningsrutten
Skicka ett kontrollerat meddelande till en separat extern mottagare och inspektera originalmeddelandet där. Registrera den synliga From, SPF-utvärderade identiteten, varje relevant DKIM d=-domän och det betrodda DMARC resultatet.
Upprepa testet genom kritiska applikationer och eventuell slutlig utgående gateway. If the visible From is your custom domain but the only passing signature uses an unrelated tenant identity, investigate custom-domain signing and the actual route. Om en gateway ändrar signerat innehåll, verifiera resultatet efter den gatewayen.
- Kontrollera: SPF policy; Bevis att behålla: Auktoritativt svar och utvärderad sändningsväg
- Kontrollera: DKIM delegation; Bevis att behålla: Både exakta CNAME och klientkonfigurationsstatus
- Kontrollera: Livesignering; Bevis att behålla: Mottagen signatur och pålitligt verifieringsresultat
- Kontrollera: DMARC ; Bevis att behålla: En förbipasserande linjerad väg och observerad policykontext
- Kontrollera: Företagstäckning; Bevis att behålla: Tester för de applikationer som organisationen faktiskt använder
- Rekordacceptans och löpande ägande
Godkänn implementeringen mot ett namngivet tjänstelager. Registrera ändringsgodkännande, DNS ägande, kritiska flödesresultat och återstående undantag. En hyresgästs giltiga signeringsstatus visar inte att varje extern ansökan täcks.
Håll molnmiljön tydlig i driftdokumentationen. Ett standardmolnexempel får inte i det tysta bli en statlig molninstruktion. Tilldela periodiska kontroller för övergivna tjänster och delegerade väljare samt fel i aktuell trafik.
Behåll förmågan att återställa det tidigare godkända tillståndet när en ändring misslyckas, samtidigt som incidentbevisen bevaras. A final review should explain the remaining risks of compromised accounts and authenticated malicious mail, rather than promising that a DMARC pass makes every message safe.
Den praktiska takeawayen
Inställningen är klar när de publicerade posterna, hyresgästens signeringsstatus, mottagna meddelandeidentiteter och rapporteringsväg överensstämmer. Behåll serviceinventeringen och undantagen med ändringsposten; de är baslinjen för nästa applikation eller gatewayändring.
Separera anställd-e-postbevis från ett CRM-undantag
Skriftligt fall M365-01 förutsätter att anställds e-post från staff@example.org har ett pålitligt godkänt DKIM signatur med d=example.org. Fakturerings-CRM använder billing@example.org , men dess enda registrerade signatur är från en icke-relaterad leverantörsdomän och dess SPF resultat är okänt. E-postbevis för anställda fastställer inte CRM-resultatet, och de partiella CRM-bevisen kan inte motivera en fullständig DMARC -dom. The CRM owner must identify its supported aligned identity and collect a controlled external message before the domain owner evaluates enforcement readiness. Dessa är fiktiva identiteter och resultat; ingen hyresgäst, DNS ändring eller e-postsändning inträffade.