공유 사서함으로 보낸 메일, 누가 답변했는지 확인할 수 있을까요?

최근 고객으로부터 공유 사서함 발송 권한에 관한 문의가 있었습니다.

"공유 사서함 권한자의 이름이 표시되도록 보낼 수 있나요?"

고객사는 여러 담당자가 하나의 공유 사서함으로 메일을 보내고 있었습니다. 수신자 화면에는 공유 사서함 이름만 표시됐고, 실제로 답변한 담당자의 이름은 보이지 않았습니다.

단순히 발신자 이름을 바꾸는 문제처럼 보이지만, 고객의 질문을 함께 살펴보면 더 중요한 고민으로 이어집니다.

"계약 조건이나 중요한 결정이 담긴 답변에 문제가 생기면, 누가 보냈는지 확인할 수 있을까요?"

이 질문에 대한 카이온아이티의 답변은 다음과 같습니다.

권한자의 이름을 수신자에게 보여주는 방법과, 문제가 발생했을 때 실제 발송자를 확인하는 방법은 서로 다릅니다.

• 권한자의 이름이 수신자에게 보여야 한다면 Send on Behalf(대신 보내기)를 검토합니다.
• 공유 사서함 이름만 보여야 한다면 Send As(다른 이름으로 보내기)를 사용합니다.
• Send As로 발송한 뒤 실제 발송 작업을 확인해야 한다면 Microsoft Purview 감사 로그를 점검합니다.
• 계약이나 중요한 결정이 담긴 메일이라면 감사 로그와 별도로 검토·승인 기록을 남겨야 합니다.

이번 글에서는 고객의 질문을 기준으로, 왜 발신 권한이 두 가지로 나뉘는지부터 실제 발송자 확인 범위, 감사 라이선스와 중요한 메일의 운영 기준까지 차례로 살펴보겠습니다.

Send As와 Send on Behalf는 무엇이 다른가요?

두 권한 모두 사용자가 공유 사서함 주소를 이용해 메일을 보낼 수 있게 합니다. 가장 큰 차이는 수신자에게 보이는 발신자입니다.¹

Full Access만 부여해서는 공유 사서함 이름으로 메일을 보낼 수 없습니다. 발송이 필요하다면 Send As 또는 Send on Behalf 권한을 별도로 부여해야 합니다.¹

또 하나의 주의점이 있습니다. 한 사용자에게 Send As와 Send on Behalf가 모두 부여되면 Microsoft는 Send As를 우선 사용합니다.¹ 담당자 이름을 보여주려는 운영 목적이 있다면 두 권한이 중복되어 있지 않은지 먼저 확인해야 합니다.

왜 발신 권한을 두 가지로 나눴을까요?

공유 사서함을 사용하는 목적이 조직마다 다르기 때문입니다.

고객센터, 채용 문의, 영업 대표 주소처럼 어느 담당자가 응답해도 하나의 조직 이름으로 보여야 하는 업무가 있습니다. 이런 환경에서는 Send As가 자연스럽습니다.

반대로 견적 확정, 계약 조건, 승인 결과처럼 누가 답변했는지 상대방에게도 보여야 하는 업무가 있습니다. 이때는 Send on Behalf가 책임 관계를 더 분명하게 보여줍니다.

따라서 선택 기준은 단순히 “메일이 발송되는가”가 아닙니다.

대표성을 우선할 것인가, 담당자의 가시성을 우선할 것인가를 먼저 정해야 합니다.

공유 사서함 자체가 필요한 이유와 사용자 메일함과의 차이는 공용 메일함과 개인 메일함은 언제 구분해야 할까?에서 함께 확인할 수 있습니다.

Send As로 보냈다면 실제 발송자를 확인할 수 없나요?

수신자는 Send As 메일에서 실제 권한자의 이름을 볼 수 없습니다. 하지만 조직 내부에서는 조건이 갖춰져 있다면 Microsoft Purview 감사에서 SendAs 또는 SendOnBehalf 활동을 조사할 수 있습니다.²

공유 사서함 감사 검색에서는 다음 정보가 중요합니다.

• 문제가 발생한 날짜와 시간 범위
• 공유 사서함의 기본 SMTP 주소 또는 Exchange GUID
• 확인할 활동인 SendAs 또는 SendOnBehalf
• 감사 검색을 수행할 관리자의 권한

Microsoft는 공유 사서함을 조사할 때 사용자 필드가 아니라 Keywords 필드에 공유 사서함의 SMTP 주소 또는 Exchange GUID를 입력하도록 안내합니다. 감사 시간은 UTC 기준이므로 한국 시간과의 차이도 고려해야 합니다.³

검색 결과는 어떤 계정이 해당 발송 작업을 수행했는지 조사하는 근거가 될 수 있습니다. 다만 이것만으로 메일 내용이 내부 승인을 받았는지, 계약상 권한을 가진 사람이 결정했는지까지 증명되는 것은 아닙니다.

감사 로그는 발송 작업의 추적 기록이지, 업무 승인 절차를 대신하는 기록은 아닙니다.

공유 사서함 감사는 기본으로 켜져 있나요?

Exchange Online의 공유 사서함은 사서함 감사가 지원되며 기본 감사 대상입니다.² 그러나 “기본으로 켜져 있다”는 표현을 “모든 행동이 언제나 기록된다”는 뜻으로 이해하면 안 됩니다.

실제 기록 범위는 다음 조건에 따라 달라질 수 있습니다.

• 조사하려는 작업이 해당 로그인 유형의 감사 대상인가
• 사서함의 기본 감사 작업 집합이 변경되지 않았는가
• 조직의 감사가 비활성화되지 않았는가
• 검색하려는 기간의 로그가 아직 보존되어 있는가
• 검색 담당자에게 필요한 역할이 있는가

관리자는 Exchange Online PowerShell에서 다음 항목을 점검할 수 있습니다.²

• 기본 감사 작업 집합: Get-Mailbox -Identity <공유사서함> | Format-List DefaultAuditSet
• 위임 사용자 감사 항목: Get-Mailbox -Identity <공유사서함> | Select-Object -ExpandProperty AuditDelegate

DefaultAuditSet이 Admin, Delegate, Owner로 표시되면 해당 사서함에 기본 감사 작업 집합이 적용된 상태입니다. 별도로 감사 항목을 수정했던 환경이라면 현재 설정을 확인한 뒤 판단해야 합니다.

감사 로그 검색에는 View-Only Audit Logs 또는 Audit Logs 역할도 필요합니다.³ 일반 사용자가 Outlook에서 바로 확인하는 기능은 아닙니다.

Exchange Online 라이선스만 있으면 감사도 사용할 수 있나요?

이 질문은 공유 사서함을 사용하는 라이선스와 Microsoft Purview 감사를 사용하는 라이선스로 나누어 확인해야 합니다.

공유 사서함 자체는 일반적으로 50GB 이하에서 별도 라이선스 없이 사용할 수 있지만, 공유 사서함에 접근하는 각 사용자는 Exchange Online이 포함된 라이선스가 필요합니다. 50GB 초과, 보관 사서함 또는 소송 보존 같은 기능에는 추가 라이선스 조건이 적용될 수 있습니다.⁵

Microsoft Purview Audit Standard는 이를 지원하는 Microsoft 365 또는 Office 365 구독에서 사용할 수 있고, 기본 감사 로그는 현재 최대 180일 동안 보존됩니다.⁴ 검색 도구를 사용하려면 관리 역할도 별도로 부여되어 있어야 합니다.

1년 보존, 사용자 지정 감사 보존 정책 또는 고급 조사 기능이 필요하다면 Audit Premium 사용 권한을 검토해야 합니다. 10년 보존에는 별도 추가 기능이 필요합니다.⁴

따라서 “Exchange Online 구독이 있으니 필요한 감사 기능을 모두 사용할 수 있다”라고 일괄 판단해서는 안 됩니다. 현재 테넌트의 구독, 조사 대상 사용자, 필요한 보존 기간과 기능을 기준으로 확인해야 합니다.

보낸 편지함에도 기록을 남겨야 합니다

공유 사서함으로 보낸 메일이 항상 공유 사서함의 보낸 편지함에 저장되는 것은 아닙니다. 기본 동작에서는 권한자의 보낸 편지함에만 남아 공동 업무 이력을 확인하기 어려운 경우가 있습니다.⁶

관리자는 Exchange PowerShell에서 발신 방식에 맞는 사본 저장 설정을 사용할 수 있습니다.

• Send As 사본 저장: Set-Mailbox <공유사서함> -MessageCopyForSentAsEnabled $True
• Send on Behalf 사본 저장: Set-Mailbox <공유사서함> -MessageCopyForSendOnBehalfEnabled $True

이 설정은 공유 사서함의 보낸 편지함에 발송 사본을 남겨 담당자들이 응답 이력을 함께 확인하는 데 도움이 됩니다.⁶

그러나 보낸 편지함 사본도 감사 로그와 역할이 다릅니다. 메일 내용을 공동으로 확인하는 운영 기록에는 유용하지만, 누가 어떤 권한으로 발송 작업을 수행했는지 조사할 때는 감사 기록을 함께 봐야 합니다.

중요한 계약이나 결정 메일은 어떻게 운영해야 할까요?

문제가 생긴 뒤 감사 로그만 찾는 방식으로는 충분하지 않습니다. 계약, 가격 확정, 납기 변경 또는 공식 승인처럼 영향이 큰 메일은 발송 전에 책임 구조가 보여야 합니다.

카이온아이티는 다음 항목을 함께 검토할 것을 권장합니다.

1. 공유 사서함의 용도를 구분합니다. 일반 문의와 계약·승인 메일을 같은 규칙으로 처리하지 않습니다.
2. 발신 권한을 업무 목적에 맞춥니다. 담당자 표시가 필요하면 Send on Behalf를 검토하고, 대표 발송이 필요하면 Send As와 내부 추적 절차를 함께 둡니다.
3. 두 발신 권한의 중복을 제거합니다. Send As가 우선 적용되어 의도와 다르게 개인 이름이 숨겨질 수 있습니다.
4. 공유 보낸 편지함에 사본을 남깁니다. 담당자들이 이전 답변과 약속 내용을 확인할 수 있어야 합니다.
5. 중요한 답변은 승인 기록을 별도로 남깁니다. 결재, 티켓, CRM 또는 업무 시스템에서 승인자와 승인 내용을 기록합니다.
6. 권한을 최소화하고 정기적으로 점검합니다. 부서 이동자와 퇴사자의 권한을 즉시 회수합니다.
7. 업무 중요도에 맞는 보존 기간을 정합니다. 기본 감사 보존 기간보다 긴 확인이 필요하다면 라이선스와 보존 정책을 사전에 검토합니다.

특히 상대방에게도 담당자의 이름이 보여야 하는 업무라면 감사 로그에만 기대지 말고 Send on Behalf 또는 개인 명의의 승인 메일처럼 발송 시점부터 책임 관계가 드러나는 방식을 선택하는 것이 안전합니다.

관리자가 확인할 체크리스트

• 사용자별 Full Access, Send As, Send on Behalf 권한을 구분했는가
• 한 사용자에게 Send As와 Send on Behalf가 중복 부여되지 않았는가
• 실제 수신자 화면에서 의도한 발신자 표시를 확인했는가
• 공유 사서함의 보낸 편지함에 발송 사본이 남는가
• DefaultAuditSet과 AuditDelegate가 예상한 상태인가
• 감사 검색 담당자에게 필요한 역할이 있는가
• 현재 구독에서 필요한 감사 기능과 보존 기간을 사용할 수 있는가
• 계약·승인 메일에 별도의 검토와 승인 기록이 있는가

정리하기

공유 사서함에서 개인 이름을 수신자에게 보여주고 싶다면 Send on Behalf를 검토해야 합니다. 공유 사서함 이름만 보여주려면 Send As가 적합하지만, 문제가 생겼을 때를 대비해 감사와 보낸 편지함 정책을 함께 운영해야 합니다.

중요한 것은 세 기능의 역할을 섞지 않는 것입니다.

• Send As / Send on Behalf: 수신자에게 누가 보이게 할 것인가
• 보낸 편지함 사본: 조직이 어떤 답변을 보냈는지 공동으로 확인
• 감사 로그: 어떤 계정이 발송 작업을 수행했는지 사후 조사

고객의 질문은 발신자 이름에서 시작했지만, 카이온아이티의 답변은 책임성, 감사, 라이선스와 보존 정책까지 함께 살펴보는 것이었습니다.

공유 사서함의 권한과 감사 범위가 현재 업무 방식에 맞는지 판단하기 어렵다면 카이온아이티 Microsoft 365 기술지원 상담에서 실제 환경을 기준으로 점검 범위를 상담할 수 있습니다.

이 글은 카이온아이티가 실제 기술지원으로 확인한 문의를 바탕으로, 고객사와 담당자를 식별할 수 없도록 내용을 재구성했습니다.

참고 자료

1. Manage permissions for recipients in Exchange Online — Microsoft Learn, 2026-07-29 확인
2. Manage mailbox auditing — Microsoft Learn, 2026-07-29 확인
3. Search the audit log for mailbox activities in specific mailboxes — Microsoft Learn, 2026-07-29 확인
4. Learn about auditing solutions in Microsoft Purview — Microsoft Learn, 2026-07-29 확인
5. About shared mailboxes in Microsoft 365 — Microsoft Learn, 2026-07-29 확인
6. Messages sent from a shared mailbox aren't saved to the Sent Items folder — Microsoft Learn, 2026-07-29 확인