hyunjinlee9 님의 블로그

[교육 10일차] Exchange Online 트러블슈팅 기술 블로그

hyunjinlee9 — Fri, 22 May 2026 15:55:41 +0900

Microsoft 365 · Exchange Online

증거 기반(Evidence-Based) Exchange Online 트러블슈팅 워크플로우

"무엇이 고장났는가"를 넘어 "왜 그런가"를 증명하는 진단 — 스코핑부터 트레이스 분석, 에스컬레이션까지

Exchange Online Support Engineering · 실무 가이드

Exchange Online 케이스의 난도는 "증상을 재현할 수 있느냐"에서 갈립니다. 사용자 환경에서만 발생하고 우리 테넌트에서는 멀쩡한 이슈일수록, 추측이 아니라 아티팩트(artifact)로 원인을 좁히는 역량이 결정적입니다. 이 글에서는 한 건의 서비스 요청(SR)을 받았을 때 따라가는 진단 흐름을 단계별로 정리합니다.

1. 시작은 항상 '스코핑'

도구를 꺼내기 전에 문제의 경계를 먼저 정의해야 합니다. 잘못 스코핑된 케이스는 아무리 좋은 트레이스를 떠도 엉뚱한 곳을 봅니다.

영향 범위: 단일 사용자인가, 전체 사용자인가? 전체 사용자가 영향을 받는다면 사서함이 아니라 도메인·DNS 레코드(MX, Autodiscover, SPF/DKIM 등)를 먼저 의심합니다.
클라이언트 격리: Outlook on the web(OWA)나 새 Outlook에서는 정상인데 클래식 Outlook에서만 문제라면 — 서버 측이 아니라 클라이언트 동기화 이슈일 가능성이 높습니다.
한 SR = 한 이슈: 케이스 정보를 충분히 검토한 뒤, 고객과 "이번에 해결할 단 하나의 문제"를 합의하고 지원 경계를 명확히 합니다.

2. 재현이 안 되면, 증거를 수집한다

엔지니어가 오류를 직접 관찰할 수 없을 때, 다음 세 가지 증거가 진단의 출발점이 됩니다.

화면 녹화

증상이 시각적이거나 재현 절차가 모호할 때 가장 빠른 수단입니다. Windows에서는 Snipping Tool(녹화 기능)·Steps Recorder, Mac에서는 PowerPoint 녹화나 macOS 기본 녹화 도구를 안내합니다.

네트워크 트레이스 (HAR)

브라우저 기반 이슈(OWA, 관리 포털)는 개발자 도구의 Network 탭에서 HAR 파일을 캡처합니다. 핵심은 "문제를 재현하면서" 캡처하는 것 — 빈 트레이스만큼 무의미한 게 없습니다.

데스크톱 트레이스 (Fiddler)

권한이 정상으로 보이는데도 오류가 나는 클래식 Outlook이나 Exchange Online PowerShell 이슈는 Fiddler로 잡습니다. HTTPS 트래픽을 보려면 HTTPS 복호화(decrypt)를 반드시 활성화해야 하며, 재현 후 세션을 .saz 파일로 저장해 공유합니다. 외부에서 받은 HAR 파일도 Fiddler로 import해 동일하게 분석할 수 있습니다.

Tip. 트레이스를 받기 전에 "정확히 몇 시 몇 분에 오류가 떴는지" 타임스탬프를 함께 요청하세요. 수백 개의 세션 중 문제 구간을 찾는 시간을 극적으로 줄여줍니다.

3. 트레이스 읽기 — HTTP 응답 코드로 원인 좁히기

Fiddler/HAR 트레이스의 핵심은 결국 HTTP 응답 코드입니다. 코드 하나로 "내 영역인지, 에스컬레이션할 영역인지"의 1차 판단이 섭니다.

코드	의미	전형적 원인 / 다음 액션
401	Unauthorized (인증 실패)	토큰·자격 증명·인증 흐름 문제. 인증 헤더와 redirect 흐름 확인
403	Forbidden (권한 거부)	인증은 됐으나 권한 부족. EAC 권한 진단으로 교차 확인
404	Not Found	잘못된 엔드포인트·리소스 미존재. URL·Autodiscover 경로 점검
407	Proxy Auth Required	고객 측 프록시/네트워크 구성 이슈. 환경 문제로 분리
5XX	Server Error	서비스 측 오류 가능성. 재현·범위 확인 후 제품 엔지니어링 에스컬레이션 검토

예를 들어 권한이 "정상으로 보이는데" 접근이 막힌다면, 트레이스의 403을 근거로 EAC 권한 진단을 돌리고, 정상 사용자와 권한을 비교(diff)해 차이를 특정합니다.

4. 진단 도구 박스

증상별로 손에 익혀두면 좋은 도구들입니다. 상당수가 "자동으로 고치거나, 최소한 다음 단서를 주는" 셀프 헬프 성격을 가집니다.

사서함·권한 (Exchange admin center)

권한 진단: 특정 사용자가 올바른 권한을 갖는지 확인하고, 두 사용자 권한을 비교해 불일치를 찾음
사서함 프로비저닝 진단: 라이선스를 할당했는데 사서함이 생성되지 않을 때, 이메일·UPN·object ID로 진단 실행
셀프 헬프 진단: 일부 이슈를 자동 완화하거나 "잠시 후 재시도" 안내를 제공

️ 클라이언트 (클래식 Outlook)

MFCMapi: 누락된 기본 폴더 복원·숨김 해제 등 MAPI 레벨 데이터 이슈 처리
Get Help 앱: 기존 SaRA(Support and Recovery Assistant)를 잇는 도구로, Outlook 프로필 스캔·고급 진단 리포트 생성
Event Viewer: Outlook·Office 앱의 크래시·무응답 원인 분석

인증·로그 수집

MSOID 로그: 인증·Office 앱 이슈와 관련된 여러 로그를 한 번에 수집
ETL 로그: 클래식 Outlook의 상세 진단 로그. 이슈 발생 시점의 정확한 타임스탬프 캡처가 분석 품질을 좌우 (수집된 ETL은 내부 분석 도구로 해석)

5. 에스컬레이션 — 아티팩트와 함께

모든 케이스가 1선에서 끝나지는 않습니다. 에스컬레이션의 품질은 결국 "얼마나 잘 정리된 증거를 넘기느냐"입니다.

문제 재현 + 정확한 타임스탬프 확보
Fiddler 세션을 .saz로 저장, ETL·MSOID 등 관련 로그 일괄 수집
HTTP 코드 기준 1차 원인 판단 — 5XX 등 서비스 측 정황이면 에스컬레이션 후보
지정된 내부 업로드 경로로 로그를 공유하고, 재현 절차·범위·이미 시도한 조치를 함께 전달

⚠️ 주의. 트레이스 없이 넘기는 에스컬레이션은 반드시 되돌아옵니다. "권한은 맞는데 안 돼요"는 케이스가 아니라 가설입니다 — 403 트레이스와 권한 diff가 붙어야 케이스가 됩니다.

마무리: 진단은 추측이 아니라 증명

좋은 Exchange Online 엔지니어와 그렇지 않은 엔지니어의 차이는 도구를 아느냐가 아닙니다. 스코핑으로 문제를 한 점으로 좁히고, 트레이스와 로그로 원인을 증명하며, 올바른 아티팩트를 갖춘 채로만 에스컬레이션하는 절제된 흐름을 가졌느냐입니다.

다음 케이스를 받으면 도구부터 열지 말고, 딱 한 줄을 먼저 물어보세요 — "이게 한 명의 문제인가요, 모두의 문제인가요?" 진단의 절반은 거기서 끝납니다.

test

hyunjinlee9 — Fri, 22 May 2026 09:30:15 +0900

test

[교육 8일차] Microsoft Purview Information Protection, eDiscovery and Audit Solutions

hyunjinlee9 — Wed, 20 May 2026 16:37:08 +0900

Training Session Review

MICROSOFT
PURVIEW

Information Protection · DLP · Audit · eDiscovery

DAY 08

PRODUCT M365 / Exchange Online

ROLE Support Engineer Trainee

PORTAL purview.microsoft.com

Overview Sensitivity Labels Encryption DLP Audit eDiscovery Q&A 복습 Support Scenarios

Section 01

️Microsoft Purview 전체 구조

Microsoft Purview는 데이터 보호부터 법적 조사까지 하나의 플랫폼에서 처리하는 통합 컴플라이언스 솔루션입니다. 4단계 흐름으로 이해하면 쉽습니다.

STEP 01

️

Information Protection

데이터 기반 보호 설정

STEP 02

️

Sensitivity Labels

분류 + 암호화 적용

STEP 03

DLP

유출 방지 / 자동 차단

STEP 04

Audit & eDiscovery

추적 + 법적 조사

핵심 흐름 / Core Flow

보호(Protect) → 통제(Control) → 모니터링(Monitor) → 조사(Investigate)
각 단계는 독립적이 아니라 서로 연계되어 동작합니다. Each stage is interconnected — protection decisions feed into DLP signals, which create audit logs, which feed eDiscovery.

DISCOVER

데이터 식별

조직 내 민감 데이터가 어디에 있는지 파악. Cloud, Apps, Devices 전체 범위.

CLASSIFY

데이터 분류

민감도 레이블로 데이터를 분류. 자동 분류 또는 사용자 수동 적용.

PROTECT

데이터 보호

암호화, 공유 제한, 워터마크로 데이터 위치와 무관하게 지속 보호.

GOVERN

⚖️

데이터 관리

보존 정책, 삭제 정책, 레코드 관리로 전체 데이터 수명 주기 관리.

Section 02

️Sensitivity Labels — 보안 정책의 집합

"레이블 하나 = 보안 정책 묶음"이라는 개념이 핵심입니다. 레이블을 적용하는 순간 그 안에 포함된 모든 보호 정책이 동시에 적용됩니다.

암호화 (Encryption)

접근 권한을 설정하여 허가된 사용자만 열람 가능. 데이터 이동 후에도 유지.

콘텐츠 마킹

헤더, 푸터, 워터마크 자동 삽입. 문서 분류 등급 시각적 표시.

자동 레이블링

콘텐츠 기반 자동 분류 또는 레이블 추천. 사용자 실수 방지.

공유 제한

외부 공유, Teams 채널, SharePoint 사이트 수준 접근 제어.

⚠️ Sensitivity Label vs Retention Label 혼동 주의

Sensitivity Label = 데이터 보호/분류 (암호화, 공유 제한) — Purview Information Protection
Retention Label = 데이터 수명 주기 관리 (보존 기간, 삭제) — Purview Data Lifecycle Management
These are entirely different features. Don't confuse them in customer support cases.

적용 대상 / Where Labels Apply

Exchange (Email) Word / Excel / PPT Teams 채팅/채널 ️ SharePoint Sites ☁️ OneDrive M365 Groups

Section 03

Message Encryption — 이메일 단위 보호

Exchange Online에서 이메일 내용을 수신자만 확인 가능하도록 보호합니다. 외부 수신자(Gmail, Yahoo 등)도 OTP 또는 Microsoft 계정으로 인증 후 열람 가능합니다.

옵션 / Option	Encrypt-Only	Do Not Forward
암호화	✅ 적용	✅ 적용
전달 (Forward)	✅ 가능	❌ 차단
인쇄 (Print)	✅ 가능	❌ 차단
복사 (Copy)	✅ 가능	❌ 차단
외부 수신자	OTP 인증으로 열람	OTP 인증으로 열람
사용 시나리오	민감 내용이지만 수신자가 공유 가능해야 함	절대 외부 공유 금지 문서

Mail Flow Rule로 자동 암호화 적용

EAC → Mail flow → Rules → + Add a rule
조건: 특정 키워드 포함 / 특정 발신자 또는 부서 / 특정 도메인으로 발송 등
동작: Apply Microsoft 365 Message Encryption 선택 후 Encrypt-Only 또는 Do Not Forward 지정
Auto-apply encryption via mail flow rules based on conditions like keywords, senders, or recipient domains.

Section 04

DLP — 데이터 유출 방지

DLP(Data Loss Prevention)는 사용자의 실수로 인한 민감 데이터 유출을 자동으로 탐지하고 차단합니다. 지원 엔지니어 입장에서 "메일 전송 안됨" 케이스의 주요 원인 중 하나입니다.

Exchange (메일)

이메일 본문/첨부파일에서 민감 정보 탐지. 전송 차단 또는 Policy Tip 표시.

Endpoint / Devices

디바이스의 파일 복사, USB 전송, 클라우드 업로드 제한. MDE 에이전트 필요.

Web Traffic

브라우저 기반 데이터 업로드 제어. Chrome 확장 프로그램과 연동.

Teams / SharePoint

메시지, 파일 공유 시 민감 정보 포함 여부 탐지 및 경고.

보호 대상 민감 정보 유형

신용카드 번호 개인식별정보 (PII) 의료 정보 (PHI) 비밀번호 / 인증 정보 기업 기밀 여권 / 주민번호

⚠️ Support 엔지니어 주의 — DLP vs Mail Flow Rule 구분

고객: "메일이 안 보내져요" → DLP인지 Mail Flow Rule인지 먼저 구분해야 합니다.

DLP 차단: Outlook에 Policy Tip 메시지가 표시됨
Mail Flow Rule 차단: NDR(배달 실패 알림, Non-Delivery Report) 발생

확인 경로: Purview → DLP → Activity Explorer 또는 Alerts 탭

Section 05

Audit — 행위 추적 로그

Audit는 사용자와 관리자의 활동을 기록하는 로그 시스템입니다. "누가 무엇을 했나?"에 답하는 도구입니다.

항목	Standard Audit	Premium Audit
보존 기간	180일	최대 10년 (E5 라이선스)
로그 범위	기본 활동	고급 활동 포함 (MailItemsAccessed 등)
대역폭	표준	더 높은 API 대역폭
라이선스	기본 포함	M365 E5 또는 Compliance E5 추가

⚠️ 주의 — 기록되지 않는 활동

Move, Copy 등 일부 작업은 Standard Audit에서 기본적으로 기록되지 않을 수 있습니다.
민감한 보안 사고 조사 시 Premium Audit (Advanced Audit) 활성화를 확인하세요.
Some actions (Move, Copy) may not be logged by default — check if Advanced Audit is enabled for sensitive investigations.

대표 활용 시나리오

"메일이 사라졌어요" — Audit에서 SoftDelete 또는 HardDelete 이벤트 검색
Search for SoftDelete/HardDelete events in Audit
"누가 내 메일함에 접근했나요?" — MailItemsAccessed 이벤트 (Premium 필요)
MailItemsAccessed event (Premium Audit required)
"관리자가 설정을 변경했나요?" — Admin activity 로그 확인
Check Admin activity logs for configuration changes
"파일이 누구에게 공유됐나요?" — SharePoint/OneDrive 공유 이벤트 검색
Search sharing events in SharePoint/OneDrive

Section 06

eDiscovery — 실제 콘텐츠 조사

eDiscovery는 전자 데이터(ESI)를 검색, 수집, 분석, 내보내기하는 도구입니다. "어떤 데이터가 존재하나?"에 답합니다.

Standard eDiscovery

케이스 기반 콘텐츠 검색
Hold 적용 가능
결과 내보내기 (PST/개별 파일)
Exchange, Teams, SharePoint, OneDrive
E3 라이선스 포함

Premium eDiscovery

Advanced indexing (OCR 포함)
Custodian 관리
Review sets (태깅, 주석)
Near-duplicate 분석
E5 또는 eDiscovery Add-on 필요

✅ Audit vs eDiscovery 핵심 구분

항목	Audit	eDiscovery
목적	활동 로그 추적	실제 데이터 조사
대상	행위 로그	실제 콘텐츠
질문	누가 무엇을 했나?	어떤 데이터가 있나?

Section 07

❓Q&A 핵심 복습

Purview 4단계 흐름을 한 줄로 설명하면?

Describe the 4-stage Purview flow in one sentence.

Information Protection: 데이터를 식별(Discover) → 분류(Classify) → 보호(Protect) → 관리(Govern)하는 기반 프레임워크
Foundation framework: Discover → Classify → Protect → Govern data
Sensitivity Labels: 분류된 데이터에 암호화·워터마크·공유 제한 등 보안 정책 적용
Apply encryption, watermarks, and sharing restrictions to classified data
DLP: 정책 기반으로 민감 데이터 유출 자동 탐지 및 차단/경고
Auto-detect and block/warn on sensitive data leakage based on policies
Audit & eDiscovery: 활동 로그 추적 및 법적·보안 목적의 콘텐츠 조사
Track activity logs and investigate content for legal or security purposes

Encrypt-Only와 Do Not Forward의 핵심 차이는?

Key difference between Encrypt-Only and Do Not Forward?

Encrypt-Only: 암호화만 적용. 수신자는 전달, 인쇄, 복사 가능.
Encryption only — recipient can forward, print, and copy.
Do Not Forward: 암호화 + 전달/인쇄/복사 모두 차단.
Encryption + blocks forwarding, printing, and copying.
두 옵션 모두 외부 수신자(Gmail 등)는 OTP 또는 Microsoft 계정으로 인증 후 열람 가능.
Both allow external recipients (Gmail, etc.) to view via OTP or Microsoft account authentication.

DLP로 메일이 차단됐을 때 Support 엔지니어로서 첫 번째 확인 단계는?

First step when a customer reports email blocked by DLP?

1단계: DLP 차단인지 Mail Flow Rule 차단인지 구분 (Policy Tip → DLP / NDR → Mail Flow Rule)
Distinguish: Policy Tip in Outlook = DLP block | NDR email = Mail Flow Rule block
2단계: Purview → DLP → Activity Explorer에서 정책 이름, 트리거 규칙, 사용자, 시간 확인
Check Activity Explorer for policy name, triggered rule, user, and timestamp
3단계: 필요 시 정책 예외(Exception) 추가 또는 고객에게 Policy Tip 메시지 내용 설명
Add policy exception if needed or explain Policy Tip message to customer

Audit 로그에서 삭제된 메일을 조사하는 경로는?

How to investigate deleted emails via Audit?

경로: Purview → Solutions → Audit → Search 탭
Navigate: Purview → Solutions → Audit → Search tab
필터: Activities에서 Deleted messages 또는 Purged messages 선택, 날짜/사용자/사서함 지정
Filter Activities: select Deleted/Purged messages → specify date, user, mailbox
결과: 수행자, 시간, IP 주소, 사서함 확인 → CSV로 내보내기 가능
Results show actor, time, IP, mailbox — can export as CSV

법무팀에서 특정 직원의 모든 메일 제출을 요청받았다. 어떻게 처리하나?

Legal team requests all emails from a specific user. How to handle?

도구: Audit(행위 로그)이 아닌 eDiscovery(실제 콘텐츠) 사용
Use eDiscovery (content), not Audit (logs)
Purview → eDiscovery → Standard → + Create a case → 케이스 생성
Create a case in Purview eDiscovery Standard
케이스 내 Searches → 조건 설정 (사용자, 기간, 키워드) → 검색 실행 → Export(PST 또는 개별 파일)
Add search with conditions → run → export as PST or individual files
eDiscovery Manager 역할 필요 (일반 관리자는 접근 불가)
Requires eDiscovery Manager role — general admins cannot access

Section 08

오늘 이후 처리 가능한 지원 시나리오

Customer Problem

이메일에 신용카드 번호 포함했더니 전송이 안 됨

Email blocked after including credit card number in body

✅ Support Action

DLP 정책 트리거 확인 → Activity Explorer에서 정책 이름 확인 → 고객 안내

Check DLP Activity Explorer for triggered policy name and rule details

Customer Problem

암호화된 메일을 외부 수신자가 못 열겠다고 함

External recipient can't open encrypted email

✅ Support Action

OTP 인증 또는 Microsoft 계정으로 열람 방법 안내. Do Not Forward 여부 확인

Guide recipient to use OTP or MS account. Check if Do Not Forward is applied

Customer Problem

"내 메일이 갑자기 사라졌어요. 누가 삭제했나요?"

Emails missing — who deleted them?

✅ Support Action

Purview Audit → SoftDelete/HardDelete 이벤트 검색으로 행위자 특정

Search Audit for SoftDelete/HardDelete events to identify the actor

Customer Problem

Sensitivity Label 붙인 문서를 외부 공유했더니 상대방이 못 열어요

External party can't open a labeled document

✅ Support Action

레이블 암호화 설정 확인 (외부 사용자 허용 여부). 필요 시 레이블 정책 수정

Check label encryption settings for external access. Modify label policy if needed

Customer Problem

법무팀에서 퇴직한 직원의 메일 전체 제출 요청

Legal team requests all emails from a former employee

✅ Support Action

eDiscovery 케이스 생성 → Content Search → PST 내보내기. Inactive Mailbox 확인

Create eDiscovery case → Content Search → export PST. Check for inactive mailbox

[교육 7일차]Exchange Online Retention, In-place archiving and Inactive Mailboxes

hyunjinlee9 — Tue, 19 May 2026 16:10:02 +0900

Exchange Online 데이터 거버넌스 & 정보 보호 | M365 Tech Blog

M365 Tech Support Engineer | Exchange Online | Data Governance & Information Protection

Exchange Online
데이터 거버넌스 &
정보 보호 완전 정복

Exchange Online Microsoft Purview Retention & Hold Archive Mailbox Journaling

Exchange Online 기본 개념 복습
사서함 유형 & 관리
복구 가능 항목 폴더
사서함 보존 (Hold)
보존 정책 & 레이블
보관 사서함
레거시 보존 태그 & MRM
저널링
오늘의 실습 체크리스트

Section 01

Exchange Online 기본 개념 복습

Exchange Online은 Microsoft가 호스팅하는 클라우드 기반 이메일 및 캘린더 서비스로, Microsoft Entra ID와 통합되어 인증 및 접근 관리를 수행합니다.

핵심 관리 도구

️

PRIMARY

Exchange 관리 센터 (EAC)

메일 흐름, 마이그레이션, Exchange 특정 설정 관리에 주로 사용

⚡

ALT

Exchange Online PowerShell

EAC의 대안으로 CLI 기반 관리. 자동화 및 대량 작업에 유리

GRAPH

Microsoft Graph PowerShell

사용자/그룹 관리 시 User.ReadWrite.All 등 적절한 권한 스코프 지정 필요

️

RBAC

역할 기반 액세스 제어

역할 그룹(기본/사용자 지정)으로 권한 관리. EAC 접근에는 Exchange 관리자 역할 필요

Exchange Online DNS 레코드

레코드	역할	비고
`MX`	도메인으로 메일 배달 위치 지정	가장 중요, 반드시 설정
`SPF`	발신 서버 인증 (스푸핑 방지)	TXT 레코드로 게시
`DKIM`	메일 서명으로 위변조 탐지	공개키 기반 서명
`DMARC`	SPF/DKIM 실패 시 처리 정책	리포트 수신도 가능
`Autodiscover`	Outlook 자동 구성	클라이언트 연결 필수

핵심 포인트

기본 onmicrosoft.com 도메인은 사용자 지정 도메인이 제거될 경우의 대체 ID 및 이메일 라우팅 도메인으로 사용됩니다. Microsoft 365 가입 시 자동 할당됩니다.

Section 02

사서함 유형 & 라이선스

사용자 사서함

라이선스 필요. 기본 50GB, Plan 2는 100GB. 라이선스 제거 후 30일 뒤 데이터 영구 삭제

리소스 사서함

라이선스 불필요. 기본 50GB 제한. 회의실, 장비 등 예약 관리용

공유 사서함

여러 사용자가 공유. 50GB 이하 시 라이선스 불필요

️

비활성 사서함

Hold/보존 정책 적용 후 삭제 시 생성. 퇴직자 데이터 보존 목적. 복구 또는 다른 사용자로 복원 가능

⚠️ 중요

Exchange Online 라이선스 제거 시, 보존 정책이나 Hold가 없다면 30일 후 사서함 데이터가 영구 삭제됩니다. 데이터 보존이 필요한 경우 미리 Litigation Hold 또는 보존 정책을 적용하세요.

사서함 권한 (Delegation)

권한	설명
Send As	대리인이 사서함 소유자 명의로 직접 발송하는 것처럼 보임
Send on Behalf	"A가 B를 대신하여" 형식으로 발송
Full Access	사서함 전체 접근 (읽기/쓰기)

Section 03

복구 가능 항목 폴더 (Recoverable Items)

복구 가능 항목 폴더는 사용자에게 보이지 않는 특수 폴더로(Outlook에서 삭제된 항목 하위 폴더 제외), 삭제/수정된 항목, 감사 로그 등을 보존하는 핵심 구조입니다.

삭제 단계 이해

1단계

Delete

삭제된 항목 폴더

→

2단계

Soft Delete

Deletions 하위폴더

→

3단계

Hard Delete

Purge 하위폴더

→

최종

영구 삭제

복구 불가

️ 하위 폴더 구조

하위 폴더	저장 내용
Deletions	Soft Delete된 항목 (사용자가 Shift+Delete하거나 휴지통에서 삭제)
Versions	수정된 항목의 이전 버전 (Single Item Recovery용)
Purge	Litigation Hold / Single Item Recovery 기간 만료 후 영구 삭제 대기 항목
Audit	사용자/관리자의 사서함 활동 감사 로그
DiscoveryHold	eDiscovery 검색 쿼리로 보존 중인 항목

용량 참고

기본 복구 가능 항목 할당량: 30 GB
Litigation Hold 활성화 시 자동으로 110 GB로 증가

이 폴더를 활용하는 기능들: 단일 항목 복구 사서함 보존 보존 정책 보존 레이블 사서함 감사

Section 04

사서함 보존 Hold 유형

⚖️

PURVIEW

Litigation Hold (소송 보존)

사용자의 모든 사서함 데이터를 기간 지정 또는 무기한 보존. PowerShell 또는 M365 관리 센터로 설정

PURVIEW

eDiscovery Hold

eDiscovery 케이스에서 검색된 항목을 지정 기간 보존. 소송/조사 목적

AUTO

Delay Hold (지연 보존)

다른 Hold 제거 시 30일간 자동 적용. 영구 삭제 전 데이터 보호

⏸️

TEMP

Retention Hold (보존 일시정지)

보존 정책을 일시적으로 중단. 예: 직원 휴가 중 받은 메일이 바로 삭제되지 않도록

PowerShell: Litigation Hold 설정

PowerShell
# Litigation Hold 활성화
Set-Mailbox-Identity"user@contoso.com"-LitigationHoldEnabled$true

# 기간 지정 (일 단위)
Set-Mailbox-Identity"user@contoso.com"-LitigationHoldEnabled$true-LitigationHoldDuration365

# 사서함의 Hold 상태 확인
Get-Mailbox-Identity"user@contoso.com"|FLLitigationHold*

PowerShell: Hold 상태 종합 확인

PowerShell
# 보존 관련 전체 속성 확인
Get-Mailbox-Identity"user@contoso.com"|
FLLitigationHoldEnabled, InPlaceHolds, RetentionHoldEnabled, DelayHoldApplied

# 조직 전체 보존 정책 확인
Get-OrganizationConfig|FLInPlaceHolds

InPlaceHolds 접두사 해독

접두사	의미
`mbx`	Exchange 사서함에 적용되는 보존 정책
`grp`	Microsoft 365 그룹 및 Teams 채널 메시지
`skp`	Skype for Business
숫자 접미사 `:1`	삭제 정책
숫자 접미사 `:2`	보존 정책
숫자 접미사 `:3`	보존 후 삭제 정책

Section 05

보존 정책 & 보존 레이블 (Microsoft Purview)

Microsoft는 레거시 기능 대신 Microsoft Purview의 보존 정책 및 보존 레이블 사용을 권장합니다.

⚖️ 보존 정책 vs 보존 레이블

구분	보존 정책	보존 레이블
적용 범위	조직 전체 또는 특정 위치(사서함, SharePoint 등)	개별 폴더 또는 항목
적용 방법	자동 적용 (관리자)	관리자 자동 또는 사용자가 직접 적용 (Outlook)
우선순위	삭제 정책보다 보존 정책 우선 여러 정책 → 가장 긴 보존 기간 적용	레이블이 정책보다 우선 적용
대상	Exchange, SharePoint, OneDrive, M365 Groups	Exchange 사서함 내 폴더/항목
적용 시간	최대 7일 소요	즉시 적용

보존 정책 설정 범위 유형

적응형 범위 (Adaptive)

Entra ID 속성 기반 동적 사용자/사이트 그룹. 라이선스 요구 있음

정적 범위 (Static)

명시적으로 위치 지정. 조직 전체 또는 특정 사서함 선택

PowerShell: 보존 정책 확인

PowerShell (Compliance)
# 모든 보존 정책 목록
Get-RetentionCompliancePolicy

# 특정 사서함에 적용된 보존 정책 확인
Get-Mailbox-Identity"user@contoso.com"|
FLComplianceTagHoldApplied, InPlaceHolds

# Managed Folder Assistant 즉시 실행 (정책 즉시 적용)
Start-ManagedFolderAssistant-Identity"user@contoso.com"

️ Purview Policy Lookup 활용

Microsoft Purview 포털의 데이터 수명 주기 관리 > 정책 조회 기능을 사용하면 특정 사용자 사서함에 어떤 보존 정책이 적용되어 있는지 빠르게 확인하고, 특정 사서함을 정책에서 제외할 수 있습니다.

️ 보존 레이블 게시 프로세스

Purview 포털에서 보존 레이블 생성 (보존 기간, 동작, 이벤트 기반 트리거 설정)
레이블 정책에 게시 (레이블 정책 = 어떤 사용자/위치에 레이블을 노출할지 지정)
사용자가 Outlook / OWA에서 직접 레이블 적용 (폴더 또는 항목 단위)

Section 06

보관 사서함 (Archive Mailbox)

️ 보관 사서함 스펙 비교

기능	기본	자동 확장 아카이브
추가 스토리지	+100 GB	최대 1.5 TB
활성화 방법	EAC / PowerShell	PowerShell만 가능
필요 라이선스	Exchange Online Plan 2 또는 Exchange Online Archiving 추가 기능	동일
Outlook 표시 이름	클래식: "Online Archive - user@..." / OWA: "Anyplace Archive"	동일

PowerShell: 보관 사서함 관리

PowerShell
# 단일 사용자 보관 사서함 활성화
Enable-Mailbox-Identity"user@contoso.com"-Archive

# 조직 전체 자동 활성화 (Plan 2 라이선스 필요)
Set-OrganizationConfig-AutoExpandingArchive

# 자동 확장 아카이브 활성화 (개별 사용자)
Enable-Mailbox-Identity"user@contoso.com"-AutoExpandingArchive

# 보관 사서함 상태 확인
Get-Mailbox-Identity"user@contoso.com"|FLArchive*

기본 보관 정책 (MRM 기본 태그)

기본 동작

기본 MRM 보존 정책에 포함된 기본 정책 태그(DPT): 2년 이상 된 항목을 자동으로 보관 사서함으로 이동

사용자는 Outlook에서 개인 태그를 직접 폴더/항목에 적용 가능하며, 사용자 지정 태그가 관리자 전역 정책보다 우선합니다.

⚡ 신규: 자동 보관 기능

기본 사서함이 할당량의 90%에 도달하면, 보관 사서함이 프로비저닝된 경우 항목이 자동으로 이동됩니다.

Section 07

레거시 보존 태그 & MRM (Messaging Records Management)

⚠️ 레거시 기능

MRM 보존 태그는 레거시 기능입니다. Microsoft는 Purview 보존 정책 및 레이블 사용을 권장합니다. 단, 보관 사서함으로 항목을 이동(Move to Archive)하는 동작은 여전히 MRM 태그를 통해서만 가능합니다.

️ 보존 태그 유형

태그 유형	적용 대상	Move to Archive 가능
DPT (기본 정책 태그)	사서함 전체 (태그 없는 항목)	✅
RPT (보존 정책 태그)	받은 편지함, 보낸 편지함 등 기본 폴더	❌
개인 태그 (Personal Tag)	사용자가 지정하는 폴더/항목	✅

보존 태그 생성 후 보존 정책에 추가 → 사서함에 정책 할당 순서로 게시합니다.

Section 08

저널링 (Journaling)

⚠️ 레거시 기능

저널링은 Exchange 레거시 기능으로 Microsoft가 권장하지 않습니다. 최신 보존 기능으로 대체하는 것을 권장하지만, 일부 규정 준수 요구 시 여전히 사용됩니다.

저널링은 지정된 사서함으로 이메일 사본을 외부 사서함에 전달하는 기능입니다. 트랜스포트 규칙과 유사하게 동작합니다.

⚙️ 저널링 설정 순서

저널 보고서 수신 사서함 설정 — 저널 규칙 생성 전에 반드시 먼저 구성
Purview 포털에서 저널 규칙 생성 — 대상 사서함, 범위, 메시지 유형 정의
메시지 추적(Message Trace)으로 검증 — 저널 규칙 트리거 여부 확인

저널 보고서 형태

저널 규칙이 트리거되면, 원본 메시지가 첨부 파일로 포함된 저널 보고서가 지정된 사서함으로 전송됩니다. 메시지 추적 결과에서 발신자, 수신자, 저널 규칙 정보를 확인할 수 있습니다.

[교육 6일차] Exchange Online

hyunjinlee9 — Mon, 18 May 2026 14:32:13 +0900

M365 Support Engineer · D6 Study Notes

Exchange Online
클라이언트 연결 완전 정복

Autodiscover의 DNS 탐색 순서부터 SMTP 지연 3가지 방식, Outlook 문제 진단 트리까지 — 지원 엔지니어가 꼭 알아야 할 모든 것을 한 페이지에 정리했습니다.

D6 세션 ⏱ 읽는 데 약 15분 교육 노트 v2

// 01

Autodiscover — 연결의 시작

고객이 새 PC에서 Outlook을 열고 이메일 주소만 입력했더니 알아서 설정이 완료됐다며 신기해하는 경험, 지원 엔지니어로서 자주 접하게 됩니다. 그리고 반대로 이게 안 될 때 가장 많이 울리는 티켓도 바로 Autodiscover 문제입니다.

Autodiscover는 사용자의 이메일 주소를 기반으로 DNS를 탐색하고, Exchange Online 서버로부터 XML 구성 파일을 받아와 연결 정보를 자동으로 설정합니다.

Autodiscover DNS 탐색 순서 (클래식 Outlook)

SCP (Service Connection Point) 조회

Active Directory에 도메인 가입된 PC는 AD에서 SCP 레코드를 먼저 조회합니다. 회사 내부 환경에서 주로 동작합니다.

HTTPS — autodiscover.도메인.com

SCP가 없으면 https://autodiscover.contoso.com/autodiscover/autodiscover.xml에 연결을 시도합니다.

HTTPS — 이메일 도메인 루트 시도

https://contoso.com/autodiscover/autodiscover.xml을 시도합니다.

DNS CNAME 리다이렉트

autodiscover.contoso.com의 CNAME이 autodiscover.outlook.com을 가리키면 Microsoft 서버로 연결됩니다. Exchange Online의 핵심 경로입니다.

인증 → XML 수신 → 연결 완료

Modern Auth(MFA 포함) 인증 후 XML을 받아 MAPI over HTTP로 Exchange Online에 연결됩니다.

실무 팁 — Autodiscover 오류 재현법: Microsoft Remote Connectivity Analyzer(aka.ms/exrca)에서 Outlook Autodiscover 테스트를 실행하면 어느 단계에서 실패했는지, XML 파일 내용이 무엇인지 바로 확인할 수 있습니다. 고객 오류 신고 시 가장 먼저 실행해야 할 도구입니다.

// 02

프로토콜 완전 비교

"어떤 이메일 클라이언트가 어떤 프로토콜을 쓰는가"는 연결 문제 진단의 출발점입니다. 특히 아래 원칙은 반드시 기억하세요.

핵심 원칙 — Exchange Online = MAPI Only (클래식 Outlook)
클래식 Outlook 데스크톱은 MAPI over HTTP만 지원합니다. MAPI를 비활성화하면 Outlook이 메일박스에 연결 자체가 불가능합니다. MFA(다단계 인증)를 포함한 Modern Authentication도 MAPI 프로토콜에서만 동작합니다. 이게 왜 중요하냐면 — 보안 정책으로 MAPI를 막으면 Outlook이 아예 열리지 않는 사태가 생기기 때문입니다.

프로토콜	용도	주요 클라이언트	MFA 지원	캘린더/연락처	상태
MAPI over HTTP	수신 · 전체	클래식 Outlook	✓ 지원	✓ 포함	주력
IMAP	수신	Thunderbird, Gmail앱 등	제한적	✗ 없음	서드파티
POP3	수신	레거시 앱	✗ 없음	✗ 없음	레거시
SMTP	발신 전용	모든 클라이언트	—	—	발신 필수
Exchange ActiveSync	모바일 동기화	Samsung Mail, iOS Mail	제한적	✓ 포함	모바일

IMAP vs POP3 — 언제 어떤 걸 써야 하나?

▲ IMAP — 권장

✓ 여러 기기에서 동일하게 보임
✓ 폴더 구조 서버에서 유지
✓ 삭제해도 서버에 이메일 남음
✗ 캘린더 / 연락처 동기화 없음
✗ 오프라인 사용 제한적

▲ POP3 — 레거시

✓ 로컬 저장 → 오프라인 OK
✗ 단일 기기, 동기화 없음
✗ 다운로드 후 서버에서 삭제
✗ 폴더 구조 없음
✗ 최신 Outlook은 POP3 미사용

POP3/IMAP은 Exchange Online에서 기본 비활성화입니다. 고객이 서드파티 클라이언트(Thunderbird 등)를 쓴다면 관리자가 해당 사용자에게 명시적으로 활성화해야 합니다.

⚙️ 서버 설정 정보

프로토콜	서버 주소	포트	암호화
IMAP	`outlook.office365.com`	993	SSL/TLS
POP3	`outlook.office365.com`	995	SSL/TLS
SMTP (발신)	`smtp.office365.com`	587	STARTTLS

// 03

SMTP 지연 3가지 방식 완전 정리

복합기, 프린터, 오래된 ERP 시스템처럼 "이메일을 보내야 하는 장치나 앱"을 Exchange Online에 연결할 때 딱 3가지 방식이 있습니다. 고객 티켓이 왔을 때 제일 먼저 할 일은 "어떤 방식을 쓰고 있는지" 확인하는 겁니다.

① Client SMTP Submission

엔드포인트smtp.office365.com

포트587 (또는 25)

인증계정 + 비밀번호

전송 범위내부 + 외부 ✓

메일박스필요

TLS1.2 이상 필수

② SMTP Relay

엔드포인트MX 레코드

포트25

인증인증서 (TLS)

전송 범위내부 + 외부 ✓

메일박스불필요

IP 등록Microsoft 365에 등록 필요

③ Direct Send

엔드포인트MX 레코드

포트25

인증없음

전송 범위내부만 ⚠️

메일박스불필요

외부 발송불가 (스팸 처리)

✅ Client SMTP Submission 트러블슈팅 체크리스트

// 오류 발생 시 확인 순서

✓

Authenticated SMTP가 사용자에 대해 활성화되어 있는가? (기본값: 비활성화)

✓

활성 메일박스 + 라이선스가 있는 계정을 사용하는가?

✓

TLS 1.2 이상을 지원하는 장치/앱인가?

✓

다른 주소로 발송 시 "Send As" 권한이 부여되어 있는가?

□

방화벽에서 포트 587 아웃바운드가 열려 있는가? (ISP가 차단하는 경우 많음)

□

MFA / 조건부 액세스 정책이 SMTP 인증 계정을 차단하고 있지 않은가?

Telnet으로 포트 확인하기

CMD / PowerShell

# 포트 587 열려 있는지 테스트 (Client SMTP Submission)
telnet smtp.office365.com 587

# MX 레코드 주소 확인 (SMTP Relay / Direct Send)
nslookup -type=MX contoso.com
# 또는 https://mxtoolbox.com 에서 확인

# SMTP 명령으로 테스트 이메일 발송
# (Telnet 접속 후)
EHLO test
AUTH LOGIN
# base64 인코딩된 사용자명/비밀번호 입력
MAIL FROM:<user@contoso.com>
RCPT TO:<recipient@contoso.com>
DATA
Subject: Test
.
QUIT

⚠️

포트 587이 차단되어 있으면 이메일이 아예 발송되지 않습니다. 특히 가정용 ISP는 포트 25/587을 기본 차단하는 경우가 많습니다. 테스트 메일이 Junk 또는 Quarantine으로 빠질 수도 있으니 받은 편지함만 확인하지 마세요.

// 04

Outlook 연결 오류 — 진단 트리

고객이 "Outlook이 안 된다"고 하면 막연하게 느껴질 수 있습니다. 하지만 아래 순서대로 질문하면 대부분의 원인을 10분 안에 좁혀낼 수 있습니다.

// 클래식 Outlook 연결 오류 진단 흐름

Outlook 연결 오류 발생 가장 먼저 — 클래식 Outlook인가, 새 Outlook인가? (아래 도구들은 클래식 전용)

❓

1. Autodiscover 문제인가? Remote Connectivity Analyzer → Outlook Autodiscover 테스트 실행, XML 확인

└

DNS CNAME 레코드가 autodiscover.outlook.com을 가리키는지 확인

❓

2. Modern Auth / MAPI 문제인가? 시스템 트레이 Outlook 아이콘 Ctrl+클릭 → 연결 상태 확인

└

"MAPI over HTTP" + "Bearer" 토큰이 보이면 정상. "Basic Auth"면 Modern Auth 비활성화 문제

❓

3. 비밀번호 반복 요청이 생기는가? Get Help 앱 → Outlook → 반복 비밀번호 요청 시나리오 선택

└

조건부 액세스 정책 또는 Credential Manager의 오래된 캐시 문제일 가능성 높음

❓

4. 프로필 문제인가? outlook.exe /resetnavpane 또는 새 프로필 생성 테스트

└

새 프로필에서 정상 동작하면 기존 프로필 손상이 원인

시스템 트레이 빠른 확인법: Ctrl 키를 누른 채로 Outlook 시스템 트레이 아이콘을 우클릭하면 "연결 상태(Connection Status)" 메뉴가 나타납니다. 여기서 프로토콜이 MAPI/HTTP이고 인증이 Bearer이면 정상 상태입니다.

// 05

문제 해결 도구 모음

아래 모든 도구는 클래식 Outlook(구 Outlook)에만 적용됩니다. 새 Outlook(New Outlook for Windows)에서는 사용 불가합니다.

Remote Connectivity Analyzer

aka.ms/exrca. Autodiscover, SMTP, ActiveSync 테스트. XML 다운로드로 오류 원인 파악.

웹 기반

Get Help (지원 도우미)

Windows의 "도움말 가져오기". 프로필·시작 오류·반복 비밀번호 자동 진단. Outlook이 먼저 실행되어야 함.

Windows 앱

Telnet 포트 테스트

SMTP 포트 개방 여부 즉시 확인. telnet smtp.office365.com 587

CLI

연결 상태 (트레이)

Ctrl+우클릭으로 MAPI/HTTP + Bearer 토큰 사용 여부 즉시 확인.

클래식 Outlook

NSLookup / MX Toolbox

MX 레코드, Autodiscover CNAME 확인. nslookup -type=MX contoso.com

DNS 확인

Outlook 프로필 진단 명령어 모음

# 새 프로필로 Outlook 실행 (프로필 선택 창)
outlook.exe /profiles

# 네비게이션 창 초기화 (자주 발생하는 UI 오류 해결)
outlook.exe /resetnavpane

# Safe Mode로 실행 (추가 기능 비활성화 — 충돌 테스트)
outlook.exe /safe

# Autodiscover 이메일 자동 구성 테스트 (클래식 Outlook)
# 파일 → 계정 설정 → 이메일 → 이메일 자동 구성 테스트

// 06

모바일 클라이언트 연결 방식

iOS/Android Outlook 앱

✓ Microsoft Sync 기술 + Autodiscover
✓ Modern Auth / MFA 완전 지원
✓ Intune 조건부 액세스 정책 적용 가능
✓ Microsoft가 권장하는 모바일 클라이언트

Samsung Mail / iOS 기본 Mail

✓ Exchange ActiveSync (EAS) 사용
✓ Remote Wipe (원격 초기화) 지원
✓ 비밀번호 정책 강제 적용 가능
✗ Modern Auth 지원 제한적

Remote Wipe란? 직원이 퇴사하거나 기기 분실 시, 관리자가 Exchange admin center에서 해당 기기의 회사 데이터를 원격으로 초기화할 수 있는 기능입니다. 오늘의 실습 과제 중 하나이니 꼭 직접 해보세요.

// 07

메일박스 정책 & 공유 메일박스

메일박스 정책

Exchange admin center에서 메일박스 정책으로 사용자 경험과 보안을 제어합니다. 정책 변경은 클래식 Outlook과 새 Outlook 모두에 동일하게 적용됩니다.

제어 항목	설명	위험도
Exchange ActiveSync	모바일 동기화 허용 여부	중간
받은 편지함 규칙	외부 자동 전달 허용 범위 — 데이터 유출 경로!	높음
연락처 추가	외부 연락처 추가 허용	낮음
삭제 항목 복구	복구 가능 기간 설정	낮음
비밀번호 변경	OWA에서 비밀번호 변경 허용	중간

공유 메일박스 Auto-mapping

Full Access 권한이 있는 공유 메일박스는 클래식 Outlook에서 자동 추가(Auto-mapping)됩니다. 편리하지만 공유 메일박스가 많으면 Outlook 시작이 느려지는 원인이 됩니다. PowerShell로 Auto-mapping을 끄고 수동으로 추가하면 성능이 개선됩니다.

PowerShell — Exchange Online

# Auto-mapping 비활성화 (권한 재부여 시 AutoMapping:$false 추가)
Add-MailboxPermission `
    -Identity "shared@contoso.com" `
    -User "user@contoso.com" `
    -AccessRights FullAccess `
    -AutoMapping $false

# 현재 Auto-mapping 상태 확인
Get-MailboxPermission -Identity "shared@contoso.com" | Select-Object User, AccessRights, IsInherited

# Auto-mapping 비활성화 후 → Outlook에서 수동으로 추가
# 파일 → 계정 설정 → 계정 설정 → 이메일 탭 → 변경 → 추가 설정 → 고급 → 다른 사서함 추가

// 08

오늘의 Action Items

교육에서 받은 실습 과제입니다. 손으로 직접 해봐야 진짜 실력이 됩니다.

Autodiscover XML 분석 — Remote Connectivity Analyzer에서 Autodiscover 테스트 실행, XML 파일 다운로드해서 서버 정보와 오류 코드 직접 읽어보기

POP/IMAP 클라이언트 실습 — Thunderbird 또는 Gmail/Outlook.com 계정으로 IMAP 구성. Autodiscover 자동 탐색 동작 확인 후 수동 설정과 비교

New vs Classic Outlook 비교 — 개인/회사 PC에서 두 버전에 POP/IMAP 계정 추가. 지원되는 기능과 안 되는 기능 차이 직접 체험

모바일 Remote Wipe 테스트 — 테스트 메일박스를 모바일에 설정 후 Exchange admin center에서 Remote Wipe 실행. 어떤 데이터가 삭제되는지 관찰

Telnet SMTP 전체 플로우 — telnet smtp.office365.com 587 접속 후 SMTP 명령으로 테스트 이메일 실제 발송. Junk/Quarantine 확인까지

마무리 한마디
Exchange Online 클라이언트 연결 문제는 결국 "어떤 프로토콜 → 어떤 인증 → 어떤 포트 → 어떤 정책"의 체인입니다. 오늘 배운 Autodiscover → MAPI → Modern Auth 흐름을 머릿속에 그릴 수 있다면, 고객 티켓의 80%는 이미 방향이 보입니다. 나머지 20%는 경험으로 채워집니다.

[교육 5일차] Exchange Online & Hybrid 완전 정복

hyunjinlee9 — Fri, 15 May 2026 15:54:47 +0900

조직 간 캘린더 공유부터 Hybrid Mail Flow, Mailbox Migration까지 실무 중심 정리

Microsoft 365 엔지니어라면 반드시 이해해야 하는 Exchange Online / Exchange Hybrid 핵심 개념과 실제 운영 포인트를 정리했습니다.
단순 기능 소개가 아니라, 실제 고객 환경에서 문제를 분석하고 설계·운영·마이그레이션까지 수행할 수 있는 수준으로 구성했습니다.

1. 왜 Exchange Hybrid를 이해해야 하는가?

최근 기업 환경은 아래 3가지 형태로 공존합니다.

환경특징

Exchange Online Only	클라우드 기반 운영
Exchange Hybrid	온프레미스 + Exchange Online 공존
On-Prem Exchange	내부 서버만 운영

특히 대기업·금융·공공기관은 여전히 Hybrid 환경을 많이 사용합니다.

그 이유는:

기존 Exchange 유지 필요
규제 및 보안 요구사항
단계적 클라우드 전환
메일 아카이빙
레거시 애플리케이션 연동
중앙 메일 라우팅 요구

때문입니다.

Microsoft는 Exchange Hybrid를 통해:

Single Organization 경험
Free/Busy 공유
Unified GAL
Mailbox Migration
Secure Mail Flow
Cross-Premises Management

를 제공합니다. (Microsoft Learn)

2. Exchange Online Calendar Sharing 구조 이해

2-1. 캘린더 공유 방식 종류

Exchange Online에서는 크게 3가지 방식이 존재합니다.

방식대상특징

Sharing Policy	Gmail/외부 사용자	개별 캘린더 공유
Organization Relationship	다른 M365 Tenant	Free/Busy 공유
Federation Trust	On-Prem Exchange	Hybrid 공유 필수

3. Organization Relationship 핵심 이해

조직 간 Free/Busy 공유란?

예를 들어:

Contoso
Fabrikam

두 회사가 있다고 가정합니다.

서로 미팅을 잡을 때:

상대방 일정 가능 여부 확인
Scheduling Assistant 사용
외부 조직 Availability 조회

가 가능해집니다.

Microsoft 공식 문서에서도:

Organization Relationship는 양쪽 조직 모두 설정해야 한다고 설명합니다. (Microsoft Learn)

4. Sharing Policy vs Organization Relationship 차이

항목Sharing PolicyOrganization Relationship

대상	외부 사용자(Gmail 등)	Exchange 조직
목적	캘린더 자체 공유	Free/Busy 조회
양방향 필요 여부	불필요	양쪽 모두 설정 필요
Delegate 가능 여부	제한적	불가능
사용 예시	Gmail 사용자 공유	회사 간 일정 공유

5. Exchange Online Calendar Sharing Permission 정리

공유 레벨

권한설명

Availability Only	시간 정보만
Limited Details	제목/위치 포함
Full Details	전체 일정
Editor	수정 가능
Delegate	일정 관리 가능

6. 실제 운영 시 자주 발생하는 문제

6-1. 외부 사용자 Availability 안 보임

원인

Organization Relationship 미설정
상대 테넌트 미구성
Federation 문제
Domain 설정 오류

실무 포인트

실제 운영에서는:

Test-OrganizationRelationship

명령어로 검증하는 경우가 많습니다.

Reddit 운영 사례에서도:
재생성 후 정상 동작한 사례가 공유되었습니다. (Reddit)

7. Exchange Hybrid란 무엇인가?

Exchange Hybrid 정의

Exchange Hybrid는:

온프레미스 Exchange와 Exchange Online을 하나의 조직처럼 운영하는 구조

입니다.

Microsoft 공식 문서에서도 다음 기능을 핵심으로 설명합니다:

Shared Domain Namespace
Unified GAL
Secure Mail Flow
Mailbox Migration
Cross-Premises Calendar Sharing (Microsoft Learn)

8. Exchange Hybrid 아키텍처

[On-Prem Exchange]
        │
        │ Hybrid Configuration Wizard
        │
[Microsoft Entra ID]
        │
[Exchange Online]

9. Exchange Hybrid 필수 구성 요소

구성 요소설명

Exchange Server	온프레미스 Exchange
Microsoft 365	EXO 환경
HCW	Hybrid Configuration Wizard
Entra ID Connect	디렉터리 동기화
Federation	Free/Busy 공유
SSL Certificate	TLS 메일 보안

Microsoft는 최신 CU 적용을 권장합니다. (Microsoft Learn)

10. Hybrid Configuration Wizard(HCW)

HCW는 Exchange Hybrid의 핵심입니다.

자동 구성되는 항목

Organization Relationship
Send Connector
Receive Connector
OAuth
Federation
Mail Flow
Free/Busy
MailTips

등을 자동 설정합니다. (Microsoft Learn)

11. Exchange Hybrid Mail Flow 완벽 이해

시나리오 1 — Centralized Mail Flow OFF

Internet
   ↓
Exchange Online
   ↓
Mailbox 위치에 따라 전달

특징

MX → Exchange Online
가장 일반적
클라우드 우선 구조

시나리오 2 — Centralized Mail Flow ON

Internet
   ↓
Exchange Online
   ↓
On-Prem Exchange
   ↓
Mailbox 전달

특징

모든 메일 On-Prem 경유
DLP/보안 장비 유지 가능
금융권에서 자주 사용

시나리오 3 — MX가 On-Prem

Internet
   ↓
On-Prem Exchange
   ↓
Exchange Online

특징

레거시 중심 구조
점진적 클라우드 이전

12. MailTips란?

메일 작성 중 사용자에게 알려주는 알림 기능입니다.

예시:

외부 사용자 여부
자동응답 활성화
큰 수신자 그룹
메일박스 Full 상태

HCW 구성 시 자동 활성화됩니다. (Microsoft Learn)

13. Exchange Online Archive 기능

Hybrid 환경에서는:

On-Prem Primary Mailbox
Exchange Online Archive

조합이 가능합니다.

즉:

Primary Mailbox → On-Prem
Archive Mailbox → Exchange Online

형태 운영이 가능합니다.

14. Mailbox Migration 종류 완벽 정리

방식특징

Cutover	전체 한 번 이동
Staged	단계적 이동
Hybrid(Remote Move)	가장 권장
IMAP	메일만 이동
PST Import	PST 업로드
Cross-Tenant	Tenant 간 이동

15. Hybrid Migration 핵심

실무에서 가장 많이 사용하는 방식입니다.

장점

사용자 영향 최소화
Outlook 프로필 유지
Free/Busy 유지
단계적 Migration 가능

16. Migration Endpoint란?

Source ↔ Target 연결 지점입니다.

주로:

MRS Proxy

를 사용합니다.

17. Migration 실패 원인 TOP 5

원인설명

SMTP 누락	ProxyAddress 문제
License 미할당	EXO Mailbox 생성 실패
MRS Proxy Disabled	Endpoint 실패
Large Item	큰 메일 실패
Existing Batch	중복 Migration

실습 중 실제로 SMTP Address 누락으로 실패 후 수정하여 해결한 사례가 있었습니다.

18. IMAP Migration 한계

IMAP Migration은:

❌ Calendar
❌ Contacts
❌ Tasks

이전이 불가능합니다.

오직 Mail만 이동됩니다.

19. Cross-Tenant Migration

M&A 환경에서 매우 중요합니다.

예시:

Tenant A → Tenant B

Mailbox를 이동할 수 있습니다.

20. Microsoft Entra ID Connect 중요성

Hybrid의 핵심은 사실상:

Identity Synchronization

입니다.

대표 명령어:

Start-ADSyncSyncCycle -PolicyType Delta

21. 실무자가 반드시 알아야 하는 운영 포인트

고객에게 먼저 확인할 것

체크 항목중요 이유

Mailbox 위치	On-Prem/Cloud 확인
MX 위치	Mail Flow 확인
Hybrid 여부	지원 범위 결정
Sync 방식	Identity 문제 분석
Exchange 버전	지원 여부

22. Hybrid 보안 이슈

최근 Microsoft는 Hybrid 환경 권한 상승 취약점(CVE-2025-53786)을 경고했습니다. (TechRadar)

권장 사항

최신 CU/SU 적용
Dedicated Hybrid App 사용
Exchange Health Checker 실행
Shared Service Principal 제거

23. 실무 PowerShell 모음

Mailbox 확인

Get-Mailbox

Remote Mailbox 생성

Enable-RemoteMailbox

Migration Batch 확인

Get-MigrationBatch

Org Relationship 확인

Get-OrganizationRelationship

Sync 강제 실행

Start-ADSyncSyncCycle -PolicyType Delta

24. 추천 실습 시나리오

실습 1 — Organization Relationship 구성

목표

Tenant A ↔ Tenant B Free/Busy 공유

체크 포인트

양쪽 테넌트 설정
Scheduling Assistant 테스트
External Availability 확인

실습 2 — Hybrid 구축

구성

DC
Exchange Server
Entra ID Connect
EXO Tenant

목표

HCW 실행 후:

Connector 생성 확인
Mail Flow 테스트
MailTips 테스트

실습 3 — Remote Mailbox 생성

목표

On-Prem에서 EXO Mailbox 생성

확인 포인트

Remote User Mailbox 상태
License 할당 후 Mailbox Provisioning

실습 4 — Hybrid Migration

목표

On-Prem → EXO Migration

테스트

Migration Endpoint 생성
Batch 생성
Large Item 처리
Completion 테스트

25. M365 엔지니어 관점 핵심 인사이트

진짜 중요한 건:

“메일박스가 어디에 존재하고 누가 그 Identity를 관리하는가”

입니다.

이걸 이해하지 못하면:

Mail Flow
Migration
Delegate
Free/Busy
SMTP
Sync

문제를 절대 해결할 수 없습니다.

26. 용어 정리 (Glossary)

용어설명

EXO	Exchange Online
HCW	Hybrid Configuration Wizard
MRS Proxy	Mailbox Replication Service
Organization Relationship	조직 간 Free/Busy 공유
Sharing Policy	외부 사용자 캘린더 공유
Remote Mailbox	EXO에 존재하는 Mailbox
Entra ID Connect	AD Sync 도구
MailTips	메일 작성 경고 기능
Centralized Mail Flow	중앙 메일 라우팅
Federation	조직 간 인증 신뢰

27. 추천 Microsoft 공식 문서

Hybrid Deployment

Calendar Sharing

28. 이 블로그의 기술 수준 평가

현재 수준 평가

이 글은 단순 “기능 소개” 수준이 아닙니다.

다음 역량이 드러납니다:

✅ 가능한 수준

Exchange Hybrid 아키텍처 이해
Mail Flow 분석 가능
Migration Troubleshooting 가능
EXO / On-Prem 역할 구분 가능
고객 환경 분석 가능
실제 운영 시나리오 이해

29. 추가 개선하여 “최고 수준 기술 블로그”로 만들기 위한 제안

추가하면 좋은 것

1. 실제 아키텍처 다이어그램

Hybrid Topology
Mail Flow Diagram
Federation 구조

2. 실제 장애 사례

예시:

Free/Busy 안 보이는 사례
SMTP ProxyAddress 문제
Migration Stuck 사례

3. PowerShell Troubleshooting 섹션 강화

예시:

Test-MigrationServerAvailability
Test-OutlookConnectivity
Test-OrganizationRelationship

4. Exchange Online Protection(EOP) 흐름 추가

Inbound Connector
Outbound Connector
Anti-Spam 처리 흐름

5. 라이선스 구조 정리

EXO Plan1/2
Archiving
Hybrid Benefit

마무리

Exchange Hybrid는 단순 “메일 이전 기술”이 아닙니다.

실제로는:

Identity
Authentication
Mail Routing
Synchronization
Security
Compliance

를 모두 이해해야 하는 고급 Microsoft 365 엔지니어링 영역입니다.

특히 실무에서는:

“문제가 Cloud인지, On-Prem인지, Hybrid Routing인지 판단하는 능력”

[교육 4일차] Mail Flow / Message Header / Security핵심 용어 정리

hyunjinlee9 — Fri, 15 May 2026 08:45:40 +0900

Mail Flow / Message Header / Security 핵심 용어 정리

Microsoft 365 Exchange Online을 공부하다 보면 영어 용어가 정말 많이 나온다.
처음에는 “이게 뭐였지?” 하고 헷갈렸는데, 단순 번역보다 아래처럼 정리하니까 훨씬 기억에 오래 남았다.

1. 스팸 / 피싱 점수 관련

SCL (Spam Confidence Level)

→ 스팸 신뢰도 점수
→ 숫자가 높을수록 스팸 가능성이 높음
→ X-Forefront-Antispam-Report 헤더에서 확인
→ SCL=5~9면 정크/격리 가능성 높음

BCL (Bulk Complaint Level)

→ 대량 메일 점수
→ 광고성/뉴스레터 메일 여부 판단
→ X-Microsoft-Antispam 헤더에서 확인
→ BCL=7 이상이면 정크 처리 가능

PCL (Phishing Confidence Level)

→ 피싱 위험 점수
→ 피싱 메일일 가능성 평가
→ 안티피싱 정책 및 헤더 정보에서 확인
→ 숫자가 높을수록 피싱 위험 증가

2. 메일 인증 관련

SPF (Sender Policy Framework)

→ 발신 서버 인증
→ 이 서버가 메일 보내도 되는지 검증
→ Authentication-Results 헤더에서 확인
→ spf=fail 이면 스푸핑 가능성 의심

DKIM (DomainKeys Identified Mail)

→ 전자서명 인증
→ 메일 내용이 중간에 변조되지 않았는지 확인
→ Authentication-Results 헤더에서 확인
→ dkim=fail 이면 서명 검증 실패

DMARC (Domain-based Message Authentication)

→ SPF/DKIM 기반 도메인 보호 정책
→ 인증 실패 시 어떻게 처리할지 결정
→ Authentication-Results 헤더에서 확인
→ dmarc=fail 이면 격리/차단 가능

Authentication-Results

→ 메일 인증 결과
→ SPF/DKIM/DMARC 성공 여부 표시
→ 메시지 헤더에서 확인
→ 메일 위조 여부 판단의 핵심 정보

3. 메시지 헤더(Message Header) 관련

Return-Path (P1)

→ 실제 발신 주소
→ 메일 서버가 실제로 사용한 발신자 주소
→ 메시지 헤더에서 확인
→ From 주소와 다르면 스푸핑 의심 가능

From (P2)

→ 사용자에게 보이는 발신자 주소
→ Outlook에서 보이는 메일 보낸 사람
→ 메일 상단/헤더에서 확인
→ 사용자는 정상처럼 보여도 실제 발신자는 다를 수 있음

CIP (Connecting IP)

→ 연결 IP 주소
→ 실제 메일 서버 IP
→ 헤더 내부에서 확인
→ 블랙리스트/스팸 서버 여부 분석 가능

X-Forefront-Antispam-Report

→ Microsoft 스팸 분석 결과
→ SCL/SFV/필터 결과 포함
→ 메시지 헤더에서 확인
→ 왜 스팸 처리됐는지 분석할 때 핵심

X-Microsoft-Antispam

→ 추가 스팸 분석 정보
→ BCL/PCL/추가 필터 정보 포함
→ 메시지 헤더에서 확인
→ Bulk 메일 여부 판단 시 중요

4. 보안 정책(Security Policy) 관련

Quarantine

→ 격리
→ 위험 메일을 사용자 대신 보관
→ Defender 포털에서 확인
→ 악성코드/고신뢰도 피싱은 관리자만 해제 가능

Safe Links

→ 안전한 링크 검사
→ URL 클릭 시 실시간 검사
→ Defender 정책 및 메일 본문에서 확인
→ 악성 사이트 접근 차단 가능

Safe Attachments

→ 안전한 첨부파일 검사
→ 첨부파일을 샌드박스에서 실행 분석
→ Defender 정책에서 확인
→ 기존 백신 우회 악성코드 탐지 가능

ZAP (Zero-hour Auto Purge)

→ 사후 자동 제거
→ 배달 후 위험 메일로 판정되면 자동 삭제
→ Message Trace 및 Defender에서 확인
→ 사용자가 봤던 메일이 갑자기 사라질 수 있음

5. 메일 흐름(Mail Flow) 관련

Transport Rule

→ 메일 흐름 규칙
→ 특정 조건에 따라 메일 처리
→ EAC > Mail Flow > Rules 에서 확인
→ SCL 설정/차단/리디렉션 등에 사용

SCL -1

→ 스팸 필터 우회
→ 해당 메일을 신뢰 메일처럼 처리
→ Transport Rule 에서 설정 가능
→ 안전하다는 뜻이 아니라 검사 일부 우회 의미

Enhanced Filtering

→ 향상된 필터링
→ 원래 발신자 IP 복원
→ Defender > Threat Policies 에서 설정
→ Third-party 필터링 환경에서 SPF 오류 방지

6. 실무에서 자주 보는 개념

False Positive

→ 오탐
→ 정상 메일인데 스팸 처리됨
→ Quarantine / Header / Message Trace로 분석
→ Microsoft 제출 가능

False Negative

→ 미탐
→ 위험 메일인데 정상 통과
→ 사용자 신고 및 헤더 분석 필요
→ 안티피싱 정책 조정 검토

공부하면서 느낀 점

처음에는 영어 용어 때문에 어렵게 느껴졌는데,
단순 암기보다:

영어 이름
실제 의미
어디서 보는지
어떤 상황에서 쓰는지

를 연결해서 공부하니까 훨씬 이해가 빨라졌다.

특히 Message Header 분석은 정말 중요했다.

메일이 왜 정크 처리됐는지,
왜 격리됐는지,
왜 정상 메일인데 차단됐는지는
결국 헤더와 Message Trace가 말해준다.

앞으로는 실제 메일 헤더를 많이 읽어보면서:

SPF fail
DKIM fail
DMARC fail
SCL/BCL 변화
ZAP 동작

같은 패턴을 반복해서 익혀볼 예정이다.

[교육 4일차]Mail flow, EOP & MDO Polices

hyunjinlee9 — Thu, 14 May 2026 16:02:51 +0900

Exchange Online 실전 운영 가이드 — Sender 차단부터 Partner Connector, 메시지 추적 심화까지

대상: Exchange Online을 운영하는 M365 엔지니어 및 관리자 시리즈: Mail Flow & 보안 정책 실습편

이전 글에서 DNS, 커넥터, 트랜스포트 규칙, EOP/Defender 보안 정책의 개념을 다뤘다면, 이번엔 실제로 손을 움직여야 하는 것들을 정리한다. Sender 차단, Partner Connector 직접 생성, SCL -1 우회 규칙, Extended Message Trace 분석까지 — 현장에서 바로 써먹을 수 있도록.

1. Sender & Domain 차단 — 어디서, 어떻게 막아야 하나

"특정 발신자 메일을 막고 싶다"는 요청은 고객 지원에서 가장 자주 들어오는 케이스 중 하나다. 그런데 차단 방법이 한 가지가 아니라 우선순위가 있는 4가지 옵션이 존재한다. 잘못된 곳에서 막으면 효과가 없거나 범위가 맞지 않는다.

차단 방법 우선순위

Microsoft가 권장하는 발신자·도메인 차단 방법의 우선순위는 다음과 같다. 가장 권장되는 방법은 Tenant Allow/Block List이며, 다음으로 Anti-spam policy의 Blocked Sender/Domain List, 그 다음 Mail flow rules, 마지막으로 Outlook Blocked Senders 순이다. Microsoft Learn

우선순위방법위치특징

✅ 1순위	Tenant Allow/Block List	Defender Portal → Threat policies → Tenant Allow/Block Lists	차단 시 SCL=9 처리, Microsoft 권장
2순위	Anti-spam Policy Blocked List	Defender Portal → Anti-spam	최대 1,000개, 포털에서 30개까지 직접 입력
3순위	Transport Rule	EAC → Mail flow → Rules	복잡한 조건 차단에 유연하게 활용 가능
4순위	Outlook Blocked Senders	사용자 Outlook 설정	개인 사서함 수준, 조직 전체 적용 불가

실습 시나리오 — Consumer Domain 차단하기

Defender Portal → Email & collaboration → Policies & rules → Threat policies → Anti-spam → Blocked Domains에 gmail.com 추가 → 해당 도메인에서 테스트 메일 발송 → 메시지 추적으로 차단 확인.

⚠️ 주의할 점: Blocked Sender List와 Blocked Domain List는 From 주소(P2)만 검사한다. Return-Path(P1 발신자)가 다른 경우 차단이 적용되지 않을 수 있다. 차단이 안 될 때는 P1/P2 발신자 주소 차이를 먼저 확인하자. Microsoft Learn

Tenant Allow/Block List 설정 — Create block entries for domains and email addresses 차단 방법 옵션 전체 가이드 — Create blocklists Anti-spam policies 설정 — Configure anti-spam policies

2. Partner Connector — Consumer Domain으로 직접 만들어보기

커넥터는 하이브리드 환경이나 기업 파트너 도메인에서만 쓰는 게 아니다. 오늘 실습에서는 gmail.com 같은 Consumer Domain을 대상으로 Partner Connector를 직접 생성해봤다. 검증(Validation)이 실패해도 커넥터를 저장할 수 있다는 것, 그리고 실패하는 이유를 정확히 파악하는 것이 핵심이었다.

Partner Connector 생성 순서

EAC → Mail flow → Connectors → + Add a connector

단계설정 항목내용

1	Connection from / to	Office 365 → Partner Organization
2	Connector name	식별 가능한 이름 입력
3	Use of connector	특정 도메인으로 보낼 때만 사용 또는 Transport Rule 리다이렉트 시 사용
4	Routing	MX record 또는 Smart host 중 선택
5	Security restrictions	TLS 암호화, 인증서 조건 설정
6	Validation	파트너 도메인의 활성 사서함으로 테스트 이메일 발송

파트너 조직과의 커넥터 설정은 선택 사항이다. 커넥터 없이도 파트너 조직과의 메일 흐름은 정상적으로 동작한다. TLS 암호화 강제 적용이나 IP 범위 제한 같은 보안 조건이 필요할 때 커넥터를 사용한다. Microsoft Learn

Validation이 실패하는 주요 원인

테스트 이메일 주소의 도메인 부분이 커넥터에 입력한 수신자 도메인과 일치해야 한다. Office 365에서 자체 이메일 서버 또는 파트너 조직으로의 메일 흐름에 대한 커넥터만 검증 가능하다. Microsoft Learn

가장 흔한 실패 원인들:

테스트 이메일 주소의 도메인이 커넥터 설정과 불일치
테넌트 도메인에 DMARC 레코드 없음
수신자 사서함이 활성 상태가 아님
단순 오타 (@ 앞뒤 모두 확인)

핵심 포인트: Validation에 실패해도 커넥터 저장 후 계속 진행할 수 있다. 실제 운영 환경에서는 반드시 Validation 통과 후 운영하는 것을 권장하지만, 실습 목적이나 긴급 상황에서는 저장 후 나중에 검증하는 것도 가능하다.

Configure mail flow using connectors Set up connectors for secure mail flow with a partner organization Validate connectors in Exchange Online Fixing connector validation errors

3. SCL -1 Transport Rule — 스팸 필터링 우회 규칙 만들기

서드파티 필터링 솔루션과 통합된 환경에서 정상 메일이 스팸으로 오탐되는 상황, 또는 신뢰할 수 있는 특정 IP에서 오는 메일을 필터링 없이 통과시켜야 할 때 사용하는 규칙이다.

규칙 생성 경로

EAC → Mail flow → Rules → Add a rule → Create a new rule

[조건] The sender's IP address is in any of these ranges
         → 신뢰할 수 있는 외부 IP 또는 IP 대역 입력

[작업] Modify the message properties
         → Set the spam confidence level (SCL) to: -1 (Bypass spam filtering)

PowerShell로 생성하는 경우:

powershell

New-TransportRule -Name "Bypass spam for trusted IP" `
  -SenderIpRanges "203.0.113.10/32" `
  -SetSCL -1

SCL을 Bypass spam filtering으로 설정하면 해당 규칙의 조건을 충족하는 메시지는 스팸 필터링을 건너뛴다. 단, 악성코드 검사 등 다른 Microsoft 365 이메일 보호 기능은 영향을 받지 않는다. Microsoft Learn

⚠️ 보안 주의사항: SCL -1은 "안전하다"는 의미가 아니라 "스팸 필터 우회" 를 의미한다. 고신뢰도 피싱 메일은 SCL -1이어도 항상 필터링된다. 신뢰할 수 있는 IP 범위에만 정밀하게 적용해야 하며, 무분별하게 사용하면 피싱 공격 경로가 열릴 수 있다.

Use mail flow rules to set the SCL in messages Anti-spam protection overview

4. Extended Message Trace 심화 — custom_data 컬럼 완전 해석

메시지 추적의 진짜 파워는 Extended Report의 custom_data 컬럼에 있다. 이걸 읽을 수 있으면 메일 플로우 이슈의 원인을 대부분 바로 찾아낼 수 있다.

보고서 3종 — 언제 무엇을 쓰나

보고서 유형조회 방법주요 사용 상황

Summary	포털 즉시 조회	발신자·수신자·상태·오류 메시지 빠른 확인
Enhanced Summary	CSV 다운로드	10일 이내 데이터 심층 분석
Extended	CSV 다운로드	10일 이상, custom_data 포함 전체 분석

custom_data 에이전트 코드 읽기

코드에이전트확인 가능한 정보

SFA	Spam Filter Agent	어떤 안티스팸 정책이 적용됐는지, SCL 판정 결과
AMA	Anti-Malware Agent	악성코드 탐지 여부, 격리 이유, 탐지된 파일명
TLA	Transport Rule Agent	어떤 트랜스포트 규칙이 적용됐는지, 규칙 ID

Extended Report 전용 추가 필드

message_delay       → 메시지 처리 지연 시간
tenant_id           → 테넌트 ID
original_server_ip  → 원본 발신 서버 IP (서드파티 통합 환경에서 핵심)
malware_file_names  → 탐지된 악성코드 파일명

⚠️ 실무 주의사항: 이메일 주소에 오타가 있는 경우 배달 실패 메일의 custom_data에 정책 적용 내역이 표시되지 않을 수 있다. custom_data가 비어 있다면 주소 오류 여부부터 확인하자.

최신 변경사항 (2025.09.01): 기존 Get-MessageTrace cmdlet은 deprecated. 이제 Get-MessageTraceV2를 사용해야 한다. Exchange Online PowerShell V3 모듈 버전 3.7.0 이상 필요.

powershell

# Extended Report 요청 예시
Get-MessageTraceV2 -SenderAddress "sender@contoso.com" `
  -StartDate "2025-01-01" -EndDate "2025-01-10" `
  -ResultSize 5000

Message trace in the new EAC New Message Trace (V2) — Get-MessageTraceV2 Message Trace FAQ

5. Message Header 분석 — 오늘의 복습 포인트

메시지 헤더 분석은 이번 시리즈에서 계속 반복되는 주제다. 볼 때마다 새로운 게 보인다.

Outlook에서 헤더 꺼내는 방법: 새 Outlook → 메일 열기 → ... 더보기 → View message details 클릭 클래식 Outlook → 메일 열기 → 파일 → 속성 → 인터넷 헤더 복사

Message Header Analyzer 에 붙여넣으면 필드별로 파싱돼서 훨씬 읽기 편하다.

Microsoft Message Header Analyzer

오늘 집중한 헤더 포인트:

헤더 필드확인 포인트

Authentication-Results	SPF · DKIM · DMARC 통과 여부 — 인증 실패 원인 파악의 첫 단계
X-Forefront-Antispam-Report	SCL · SFV 코드 — 왜 스팸으로 분류됐는지
X-Microsoft-Antispam	BCL — 대량 메일 필터 적용 여부
Return-Path (P1)	실제 봉투 발신자 — Transport Rule 조건 기준
From (P2)	사용자에게 보이는 발신자 — 사칭 여부 확인

새 Outlook vs 클래식 Outlook: 같은 메일도 두 클라이언트에서 헤더 내용이 미묘하게 다를 수 있다. 트러블슈팅 시 두 버전에서 각각 헤더를 수집해서 비교해보는 습관을 들이자.

Anti-spam message headers (Microsoft Learn)

마무리 — 오늘 실습 체크리스트

Tenant Allow/Block List에서 특정 Consumer Domain 차단 후 메시지 추적으로 결과 확인했는가?
Partner Connector를 gmail.com 대상으로 생성하고 Validation 결과를 확인했는가?
Validation 실패 원인을 DMARC · 도메인 불일치 · 주소 오류 순서로 점검했는가?
SCL -1 Transport Rule을 특정 IP 조건으로 생성하고 동작을 테스트했는가?
Extended Report의 custom_data에서 SFA · AMA · TLA 코드를 직접 읽어봤는가?
새 Outlook과 클래식 Outlook에서 각각 메시지 헤더를 수집해 비교했는가?

오늘 실습 관련 참고 문서 모음

주제Microsoft Learn 링크

Tenant Allow/Block List 설정	Create block entries for domains and email addresses
차단 방법 우선순위 전체 가이드	Create blocklists in Office 365
Anti-spam policy 설정	Configure anti-spam policies
Outbound anti-spam policy	Configure outbound spam policies
커넥터 구성 전체 가이드	Configure mail flow using connectors
Partner Connector 보안 설정	Set up connectors for secure mail flow with a partner
Connector Validation	Validate connectors in Exchange Online
Connector Validation 오류 해결	Fixing connector validation errors
SCL 설정 Transport Rule	Use mail flow rules to set the SCL
SCL 개요	Spam confidence level (SCL)
Message Trace (새 EAC)	Message trace in the new EAC
Get-MessageTraceV2	New Message Trace (V2)
안티스팸 메시지 헤더 분석	Anti-spam message headers
Enhanced Filtering for Connectors	Enhanced filtering for connectors

이번 시리즈에서 반복해서 강조하는 한 가지가 있다. "설정은 도구를 아는 것보다 목적을 아는 게 먼저다." Sender를 막을 때도, Connector를 만들 때도, 규칙을 추가할 때도 — 왜 이 방법을 쓰는지, 다른 방법과 뭐가 다른지를 알고 있어야 고객에게 제대로 된 솔루션을 제시할 수 있다.

[교육 3일차] Exchange Online 랩 리뷰 — 마무리 과제 & Q&A

hyunjinlee9 — Wed, 13 May 2026 16:59:15 +0900

"권한을 읽는 것과 랩에서 직접 부숴보는 것은 완전히 다른 이야기다. 진짜 학습은 후자에서 시작된다."

마무리 과제 — 랩 실습 가이드

Task 1. 사용자 메일박스를 공유 메일박스로 전환

퇴사한 직원의 메일박스를 팀이 계속 접근할 수 있도록 유지해야 할 때, 라이선스 비용 없이 가장 깔끔한 해결책이 바로 사용자 메일박스 → 공유 메일박스 전환이다.

Admin Center에서 전환:

Microsoft 365 Admin Center → 사용자 → 활성 사용자
대상 사용자 선택 → 메일 탭
"공유 메일박스로 전환" 클릭 → 확인

PowerShell로 전환:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# 사용자 메일박스를 공유 메일박스로 전환
Set-Mailbox -Identity "john.doe@contoso.com" -Type Shared

전환 후 일어나는 일:

메일박스가 공유 메일박스로 변경 (50GB, 라이선스 불필요)
사용자 계정은 Entra ID에 그대로 남음 → 필요에 따라 비활성화 또는 삭제 가능
라이선스는 전환 후 반드시 제거 — 공유 메일박스에는 라이선스가 필요 없음
이후 접근은 Full Access 권한 위임 방식으로만 가능

⚠️ 실무 주의사항: 라이선스를 제거하기 전에 계정을 삭제하면 복잡한 상황이 생길 수 있다. 순서는 반드시 전환 → 라이선스 제거 → 계정 비활성화/삭제 순으로.

Task 2. 공유 메일박스 열기 및 사용 (OWA & Outlook 데스크톱/New Outlook)

클라이언트별로 접근 방식이 다르다. 세 가지 모두 알고 있어야 고객 문의에 대응할 수 있다.

방법 A — Outlook on the Web (OWA)

방법 1: 직접 URL 접근

https://outlook.office.com/mail/shared@contoso.com

방법 2: "다른 사서함 열기"

우측 상단 프로필 사진 클릭 → "다른 사서함 열기"
공유 메일박스 주소 입력 → 열기
새 브라우저 탭에서 공유 메일박스가 열림

공유 메일박스에서 메일 발송:

새 메일 작성 → "보낸 사람" 필드 클릭
공유 메일박스 주소 선택 또는 직접 입력
발송 시 수신자에게 공유 메일박스 주소로 표시됨 (Send As 권한 부여 시)

방법 B — New Outlook for Windows

Full Access 권한이 있는 공유 메일박스는 자동으로 왼쪽 폴더 창에 표시된다. 자동으로 나타나지 않을 경우:

왼쪽 폴더 창에서 기본 계정 우클릭
"공유 폴더 또는 사서함 추가" 선택
공유 메일박스 주소 검색 후 추가

방법 C — 클래식 Outlook 데스크톱 클라이언트

파일 → 계정 설정 → 계정 설정
Exchange 계정 선택 → 변경 → 추가 설정 → 고급
"추가 사서함 열기" 항목에서 추가 → 공유 메일박스 주소 입력
Outlook 재시작 → 왼쪽 폴더 창에 공유 메일박스 표시

지원 시나리오 팁: 고객이 "공유 메일박스가 Outlook에 안 뜬다"고 하면, Full Access 권한이 최근에 부여됐는지 확인하자. 권한 전파에 최대 60분이 걸릴 수 있다. 또한 AutoMapping이 비활성화된 경우 권한이 있어도 자동으로 표시되지 않는다.

# AutoMapping 포함 Full Access 권한 부여 (기본값)
Add-MailboxPermission -Identity "shared@contoso.com" `
                      -User "john@contoso.com" `
                      -AccessRights FullAccess `
                      -AutoMapping $true

# AutoMapping 없이 Full Access 권한 부여
Add-MailboxPermission -Identity "shared@contoso.com" `
                      -User "john@contoso.com" `
                      -AccessRights FullAccess `
                      -AutoMapping $false

Task 3. 공유 메일박스 생성 및 위임 멤버 추가

Admin Center에서 생성:

Exchange Admin Center → 받는 사람 → 공유 사서함 → 공유 사서함 추가
표시 이름 및 이메일 주소 입력 → 만들기
생성 후 → 편집 → 사서함 위임
Full Access 및/또는 Send As 항목에 멤버 추가

PowerShell로 생성 및 권한 부여:

# Step 1: 공유 메일박스 생성
New-Mailbox -Shared `
            -Name "Support Team" `
            -DisplayName "Support Team" `
            -Alias "support" `
            -PrimarySmtpAddress "support@contoso.com"

# Step 2: Full Access 권한 부여
Add-MailboxPermission -Identity "support@contoso.com" `
                      -User "alice@contoso.com" `
                      -AccessRights FullAccess `
                      -InheritanceType All

# Step 3: Send As 권한 부여
Add-RecipientPermission -Identity "support@contoso.com" `
                        -Trustee "alice@contoso.com" `
                        -AccessRights SendAs `
                        -Confirm:$false

# Step 4: Send on Behalf 권한 부여
Set-Mailbox -Identity "support@contoso.com" `
            -GrantSendOnBehalfTo @{Add="bob@contoso.com"}

# 권한 전체 확인
Get-MailboxPermission -Identity "support@contoso.com"
Get-RecipientPermission -Identity "support@contoso.com"
Get-Mailbox -Identity "support@contoso.com" | 
    Select-Object GrantSendOnBehalfTo

Task 4. PowerShell로 메일 연락처 및 메일 사용자 생성

메일 연락처(Mail Contact)와 메일 사용자(Mail User)의 차이부터 짚고 가자:

구분 메일 연락처 메일 사용자

위치	조직 외부 인물	조직 내부 계정 보유
이메일 주소	외부 주소만 보유	내부 + 외부 주소 보유
조직 리소스 접근	불가	가능
주소록 표시	표시됨	표시됨

# ① 메일 연락처 생성
New-MailContact -Name "Jane Smith" `
                -DisplayName "Jane Smith" `
                -ExternalEmailAddress "jane.smith@external.com" `
                -FirstName "Jane" `
                -LastName "Smith"

# ② 메일 사용자 생성
New-MailUser -Name "Bob External" `
             -DisplayName "Bob External" `
             -ExternalEmailAddress "bob@partner.com" `
             -UserPrincipalName "bob.external@contoso.com" `
             -Password (ConvertTo-SecureString "TempPass123!" `
                        -AsPlainText -Force) `
             -FirstName "Bob" `
             -LastName "External"

언제 어떤 걸 쓰나? 단순히 주소록에 외부 연락처를 등록하고 메일 배포 그룹에 포함시키고 싶다면 메일 연락처. 외부 파트너가 내부 시스템(SharePoint, Teams 등)에도 접근해야 한다면 메일 사용자.

Task 5. 메일 연락처 및 메일 사용자 목록 내보내기 (PowerShell)

# ① 메일 연락처 전체 목록 조회
Get-MailContact | Select-Object DisplayName, 
                                PrimarySmtpAddress, 
                                ExternalEmailAddress

# ② 메일 연락처 목록 CSV로 내보내기
Get-MailContact | Select-Object DisplayName, 
                                PrimarySmtpAddress, 
                                ExternalEmailAddress |
    Export-Csv -Path "C:\MailContacts.csv" `
               -NoTypeInformation `
               -Encoding UTF8

# ③ 메일 사용자 전체 목록 조회
Get-MailUser | Select-Object DisplayName, 
                              UserPrincipalName, 
                              ExternalEmailAddress

# ④ 메일 사용자 목록 CSV로 내보내기
Get-MailUser | Select-Object DisplayName, 
                             UserPrincipalName, 
                             ExternalEmailAddress |
    Export-Csv -Path "C:\MailUsers.csv" `
               -NoTypeInformation `
               -Encoding UTF8

# ⑤ 메일 연락처 + 메일 사용자 통합 조회 (Get-Recipient 활용)
Get-Recipient -RecipientType MailContact, MailUser |
    Select-Object DisplayName, 
                  RecipientType, 
                  PrimarySmtpAddress |
    Export-Csv -Path "C:\AllExternalRecipients.csv" `
               -NoTypeInformation `
               -Encoding UTF8

Task 6. PowerShell로 메일 연락처 대량 삭제

# ① 삭제 전 반드시 대상 목록 확인
Get-MailContact | Select-Object DisplayName, PrimarySmtpAddress

# ② 전체 메일 연락처 일괄 삭제 (주의: 되돌릴 수 없음)
Get-MailContact | Remove-MailContact -Confirm:$false

# ③ 특정 조건으로 필터링 후 삭제 (권장 방식)
# 예: 특정 도메인의 연락처만 삭제
Get-MailContact | Where-Object {
    $_.ExternalEmailAddress -like "*@olddomain.com"
} | Remove-MailContact -Confirm:$false

# ④ CSV 파일 기반 대량 삭제 (가장 안전한 방식)
# 삭제 대상 목록을 CSV로 미리 준비
Import-Csv "C:\ContactsToDelete.csv" | ForEach-Object {
    Remove-MailContact -Identity $_.PrimarySmtpAddress `
                       -Confirm:$false
    Write-Host "Deleted: $($_.PrimarySmtpAddress)"
}

⚠️ 삭제 전 체크리스트:

삭제 대상 목록을 반드시 CSV로 백업해두자

-Confirm:$false 는 확인 프롬프트를 건너뛰므로 신중하게 사용

프로덕션 환경에서는 항상 -WhatIf 플래그로 먼저 시뮬레이션

# 실제 삭제 전 WhatIf로 시뮬레이션
Get-MailContact | Where-Object {
    $_.ExternalEmailAddress -like "*@olddomain.com"
} | Remove-MailContact -WhatIf

Task 7. 모든 권한 설명 및 랩 재현

Exchange Online 메일박스 권한은 크게 세 가지다. 각각의 동작 방식을 랩에서 직접 재현해보자.

권한 1. Full Access (전체 액세스)

할 수 있는 것: 메일박스 열기, 메일 읽기·이동·삭제, 폴더 생성 할 수 없는 것: 해당 메일박스 주소로 메일 발송

# Full Access 권한 부여
Add-MailboxPermission -Identity "shared@contoso.com" `
                      -User "alice@contoso.com" `
                      -AccessRights FullAccess `
                      -InheritanceType All

# 권한 확인
Get-MailboxPermission -Identity "shared@contoso.com" |
    Where-Object { $_.User -like "*alice*" }

# 권한 제거
Remove-MailboxPermission -Identity "shared@contoso.com" `
                         -User "alice@contoso.com" `
                         -AccessRights FullAccess `
                         -Confirm:$false

랩 재현 포인트: Full Access만 부여한 상태에서 OWA로 공유 메일박스를 열어 메일을 읽을 수 있는지 확인. 그 상태에서 해당 메일박스 주소로 발송을 시도하면 오류 발생 — 이게 Full Access의 한계다.

권한 2. Send As (대신 보내기)

할 수 있는 것: 공유 메일박스 주소로 직접 발송 수신자에게 보이는 발신자: support@contoso.com (위임 관계 표시 없음)

# Send As 권한 부여
Add-RecipientPermission -Identity "shared@contoso.com" `
                        -Trustee "alice@contoso.com" `
                        -AccessRights SendAs `
                        -Confirm:$false

# 권한 확인
Get-RecipientPermission -Identity "shared@contoso.com" |
    Where-Object { $_.Trustee -like "*alice*" }

# 권한 제거
Remove-RecipientPermission -Identity "shared@contoso.com" `
                           -Trustee "alice@contoso.com" `
                           -AccessRights SendAs `
                           -Confirm:$false

랩 재현 포인트: Send As 권한만 부여한 상태에서 OWA "보낸 사람" 필드에 공유 메일박스 주소를 추가해 발송. 수신자 측에서 발신자가 support@contoso.com으로만 표시되는지 확인.

권한 3. Send on Behalf (대리 보내기)

할 수 있는 것: 공유 메일박스를 대신하여 발송 수신자에게 보이는 발신자: alice@contoso.com on behalf of support@contoso.com

# Send on Behalf 권한 부여
Set-Mailbox -Identity "shared@contoso.com" `
            -GrantSendOnBehalfTo @{Add="bob@contoso.com"}

# 권한 확인
Get-Mailbox -Identity "shared@contoso.com" | 
    Select-Object GrantSendOnBehalfTo

# 권한 제거
Set-Mailbox -Identity "shared@contoso.com" `
            -GrantSendOnBehalfTo @{Remove="bob@contoso.com"}

랩 재현 포인트: Send on Behalf 권한만 부여한 상태에서 발송 후 수신자 측에서 on behalf of 형태로 표시되는지 확인. Send As와의 표시 차이를 직접 눈으로 비교하는 것이 핵심.

Review Questions — 심층 Q&A

Q1. Send As와 Send on Behalf 권한이 동시에 부여되면 어떻게 될까?

"두 권한을 동시에 주면 어떤 게 이기나?"

결론부터: Send As가 우선 적용된다.

Exchange Online은 두 권한이 동시에 존재할 때 Send As를 우선 처리한다. 즉, 수신자에게는 support@contoso.com으로만 표시되고 on behalf of 문구는 나타나지 않는다.

랩에서 직접 재현해보자:

# 두 권한 동시 부여
Add-RecipientPermission -Identity "shared@contoso.com" `
                        -Trustee "alice@contoso.com" `
                        -AccessRights SendAs `
                        -Confirm:$false

Set-Mailbox -Identity "shared@contoso.com" `
            -GrantSendOnBehalfTo @{Add="alice@contoso.com"}

# 현재 권한 상태 확인
Get-RecipientPermission -Identity "shared@contoso.com"
Get-Mailbox "shared@contoso.com" | Select-Object GrantSendOnBehalfTo

이 상태에서 Alice가 공유 메일박스 주소로 메일을 보내면, 수신자에게는 support@contoso.com으로만 표시된다. on behalf of 는 나타나지 않는다.

실무에서 이 상황이 문제가 되는 경우: 고객이 "Send on Behalf로 설정했는데 왜 on behalf of가 안 뜨냐"고 문의할 때가 있다. 이 경우 Send As 권한이 함께 부여되어 있는지 먼저 확인하면 된다. 두 권한이 공존하면 Send As가 항상 이긴다.

Q2. 메일박스가 GAL(글로벌 주소록)에 숨겨져 있으면 Send As나 Send on Behalf가 동작할까?

"숨긴다고 권한까지 사라지는 건 아닌데, 왜 발송이 안 될까?"

결론: 동작하지 않는다.

GAL에 숨겨진 메일박스는 Send As 또는 Send on Behalf 권한이 부여되어 있어도 해당 주소로 발송할 수 없다. OWA의 "보낸 사람" 필드에서 해당 주소를 선택하거나 입력하면 주소를 찾을 수 없다는 오류가 발생한다.

왜 그럴까? Exchange Online에서 발신자 주소를 설정할 때 내부적으로 주소 확인(Address Resolution) 프로세스가 실행된다. 이 과정에서 Exchange는 해당 주소가 유효한 수신자인지 조회하는데, GAL에서 숨겨진 메일박스는 이 조회 결과에서 제외된다. 권한 자체는 존재하지만, 주소 확인 단계에서 막히는 구조다.

랩에서 재현:

# 메일박스를 GAL에서 숨기기
Set-Mailbox -Identity "shared@contoso.com" `
            -HiddenFromAddressListsEnabled $true

# 숨김 상태 확인
Get-Mailbox -Identity "shared@contoso.com" | 
    Select-Object HiddenFromAddressListsEnabled

# Send As 권한은 여전히 존재
Add-RecipientPermission -Identity "shared@contoso.com" `
                        -Trustee "alice@contoso.com" `
                        -AccessRights SendAs `
                        -Confirm:$false

이 상태에서 Alice가 OWA에서 shared@contoso.com으로 발송을 시도하면 오류가 발생한다.

해결책은 두 가지:

# 방법 1: GAL 숨김 해제
Set-Mailbox -Identity "shared@contoso.com" `
            -HiddenFromAddressListsEnabled $false

# 방법 2: 숨김을 유지하면서 발송이 필요하다면
# → 포워딩 또는 메일 흐름 규칙으로 우회 구성 검토

고객 지원 팁: 고객이 "권한을 줬는데 공유 메일박스 주소로 발송이 안 된다"고 하면, 권한 확인과 함께 GAL 숨김 여부를 반드시 체크하자. 이 두 가지를 동시에 확인하는 습관이 트러블슈팅 시간을 크게 줄여준다.

Q3. EAC(Exchange Admin Center)에서 사용자 메일박스를 직접 생성할 수 있을까?

결론: 불가능하다.

Exchange Admin Center에서는 사용자 메일박스를 직접 생성하는 옵션이 존재하지 않는다. 이것은 버그나 제한이 아니라 Microsoft의 의도적인 설계다.

왜 그럴까? Exchange Online에서 사용자 메일박스는 독립적으로 존재하지 않는다. 메일박스는 항상 Microsoft Entra ID의 사용자 계정에 종속된다. 계정이 먼저 존재해야 메일박스가 생길 수 있는 구조다.

올바른 사용자 메일박스 생성 흐름:

Microsoft 365 Admin Center에서 사용자 계정 생성
    → Exchange Online 라이선스 할당
        → 메일박스 자동 프로비저닝 (수 분 내)
            → Exchange Admin Center에서 확인 가능

# PowerShell로도 동일한 흐름 — 먼저 사용자 생성 후 라이선스 할당
# Step 1: Microsoft Graph로 사용자 생성
Connect-MgGraph -Scopes "User.ReadWrite.All"

New-MgUser -DisplayName "Hyunjin Lee" `
           -UserPrincipalName "hyunjin@contoso.com" `
           -PasswordProfile @{
               Password = "TempPass123!"
               ForceChangePasswordNextSignIn = $true
           } `
           -AccountEnabled $true `
           -UsageLocation "KR"

# Step 2: 라이선스 할당 후 메일박스 자동 생성됨
# (라이선스 할당은 Microsoft 365 Admin Center 또는 Graph API로 진행)

# Step 3: 메일박스 프로비저닝 확인 (수 분 소요)
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-Mailbox -Identity "hyunjin@contoso.com"

EAC에서 직접 생성 가능한 메일박스 유형은 따로 있다:

메일박스 유형 EAC 직접 생성 가능 여부

사용자 메일박스	❌ 불가 (M365 Admin Center에서 생성)
공유 메일박스	✅ 가능
룸 메일박스	✅ 가능
장비 메일박스	✅ 가능

고객 지원 팁: 고객이 "Exchange 관리 센터에서 직원 계정을 만들려고 하는데 어디 있냐"고 물어보면, M365 Admin Center에서 사용자를 생성하고 라이선스를 할당해야 메일박스가 자동으로 생성된다고 안내하자. EAC는 메일박스 관리 도구이지, 사용자 생성 도구가 아니다.

마치며

"오늘 랩에서 가장 많이 배운 건 명령어가 아니라 '왜 안 되는지'였다."

권한을 부여했는데 발송이 안 되고, GAL에 숨겼더니 주소 확인이 막히고, EAC에서 사용자를 만들려고 했더니 옵션 자체가 없고 — 이런 상황들이 실제 고객 문의에서 그대로 나온다.

명령어를 외우는 것보다 "왜 이렇게 동작하는지" 를 이해하는 것이 기술지원 엔지니어로서 훨씬 오래가는 자산이다. 오늘 랩이 그 토대를 만들어줬다.

Microsoft 365 기술지원 엔지니어 교육 — 마무리 과제 랩 리뷰 | Hyunjin Lee

[교육 3일차] Overview of Exchange Online

hyunjinlee9 — Wed, 13 May 2026 16:45:30 +0900

Overview of Exchange Online

클라우드 메일 서비스라고 얕봤다가 하루 만에 생각이 바뀌었다.

Microsoft 365 기술지원 엔지니어 교육 3일차. 오늘의 주제는 Exchange Online이었다. 솔직히 말하면 교육 시작 전까지는 "그냥 클라우드 메일 서비스 아닌가?" 정도로 생각했다. 하루가 지난 지금, 그 생각은 완전히 틀렸다는 걸 안다.

인증, 권한, 도메인, 메일 흐름, 보안, 컴플라이언스까지 — Exchange Online은 이 모든 것이 맞물려 돌아가는 하나의 생태계였다. 오늘 배운 내용을 내 방식으로 정리해봤다.

1. Exchange Online이 뭔지 다시 정의해보자

Exchange Online은 Microsoft 데이터 센터에서 운영되는 클라우드 기반 메일·일정·연락처·작업 관리 서비스다. 서버를 직접 구축할 필요가 없다는 게 가장 큰 장점이지만, 여기서 중요한 포인트가 하나 있다.

Microsoft는 서비스 가용성만 보장한다. 정책 설정과 사용자 관리는 전적으로 고객 조직의 몫이다.

지원 엔지니어 입장에서 이 문장은 굉장히 중요하다. 고객이 "왜 이렇게 됐냐"고 물어봤을 때, 그게 Microsoft 인프라 문제인지 고객 설정 문제인지를 빠르게 구분할 수 있어야 한다. 그 출발점이 바로 이 개념이다.

인증과 접근 관리는 Microsoft Entra ID와 통합되어 처리된다. 즉, 계정 하나로 Exchange뿐 아니라 Microsoft 365 전체 서비스에 접근하는 구조다.

2. 플랜별 스펙, 숫자로 확실히 외워두자

고객 문의 중 꽤 많은 비율이 "용량이 부족하다", "아카이브를 쓰고 싶다"는 내용이다. 플랜별 스펙을 모르면 대답을 못 한다.

플랜 메일박스 아카이브

Exchange Online Plan 1	50GB	50GB
Exchange Online Plan 2	100GB	최대 1.5TB
비즈니스 프리미엄 / E3 / E5	100GB	최대 1.5TB
비즈니스 베이직 / 스탠다드	50GB	50GB
M365 F1 (Frontline)	❌ 메일박스 없음	—

그리고 오늘 가장 기억에 남은 스펙 하나.

공유·룸·장비 메일박스 → 라이선스 없이 50GB 무료 제공.

라이선스 비용 걱정 없이 회의실 예약 시스템을 구축할 수 있다는 뜻이다. 고객사 규모가 클수록 이 포인트를 모르면 불필요한 비용이 발생할 수 있다.

메시지 크기 제한도 챙겨두자. Outlook 웹은 최대 112MB, 데스크톱은 최대 150MB다. 첨부파일 관련 문의가 들어오면 이 수치부터 확인하면 된다.

3. 메일 삭제, 사실 바로 없어지는 게 아니다

고객이 "메일을 실수로 지웠어요"라고 연락해올 때 당황하지 않으려면 아래 흐름을 머릿속에 그릴 수 있어야 한다.

[1단계] 삭제함
    ↓ 보관 기간: 무제한 (사용자가 비우기 전까지)

[2단계] 복구함 (Recoverable Items)
    ↓ 보관 기간: 14일
    ↓ 이후 → 영구 삭제 ❌

[예외] 정크 메일함
    → 7일 후 자동 영구 삭제

14일 안에 연락이 왔다면 복구 가능하다. 그 이후라면?

여기서 Litigation Hold가 등장한다. 이 보존 정책이 설정된 계정은 위 흐름과 관계없이 지정 기간 또는 무기한으로 메일이 보관된다. 법적 분쟁 가능성이 있는 기업이나 규정 준수가 필요한 산업군 고객에게는 사실상 필수 기능이다.

4. 권한 3형제 — 이것만큼은 헷갈리면 안 된다

공유 메일박스 관련 문의에서 가장 자주 혼동되는 부분이다. 세 가지 권한의 차이를 정확히 이해하고 있어야 고객 설명이 가능하다.

권한 할 수 있는 것 수신자에게 보이는 발신자

Full Access	읽기·추가·삭제 (발송은 불가)	—
Send As	해당 메일박스 주소로 직접 발송	support@company.com
Send on Behalf	위임 발송	A on behalf of support@company.com

실무에서 놓치기 쉬운 두 가지 함정:

첫째, Send As와 Send on Behalf를 동시에 부여하면 Send As가 우선 적용된다. 고객이 "대리 발신자 표시가 안 된다"고 할 때 이 경우일 가능성이 높다.

둘째, 글로벌 주소록에 숨겨진 메일박스는 아무리 권한을 부여해도 발송이 되지 않는다. 권한 설정이 맞는데도 발송이 안 된다고 하면, 숨김 여부부터 확인하자.

5. 그룹 유형, 목적에 맞게 골라야 한다

"그룹 만들어달라"는 요청이 들어왔을 때 어떤 그룹을 만들어야 할지 바로 판단할 수 있어야 한다.

그룹 유형 핵심 목적 특징

Microsoft 365 그룹	협업 + Teams 연동	공유 메일함·캘린더·파일 포함, 50GB 저장
배포 그룹	메일 일괄 발송	리소스 권한 부여 불가
메일 사용 보안 그룹	메일 배포 + 리소스 권한	두 기능 겸용
동적 배포 그룹	조건 기반 자동 멤버 관리	부서·속성 필터로 멤버 자동 추가·제외

동적 배포 그룹은 오늘 처음 제대로 이해했는데, 솔직히 꽤 인상적이었다. 부서 속성을 기준으로 필터를 걸어두면 신입이 입사하거나 부서가 바뀔 때 멤버 목록을 따로 관리할 필요가 없다. 수백 명 규모 조직이라면 관리 공수를 극적으로 줄여주는 기능이다.

6. 메일 흐름, MX 레코드가 모든 것의 시작이다

메일이 왜 안 가는지 분석할 때 가장 먼저 봐야 할 것이 MX 레코드다. MX 레코드가 메일박스 호스팅 위치를 가리키기 때문에, 이게 잘못 설정되어 있으면 메일 전달 자체가 틀어진다.

도메인 유형도 메일 흐름을 결정하는 핵심 변수다.

Authoritative(권위 도메인): Exchange Online이 해당 도메인의 메일을 직접 처리. 수신자가 없으면 NDR 즉시 반환.
Internal Relay(내부 릴레이): 수신자가 없으면 On-premises 서버로 릴레이. Hybrid 환경에서 주로 사용.

메일 흐름 규칙(전송 규칙)을 활용하면 특정 도메인 발송 차단, 외부 발신자 경고 배너 삽입 등 다양한 정책을 코드 한 줄 없이 적용할 수 있다. 커넥터를 이용하면 타사 위협 필터링 서버를 경유한 후 최종 수신자에게 전달하는 복합 메일 흐름 구성도 가능하다.

7. Exchange Online 관리 도구 지도

오늘 세션에서 명확해진 것 중 하나가 바로 이 부분이다. Exchange Online 관리는 하나의 포털에서 끝나지 않는다.

Microsoft 365 Admin Center   → 사용자 생성, 라이선스 할당
Exchange Admin Center        → 메일박스·그룹·메일 흐름 관리
Security / Defender Portal   → 이메일 보안, 위협 보호
Microsoft Purview Portal     → 데이터 거버넌스, 보존 정책
Entra ID Admin Center        → 인증, 조건부 액세스, 계정 관리
PowerShell                   → 위 모든 것의 자동화 + 포털 불가 작업

참고로 Exchange Admin Center에서 직접 사용자 메일박스를 생성하는 건 불가능하다. Microsoft 365 Admin Center에서 사용자를 만들고 라이선스를 할당해야 메일박스가 자동으로 프로비저닝된다. 처음 알았을 때 살짝 당황했던 포인트.

8. PowerShell, 세 가지 모듈을 구분해서 써야 한다

Exchange Online 관련 PowerShell 모듈은 목적에 따라 세 가지로 나뉜다.

# ① Exchange Online 관리 (메일박스·수신자·그룹)
Install-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

Get-Mailbox                    # 메일박스 조회
Get-Recipient                  # 수신자 전체 조회

# ② 보안·컴플라이언스 관리 (보존 정책 등)
Connect-IPPSSession

Get-RetentionCompliancePolicy  # 보존 정책 확인

# ③ 신원·계정 관리 (사용자·그룹)
Connect-Entra  # 또는 Connect-MgGraph

Graph와 다른 점 하나: Exchange Online PowerShell은 설치 후 반드시 Import-Module을 실행해야 한다. 이걸 빠뜨리면 명령어가 인식이 안 돼서 처음에 한 번쯤은 헤매게 된다.

버전도 중요하다. v1, v2, v3가 있는데 구버전을 쓰면 연결 오류가 발생할 수 있다. 항상 최신 버전을 유지하자.

마지막으로 지원 범위에 대한 중요한 원칙 하나.

고객이 직접 작성한 커스텀 PowerShell 스크립트는 지원 범위에 포함되지 않는다. Microsoft에서 공식 제공하는 스크립트와 명령어만 지원 가능하다.

이 원칙을 명확히 알고 있어야 고객과의 경계를 정확히 그을 수 있다.

9. 오늘의 미해결 질문

"글로벌 주소록에 숨겨진 메일박스는 왜 Send As가 안 될까?"

오늘 강사님께서 "숨겨진 메일박스는 Send As가 동작하지 않는다"고 설명하셨는데, 정확한 기술적 원인까지는 다루지 않았다. 주소 확인(Address Resolution) 프로세스와 연관이 있는 것 같은데, 좀 더 파봐야 할 것 같다.

추가로, Hybrid 환경에서 권위 도메인과 내부 릴레이 도메인이 혼용될 때 NDR 발생 시 원인 분석 절차도 아직 체계적으로 정리가 안 됐다. 다음 주 심화 세션 전에 직접 테스트해볼 예정이다.

마치며 — 오늘 배운 것의 핵심 한 줄

"메일박스가 어디 있는지부터 물어라."

클라우드인지, On-premises인지, Hybrid인지. 이 질문 하나가 트러블슈팅 방향을 완전히 바꾼다. 같은 증상이라도 호스팅 위치에 따라 원인과 해결책이 전혀 달라지기 때문이다.

그리고 어떤 포털에서 무엇을 해야 하는지를 바로 떠올릴 수 있는 것 자체가 실력이라는 것도 오늘 다시 한번 느꼈다. 기능을 아는 것과, 고객 문의가 들어왔을 때 어디서 무엇을 확인해야 하는지 바로 판단하는 것은 전혀 다른 이야기다.

내일은 더 깊이 들어간다. 기대된다.

Microsoft 365 기술지원 엔지니어 교육 3일차 | Hyunjin Lee

hyunjinlee9 님의 블로그

[교육 10일차] Exchange Online 트러블슈팅 기술 블로그

증거 기반(Evidence-Based) Exchange Online 트러블슈팅 워크플로우

1. 시작은 항상 '스코핑'

2. 재현이 안 되면, 증거를 수집한다

화면 녹화

네트워크 트레이스 (HAR)

데스크톱 트레이스 (Fiddler)

3. 트레이스 읽기 — HTTP 응답 코드로 원인 좁히기

4. 진단 도구 박스

사서함·권한 (Exchange admin center)

️ 클라이언트 (클래식 Outlook)

인증·로그 수집

5. 에스컬레이션 — 아티팩트와 함께

마무리: 진단은 추측이 아니라 증명

test

[교육 8일차] Microsoft Purview Information Protection, eDiscovery and Audit Solutions

MICROSOFTPURVIEW

️Microsoft Purview 전체 구조

️Sensitivity Labels — 보안 정책의 집합

적용 대상 / Where Labels Apply

Message Encryption — 이메일 단위 보호

DLP — 데이터 유출 방지

보호 대상 민감 정보 유형

Audit — 행위 추적 로그

대표 활용 시나리오

eDiscovery — 실제 콘텐츠 조사

❓Q&A 핵심 복습

오늘 이후 처리 가능한 지원 시나리오

[교육 7일차]Exchange Online Retention, In-place archiving and Inactive Mailboxes​

Exchange Online데이터 거버넌스 &정보 보호 완전 정복

Table of Contents

Exchange Online 기본 개념 복습

핵심 관리 도구

Exchange 관리 센터 (EAC)

Exchange Online PowerShell

Microsoft Graph PowerShell

역할 기반 액세스 제어

Exchange Online DNS 레코드

사서함 유형 & 라이선스

사용자 사서함

리소스 사서함

공유 사서함

비활성 사서함

사서함 권한 (Delegation)

복구 가능 항목 폴더 (Recoverable Items)

삭제 단계 이해

️ 하위 폴더 구조

사서함 보존 Hold 유형

Litigation Hold (소송 보존)

eDiscovery Hold

Delay Hold (지연 보존)

Retention Hold (보존 일시정지)

PowerShell: Litigation Hold 설정

PowerShell: Hold 상태 종합 확인

보존 정책 & 보존 레이블 (Microsoft Purview)

⚖️ 보존 정책 vs 보존 레이블

보존 정책 설정 범위 유형

적응형 범위 (Adaptive)

정적 범위 (Static)

PowerShell: 보존 정책 확인

️ 보존 레이블 게시 프로세스

보관 사서함 (Archive Mailbox)

️ 보관 사서함 스펙 비교

PowerShell: 보관 사서함 관리

기본 보관 정책 (MRM 기본 태그)

⚡ 신규: 자동 보관 기능

레거시 보존 태그 & MRM (Messaging Records Management)

️ 보존 태그 유형

저널링 (Journaling)

⚙️ 저널링 설정 순서

오늘의 실습 체크리스트

✅ Today's Lab Tasks

[교육 6일차] Exchange Online

Exchange Online클라이언트 연결 완전 정복

Autodiscover — 연결의 시작

Autodiscover DNS 탐색 순서 (클래식 Outlook)

프로토콜 완전 비교

IMAP vs POP3 — 언제 어떤 걸 써야 하나?

▲ IMAP — 권장

MICROSOFT
PURVIEW

[교육 7일차]Exchange Online Retention, In-place archiving and Inactive Mailboxes

Exchange Online
데이터 거버넌스 &
정보 보호 완전 정복

Exchange Online
클라이언트 연결 완전 정복