Sådan skifter du sprog på standardmapper i Outlook – både for brugere og delte postkasser via PowerShell

Når Outlook‑mapper som Inbox, Sent Items, Drafts og Deleted Items står på engelsk selvom brugeren forventer dansk, skyldes det normalt én af disse årsager:

1. Brugeren har første gang åbnet Outlook Web App (OWA) med engelsk sprog.
2. Den delte postkasse er oprettet med engelsk standardsprog i Exchange Online.

Heldigvis kan du ændre sproget og gendanne mapperne via PowerShell – både for almindelige brugere og Shared Mailboxes. Her er en trin‑for‑trin guide.

Trin 1: Forbind til Exchange Online PowerShell

Kør følgende i PowerShell (Administrator):

Install-Module ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

Trin 2: Tjek nuværende sprog for en postkasse

Get-MailboxRegionalConfiguration -Identity user@domain.dk

Hvis Language står til “en-US”, er mapperne oprettet på engelsk.

Trin 3: Skift sprog og gendan mapper for en normal bruger

Set-MailboxRegionalConfiguration -Identity user@domain.dk -Language da-DK -LocalizeDefaultFolderName

Dette sætter dansk som sprog og omskriver standardmapper til dansk.

Trin 4: Gør det samme for en delt postkasse

Set-MailboxRegionalConfiguration -Identity sharedmailbox@domain.dk -Language da-DK -LocalizeDefaultFolderName

Brugerne skal typisk genstarte Outlook bagefter.

Trin 5: Hvis mapperne ikke ændrer sig → tving gendannelse

Set-Mailbox -Identity user@domain.dk -ForceDefaultFolderReset

For delt postkasse:

Set-Mailbox -Identity sharedmailbox@domain.dk -ForceDefaultFolderReset

Dette gendanner kun standardmapper – brugerens egne mapper sammenlægges ikke.

Trin 6: Skift sprog for alle brugere på én gang

Alle mailbokse:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
Set-MailboxRegionalConfiguration -Identity $_.PrimarySmtpAddress -Language da-DK -LocalizeDefaultFolderName
}

Kun delte postkasser:

Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | ForEach-Object {
Set-MailboxRegionalConfiguration -Identity $_.PrimarySmtpAddress -Language da-DK -LocalizeDefaultFolderName
}

Hvornår slår ændringerne igennem?

Outlook Web App: med det samme
Outlook Desktop: efter genstart
Outlook mobilapps: når de synkroniserer igen

Hvis brugeren stadig ser engelske mapper, kan Outlook‑profilen slettes og reoprettes.

Konklusion

Med PowerShell kan du hurtigt sikre ensartede danske mapper i både individuelle og delte postkasser – og du kan endda udføre ændringerne i bulk. Det giver en mere konsistent brugeroplevelse og færre supportsager.

✅ Hvad betyder arc=fail i dine DMARC‑rapporter?

Når du ser:

arc=fail

så betyder det, at en videresendende server (fx mailingliste, auto‑forward, antivirus‑gateway, journaling‑hop osv.) ikke har kunnet validere ARC‑kæden.

ARC bruges til at bevare autentificeringsresultater gennem forwarding og består af AAR, AMS og ARC‑Seal. Hvis en af disse dele ikke kan valideres, får du arc=fail.
Dette stemmer overens med den dokumenterede funktion: ARC bevarer authentication, men mislykkes hvis forwarding ændrer mailen eller kæden ikke er korrekt signeret.
Forwarding kan ødelægge SPF og DKIM, og ARC skal så redde kæden – hvis det mislykkes, giver det fejl. [trndigital.com] [github.com]

Men det vigtige er:
ARC evalueres af modtagerens server, ikke af din server som afsender.

---

❌ Så hvad kan DU som afsender ikke gøre noget ved?

Du kan ikke rette:

• Hvis en ekstern videresender ændrer mailens content og brækker DKIM
• Hvis deres server ikke understøtter ARC
• Hvis forwarding‑serveren har forkert konfiguration
• Hvis deres ARC‑seal er udløbet, forkert signeret eller mangler
• Hvis modtagerens mailserver ignorerer ARC, accepterer eller afviser det

Alt dette er dokumenteret i den tekniske forklaring på forwarding‑problemer og hvordan ARC forsøger – men ikke altid kan – at bevare autentificering. [github.com]

Med andre ord: ARC er et forwarding‑problem, ikke et afsenderproblem.

---

✅ Hvad kan DU faktisk gøre noget ved?

Selvom du ikke kan kontrollere ARC‑fail direkte, kan du sikre at din ende er fuldstændig korrekt, så ARC‑kæden får et stabilt udgangspunkt.

Du kan:

---

1️⃣ Sikre at DKIM-signaturen er stabil og stærk

• Brug 2048-bit nøgler
• Brug moderne DKIM‑canonicalization, fx relaxed/relaxed
  (Dette understøttes af email‑autentifikationsprincipperne fra Microsoft Learn) [techcommun...rosoft.com]

Hvorfor hjælper det?
Hvis forwarding kun ændrer få headers, men ikke brækker DKIM, er ARC ofte slet ikke nødvendig.

---

2️⃣ Sørg for korrekt SPF og alignment

• Alle dine legitime afsenderservere skal være i SPF
• Undgå SPF‑rekorder med +all eller for mange includes
  SPF er et centralt krav for DMARC og påvirker ARC’s baseline. [techcommun...rosoft.com]

---

3️⃣ DMARC‑policy bør være korrekt

• Start med p=none under test
• Gå senere til quarantine eller reject
  DMARC alignment understøtter ARC’s funktion, fordi ARC bygger videre på disse resultater. [techcommun...rosoft.com]

---

4️⃣ Opsæt ARC på dine egne mail‑hop, hvis du har dem

Hvis du fx bruger:

• en mailgateway
• spamfilter
• routing før udgående mail
• journaling eller arkivering

Så skal din egen infrastruktur også ARC‑signere for at undgå kædebrud.

Hvis du ikke signerer ARC selv, kan kæden gå i stykker tidligt.

---

5️⃣ Undgå at bruge systemer der ændrer mails unødigt

Forwarding og content‑modifikation er hovedårsagen til ARC‑fail.
Suped beskriver tydeligt at videregivelse ændrer mailens headers og body, hvilket ødelægger DKIM og dermed også ARC‑kæder. [github.com]

Hvis du selv kontrollerer nogen af de mellem‑hops, kan du reducere header‑manipulation.

---

🟥 Skal du være bekymret over arc=fail?

Ofte nej.

ARC er valgfrit, og selv ved arc=fail vil mange modtagende systemer ikke afvise mailen, så længe:

• SPF eller DKIM passer
• DMARC alignment er OK
• ARC‑fail ikke overskriver de oprindelige autentificeringer

Microsoft Learn bekræfter, at ARC er et ekstra lag, ikke en erstatning for SPF, DKIM og DMARC. [techcommun...rosoft.com]

Kun tjenester der kræver ARC (fx visse Google/Yahoo politikker for forwarded mail) kan vælge at reagere på det.

---

⭐ Konklusion

arc=fail er næsten aldrig noget du som afsender kan rette direkte, fordi fejlen opstår på en mellemserver, der videresender eller ændrer mailen.

Men du kan sikre:

• robuste DKIM‑signaturer
• korrekte SPF‑optegnelser
• korrekt DMARC alignment
• ARC‑signering i egne hops

…så dine mails har bedst chance for at overleve forwarding‑kæderne.

Når selector2 i Microsoft 365 DKIM driller – og hvorfor en key-rotation løser problemet

Hvis du arbejder med e-mail‑sikkerhed i Microsoft 365, har du sikkert stiftet bekendtskab med DKIM‑opsætningen og de to selectors: selector1 og selector2. Normalt kører tingene gnidningsfrit, men indimellem rammer man et scenarie, hvor selector2 ganske enkelt nægter at virke – uanset hvor mange gange DNS‑poster dobbelttjekkes.

Hvorfor fejler selector2?

Når selector2 ikke fungerer, skyldes det typisk én af følgende årsager:

• DNS-posten for selector2 er forkert formateret eller mangler helt.
• DNS‑udbyderen cacher gamle værdier for længe.
• Der ligger gamle eller ugyldige DKIM‑nøgler i Microsoft 365, som forhindrer korrekt signering.
• Domænet har tidligere været flyttet, og gamle nøgler hænger stadig fast i systemet.

Uanset hvad rodårsagen er, oplever mange, at selector2 nægter at komme online – selv efter lange DNS‑debug‑sessioner.

Den hurtige og sikre løsning: Rotate DKIM Keys

Heldigvis er løsningen næsten altid simpel: Lav en DKIM key‑rotation i Microsoft 365.

Når du roterer nøglerne, gør Microsoft 365 følgende:

1. Genererer et nyt sæt DKIM‑nøgler
2. Udgiver nye selector‑værdier
3. Sikrer at både selector1 og selector2 bliver opdateret korrekt
4. Tvinger systemet til at slippe gamle, defekte eller cached nøgler

Efter rotationen kan du opdatere DNS‑poster med de nye værdier, og i langt de fleste tilfælde vil både selector1 og selector2 fungere fejlfrit igen.

Hvorfor er rotation en god praksis?

Foruden at løse problemer er det faktisk en anbefalet sikkerhedspraksis at rotere DKIM‑nøgler med jævne mellemrum. Det reducerer risikoen for misbrug og sikrer, at dine DKIM‑signaturer lever op til moderne standarder.

Konklusion

Hvis du ikke kan få selector2 til at virke i Microsoft 365 – selv efter korrekt DNS‑opsætning – er den bedste løsning næsten altid at rotere DKIM‑nøglerne. Det rydder op i gamle nøgler, opdaterer selectors og får DKIM til at køre stabilt igen.

Sådan aktiverer du Microsoft 365 Baseline Security Mode – den nye standard for sikkerhed i 2025–2026

Publiceret: 8. februar 2026

Microsoft 365 har taget et stort skridt mod “secure‑by‑default”. Med Baseline Security Mode (BSM) kan du med få klik løfte sikkerhedsniveauet på tværs af Exchange, Teams, SharePoint/OneDrive, Entra og Office — uden at fin‑tune hundredevis af indstillinger manuelt. BSM blev introduceret i 2025 som en tenant‑omfattende baseline og henvender sig særligt til travle M365‑admins, der vil have maks effekt pr. minut. 

Samtidig buldrer Microsofts roadmap videre i 2025–2026 med Copilot, Agent Mode og nye sikkerheds‑defaults, som gør baselines endnu vigtigere at få på plads nu. 

---

Hvad er Baseline Security Mode?

Baseline Security Mode er en tenant‑wide sikkerhedsbaseline i Microsoft 365, der samler Microsofts egne bedste anbefalinger i én switch. Første udrulning dækker 20+ baseline policies på tværs af fem kerneområder (Office, Exchange, Teams, SharePoint/OneDrive og Entra) og er målrettet bredt — fra SMB til enterprise. 

Formålet er at:

• Forenkle opsætning: slip for at jagte settings i fem forskellige portaler.
• Hæve bundniveauet: stærkere defaults i en tid med AI‑funktioner, nye samarbejdsformer og mere eksternt delingstryk.
• Minimere fejlkonfigurationer: mange brud starter med små misconfigs; BSM reducerer risikoen. 

---

Hvorfor er det ekstra relevant i 2026?

Microsoft 365 bevæger sig ind i en AI‑først hverdag (Copilot, Agent Mode, Security Copilot). Når intelligens lagres tæt på dine data, stiger kravene til identitet, deling, mail og device‑kontrol — og Microsoft løfter netop disse “defaults” på tværs af planer i 2026‑opdateringerne. 

• Copilot/Agent Mode bliver dybere integreret i Word, Excel, Teams m.m. → Baseline‑kontroller for adgang og databeskyttelse bliver kritiske. 
• Flere sikkerhedsfunktioner rulles bredere ud på tværs af licenser (fx URL‑beskyttelse/Defender for Office P1 i flere planer). 
• Security Copilot kobles tæt på Defender/Entra/Intune/Purview for hurtigere respons — men værdi forudsætter solide baselines. 

---

Hvad indeholder Baseline Security Mode? (eksempler)

BSM er ikke én enkelt regel — det er et sæt koordinerede policies. Her er typiske områder, der indgår i baseline‑profilen:

• Exchange Online: Blokér “direct send”; strammere anti‑phishing defaults; styrket håndtering af indgående URL’er. 
• Microsoft Teams: Beskyt mod ondsindede URL’er i chats/kanaler; forhindr skærmoptagelse i møder (policy‑styret). 
• Ekstern adgang: Granulær kontrol for gæsteadgang i Teams og mere sikre delingsdefaults i SharePoint/OneDrive. 
• Entra (Azure AD): Baseline for identitets‑ og adgangskontrol (fx stærkere standarder for auth‑metoder). 

Bemærk: Microsoft kan løbende udvide BSM’s omfang. Tjek altid seneste release notes/roadmap for ændringer. 

---

Forudsætninger og roller

• Rollekrav: Security Administrator eller Global Administrator for at aktivere BSM.
• Licens: Ifølge de første udrulninger er BSM tilgængelig på tværs af alle M365‑abonnementer (bred tilgængelighed). Verificér i din tenant, da Microsoft kan ændre plan‑tilgængelighed.

---

Trin‑for‑trin: Sådan aktiverer du Baseline Security Mode

Varighed: 5–15 minutter (ex. validering)
Indvirkning: Tenant‑wide (planlæg gerne uden for peak)

1. Log ind i Microsoft 365 admin center med en Security Admin eller Global Admin. 
2. Navigér til Settings → Org settings → Security & Privacy. 
3. Vælg Baseline Security Mode i listen.
4. Klik Enable og bekræft. (Overvej change ticket + kommunikation til it‑drift.)

Tip til implementering:

• Start med pilot (fx et mindre forretningsområde), mål effekten (alerts, brugerfeedback), og rul derefter ud org‑wide.
• Sammenlign med jeres eksisterende Conditional Access, DLP og Safe Links/Attachments‑policyer for at undgå konflikter.

---

Tjekliste: Hvad skal du kontrollere efter aktivering?

• Mailflow: Test ind/udgående post, specielt hvis I tidligere brugte “direct send” fra printere/scannere. Planlæg alternativ (SMTP AUTH/connector). 
• Teams møder: Valider at mødepolitikker ikke spænder ben for reelle behov (screen capture policies kan påvirke support/træning). 
• Ekstern deling: Bekræft at forretningskritiske delingsscenarier (eksterne projekter/gæster) stadig fungerer, men nu mere kontrolleret. 
• Sikkerhedsalarm‑støj: Brug få dage på at kalibrere alert‑niveauer for at undgå “alert fatigue”. 

---

Samspil med 2026‑nyheder: Copilot, Agent Mode og plan‑opdateringer

Når I har baseline på plads, får I mere ud af de nye AI‑funktioner:

• Agent Mode / Copilot i Office‑apps: Baseline‑adgang & delingspolitikker mindsker risiko, når Copilot arbejder på tværs af filer, mail og mødenoter. 
• Plan‑udvidelser (fx Defender for Office P1 og bredere URL‑sikkerhed) øger niveauet — også i “lavere” planer — men kræver stadig korrekt konfiguration og baseline. 
• Security Copilot i E5: AI assisterer triagering og respons; baselines reducerer støj og skaber bedre signal‑til‑støj for SOC‑teams. 

---

Faldgruber og “gotchas”

1. Direct send deaktiveres: Enheder, der sender mail uden auth (MFP/IoT), kan fejle. Skift til SMTP AUTH med app‑password (hvis tilladt) eller opret en connector fra en godkendt udgående IP. 
2. Skærmoptagelses‑blokering i Teams: Gør undtagelser for support/træning, hvis nødvendigt, via dedikerede mødepolitikker.
3. Ekstern adgang: For stramme defaults kan bremse projekter. Indfør godkendt gæsteforløb (invitationer, udløb, review). 
4. Policy overlap: Har I allerede Conditional Access‑pakker og Teams/SharePoint‑policies, så dokumentér prioritet og undtagelser. 

---

Metrics: Sådan måler du, at BSM virker

• Reducerede hændelser i Defender/Incidents pr. uge (efter baseline) — track over 4–6 uger. 
• Phishing‑klikrate i kampagner (før/efter). En lavere klikrate efter BSM + URL‑beskyttelse er et godt tegn. 
• Færre misconfig‑fund i periodiske tenant reviews (CIS‑lignende checklister). 

---

FAQ

Er Baseline Security Mode det samme som Security Defaults?
Nej. Security Defaults i Entra er et sæt generelle identity‑defaults. BSM rækker bredere (Exchange, Teams, SharePoint/OneDrive, Office + Entra) og kurateres som en samlet Microsoft 365‑baseline. 

Påvirker BSM licenser/planer?
BSM er designet til bred tilgængelighed på tværs af M365‑abonnementer, men Microsoft kan justere over tid. Verificér i din tenant og følg roadmap for ændringer i 2026. 

Skal vi stadig lave vores egne policies?
Ja. Se BSM som “det nye minimum”. Du bør stadig konfigurere Conditional Access, DLP, Sensitivity labels, Safe Links/Attachments mv. efter din risikoprofil — især når nye URL‑/mailbeskyttelser udrulles bredere i planerne i 2026.

Spiller BSM sammen med Security Copilot?
Ja. En stærk baseline giver bedre data‑kvalitet og mindre alarm‑støj, hvilket gør Security Copilot mere effektiv i triagering og respons.

---

Tjekliste (print‑venlig)

• Roller: Global/Security Admin klar.
• Aktivér Baseline Security Mode i Admin center → Org settings → Security & Privacy.
• Test mailflow (printere/scannere/IoT).
• Valider Teams‑mødepolitikker (screen capture).
• Gennemgå ekstern deling (Teams/SharePoint).
• Plan for undtagelser/overstyringer (CA, DLP, Safe Links/Attachments).
• Mål effekten (Defender incidents, phishing‑klikrate, review‑fund).

---

Konklusion

Baseline Security Mode er den hurtigste måde at hæve sikkerheds‑grundniveauet i Microsoft 365 i 2026. Det er ikke en erstatning for jeres egne policies — men et stærkt fundament, der står mål med den accelererende AI‑udvikling og Microsofts 2026‑opdateringer. Start med pilot, mål effekten, og rul derefter ud i hele organisationen. 

🔐 DNS‑baseret mailsikkerhed – komplet oversigt (inkl. SPF/DKIM/DMARC/DANE)

Her er ALLE centrale teknologier, du kan implementere på DNS‑niveau for at sikre både indgående og udgående mail.

---

✅ 1. SPF (Sender Policy Framework) – DNS TXT‑record

Beskytter mod: spoofing (hvem må sende fra dit domæne)

SPF definerer hvilke servere/IP’er der har lov til at sende mail på vegne af domænet.

Eksempel:

v=spf1 include:spf.protection.outlook.com -all

---

✅ 2. DKIM (DomainKeys Identified Mail) – DNS TXT‑record

Beskytter mod: manipulation af mailindhold (integritet)

DKIM lægger en digital signatur i mailen, og den offentlige nøgle ligger i DNS.

Eksempel:

selector._domainkey.example.com  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

---

✅ 3. DMARC – DNS TXT‑record

Beskytter mod: misbrug af domænet + rapportering

DMARC kræver SPF/DKIM alignment og styrer håndhævelse.

Eksempel (reject):

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

---

🔒 4. DANE (DNS‑Based Authentication of Named Entities) – DNS TLSA-record

Beskytter mod: MITM‑angreb på SMTP, certifikat‑spoofing
Kræver: DNSSEC

Bruges til at binde TLS‑certifikatet til SMTP‑serveren via DNS.

Eksempel:

_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash>

---

🛡️ 5. DNSSEC (DNS Security Extensions)

Beskytter mod: manipulation af DNS‑records (fundamentet for DANE)

DNSSEC tilføjer kryptografisk signering af dine DNS‑records.

Hvis du har DANE, bør DNSSEC være aktiv, men mange har det stadig ikke korrekt.

---

📦 6. MTA‑STS (SMTP Strict Transport Security)

Beskytter mod: TLS‑downgrade angreb, MITM når DANE ikke bruges

Består af:

• TXT‑record: _mta-sts.domæne
• HTTPS policy‑fil på:
  https://mta-sts.<domæne>/.well-known/mta-sts.txt

Eksempel TXT:

_mta-sts.example.com TXT "v=STSv1; id=20260208"

---

📊 7. TLS‑RPT (SMTP TLS Reporting)

Beskytter: indirekte – ved at overvåge fejl i krypteret SMTP
Rapporter: failures i TLS leveringer fra andre mailservere

Eksempel:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

---

🏷️ 8. BIMI + VMC (Brand Indicators for Message Identification)

Beskytter mod: phishing via visuel brandforfalskning

Kræver:

• DMARC enforcement (p=quarantine/reject)
• Valid logo (SVG)
• Ofte VMC‑certifikat (betalt)

Eksempel:

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

---

🪪 9. CAA (Certification Authority Authorization)

Beskytter mod: uautoriseret udstedelse af TLS‑certifikater

Eksempel:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"

---

🔁 10. ARC (Authenticated Received Chain)

Ikke DNS, men relateret – vigtigt for forwarding

Beskytter mod:

• DMARC failures ved videresendelse
• Mailing‑lists / helpdesk / autosvar‑systemer

---

❌ 11. DNSBL / RBL (indgående spam‑beskyttelse)

DNS‑baseret bag‑sceningsteknologi til:

• spamfiltrering
• IP reputation
• beskyttelse af modtagende mailserver

Ikke en DNS‑record, men baseret på DNS‑lookups.

---

Sådan opsætter du Inbound SMTP DANE og DNSSEC i Microsoft 365 (inkl. test-links)

 📞 Mobil: +45 2278 2720
📧 E-mail: kc@todo-it.dk
🌐 Website: www.todo-it.dk