Microsoft는 등록된 도메인에서 이메일 인증 프로토콜을 채택할 수 있는 Office 365 사용자를 위한 DMARC를 지원 및 권장합니다. 을 만장일치로 채택할 수 있도록 지원합니다. 이 블로그에서는 Office 365용 DMARC를 구성하여 모든 Office 365 전자 메일의 유효성을 검사하는 프로세스에 대해 설명합니다:
- Microsoft의 온라인 이메일 라우팅 주소
- 관리 센터에 사용자 정의 도메인 추가
- 파킹 또는 비활성 상태이지만 등록된 도메인
2023년 2분기에 Microsoft는 다양한 출처에서 피싱 사기에 가장 많이 사칭된 브랜드로 선정되었습니다. DMARC와 같은 프로토콜은 방어 메커니즘을 강화하는 데 필수적입니다.
주요 내용
- 도메인 스푸핑 및 피싱에 대한 이메일 보안을 강화하려면 DMARC가 필수입니다.
- DMARC를 설정하려면 이메일 인증을 위한 기존 SPF 또는 DKIM 레코드가 필요합니다.
- Microsoft 365는 인바운드 DMARC 실패를 다르게 처리하며, 엄격한 적용(격리/거부)을 위해 전송 규칙을 사용합니다.
- 합법적인 메일이 차단되지 않도록 보고서를 모니터링하면서 DMARC 정책의 엄격성(거부할 항목 없음)을 점진적으로 높이세요.
- 비활성 도메인에 대해서도 DMARC를 구성하여 무단 사용을 방지하세요.
Office 365에서 DMARC를 사용하여 정교한 전자 메일 위협을 방지하는 방법을 알아보세요.
Office 365용 DMARC를 구성하는 방법
DMARC 또는 도메인 기반 메시지 인증, 보고 및 적합성은 도메인의 DNS에 TXT 레코드로 존재합니다. DMARC는 내 도메인에서 발생하는 이메일 기반 위협에 대한 1차 방어 역할을 합니다. DMARC를 구성하기 전에 고급 보호를 위해 도메인에 SPF 또는 DKIM 또는 둘 다에 대한 레코드가 포함되어 있어야 합니다.
사용자 정의 도메인을 사용하는 경우 DMARC 레코드를 만드는 단계는 다음과 같습니다. DMARC를 구현하기 위해 SPF와 DKIM을 모두 구성해야 하는 것은 아닙니다. 그러나 추가 보호 계층을 추가하는 것이 좋습니다.
PowerDMARC로 Office 365용 DMARC를 간소화하세요!
시작하기 전에 고려해야 할 사항
에 따르면 Microsoft의 문서:
- onmicrosoft.com으로 끝나는 MOERA(Microsoft 온라인 이메일 라우팅 주소)를 사용하는 경우 SPF 및 DKIM이 이미 구성되어 있을 것입니다. 하지만 Microsoft 365 관리 센터를 사용하여 DMARC 레코드를 만들어야 합니다.
- example.com과 같은 사용자 정의 도메인을 사용하는 경우 도메인에 대한 SPF, DKIM 및 DMARC를 수동으로 구성해야 합니다.
- 파킹된 도메인(비활성 도메인)의 경우 Microsoft는 해당 도메인에서 이메일을 보내지 않도록 명시적으로 지정할 것을 권장합니다. 그렇지 않으면 이러한 도메인이 스푸핑 및 피싱 공격에 사용될 수 있습니다.
- 전송 중 전달되거나 수정된 메시지의 경우 반드시 ARC. 이렇게 하면 이메일 인증 헤더가 수정되더라도 원본 이메일 인증 헤더를 보존하여 정확한 인증을 수행할 수 있습니다.
1단계: 도메인에 유효한 이메일 소스 확인
이는 사용자를 대신하여 이메일을 보내도록 허용하려는 소스 IP 주소(타사 포함)입니다.
2단계: 도메인에 SPF 설정하기
이제 다음을 구성해야 합니다. SPF 를 구성해야 합니다. 이렇게 하려면 외부 이메일 공급업체를 포함한 모든 유효한 발신 소스를 포함하는 SPF TXT 레코드를 만드세요. PowerDMARC에 무료로 가입하고 SPF 레코드 생성 도구를 사용하여 레코드를 만들 수 있습니다.
3단계: 도메인에서 Office 365용 DKIM 설정하기
DMARC Office 365를 사용하려면 도메인에 대해 SPF 또는 DKIM이 구성되어 있어야 합니다. 설정하는 것이 좋습니다. DKIM 및 Office 365에서 DMARC를 설정하여 도메인의 이메일에 대한 보안 계층을 추가하는 것이 좋습니다. PowerDMARC에 무료로 가입하고 DKIM 레코드 생성 도구를 사용하여 레코드를 만들 수 있습니다.
4단계: DMARC TXT 레코드 만들기
PowerDMARC의 무료 DMARC 레코드 생성기 를 사용할 수 있습니다. 올바른 구문으로 레코드를 즉시 생성하여 DNS에 게시하고 도메인에 대한 DMARC를 구성하세요!
시행 정책은 거부 정책만 효과적으로 사칭 공격을 방지할 수 있습니다. 먼저 없음 정책으로 시작하여 이메일 트래픽을 정기적으로 모니터링하는 것이 좋습니다. 일정 기간 동안 이렇게 한 후 최종적으로 적용으로 전환하세요. 발신 소스를 제대로 구성하거나 모니터링하지 않으면 합법적인 이메일이 손실될 수 있으므로 DMARC 거부를 가볍게 생각해서는 안 됩니다.
DMARC 기록의 경우 정책 모드(없음/검역/거부)를 정의하고, DMARC 집계 보고서를 받으려면 'rua' 필드에 이메일 주소를 입력합니다.
DMARC 정책 | 정책 유형 | 구문 | 액션 |
---|---|---|---|
없음 | 편안한/무조치/허용적 | p=없음; | 인증에 실패한 메시지에 대해서는 아무런 조치도 취하지 않습니다(즉, 메시지를 전달하지 않습니다). |
격리 | 시행 | p=검역; | DMARC에 실패한 격리 메시지 |
거부 | 시행 | p=거부; | DMARC에 실패한 메시지 삭제 |
DMARC 레코드 구문은 다음과 같습니다:
v=DMARC1; p=reject; rua=mailto:[email protected];
이 레코드에는 "거부" 정책이 적용되어 있으며 도메인에 대해 DMARC 집계 보고가 활성화되어 있습니다.
Microsoft 관리 센터를 사용하여 Office 365 DMARC 레코드를 추가하는 단계
다음에 대한 DMARC Office 365 레코드를 추가하려면 MOERA 도메인(*온마이크로소프트.com 도메인)을 클릭한 다음 단계를 따르세요:
1. Microsoft 관리 센터에 로그인합니다.
2. 2. 모두 보기 > 설정 > 도메인
3. 도메인 페이지의 도메인 목록에서 *onmicrosoft.com 도메인을 선택하여 도메인 세부 정보 페이지를 엽니다.
4. 이 페이지에서 DNS 레코드 탭을 클릭하고 + 레코드 추가를 선택합니다.
5. 다양한 필드가 있는 새 DMARC 레코드를 추가할 수 있는 텍스트 상자가 나타납니다. 아래는 특정 필드에 입력해야 하는 값입니다:
유형: TXT
이름: _dmarc
TTL: 1 시간
Value: (생성한 DMARC 레코드의 값 붙여넣기)
6. 저장을 클릭합니다.
사용자 지정 도메인에 Office 365 DMARC 레코드 추가하기
example.com과 같은 사용자 정의 도메인을 사용하는 경우 다음과 같은 자세한 가이드를 참조하세요. DMARC 설정 방법. 가이드의 단계에 따라 프로토콜을 쉽게 구성할 수 있습니다. Microsoft는 사용자 지정 도메인에 대해 DMARC를 구성하는 동안 몇 가지 유용한 권장 사항을 제공합니다. 저희도 이러한 팁에 동의하며 고객에게도 이를 제안합니다! 그 내용을 살펴보겠습니다:
- DMARC를 구성할 때는 없음 정책으로 시작하세요.
- 천천히 격리로 전환한 다음 거부하기
- 정책 영향력에 대한 백분율(%) 값을 10에서 시작하여 천천히 100까지 늘려서 낮은 값을 유지할 수도 있습니다.
- 이메일 채널을 정기적으로 모니터링하려면 DMARC 보고를 사용하도록 설정하세요.
비활성 도메인에 대한 DMARC Office 365 레코드 추가하기
다음에 대한 자세한 가이드를 다루었습니다. 비활성/파킹된 도메인을 보호하는 방법 비활성/주차 도메인을 보호하는 방법에 대한 자세한 가이드를 다루었습니다. 여기에서 자세한 단계를 살펴볼 수 있지만 간략하게 요약하자면 비활성 도메인의 경우에도 DMARC를 구성해야 합니다.
비활성 도메인에 대한 DNS 관리 콘솔에 액세스하여 DMARC 레코드를 게시하기만 하면 됩니다. DNS에 액세스할 수 없는 경우 지금 바로 DNS 공급업체에 문의하세요. 이 레코드는 DMARC에 실패하는 비활성 도메인에서 보내는 모든 메시지를 거부하도록 구성할 수 있습니다:
v=DMARC1; p=거부;
PowerDMARC로 Office 365용 DMARC를 올바른 방식으로 구성하세요!
Office 365에 DMARC를 구성하는 이유는 무엇인가요?
Office 365에는 스팸 방지 솔루션과 이메일 보안 게이트웨이가 이미 보안 제품군에 통합되어 있습니다. 그렇다면 Office 365에서 인증을 위해 DMARC 정책이 필요한 이유는 무엇일까요? 그 이유는 이러한 솔루션이 주로 인바운드 피싱 이메일 인바운드 피싱 이메일을 방지하기 때문입니다. DMARC 인증 프로토콜은 아웃바운드 피싱 방지 솔루션입니다. 도메인 소유자는 도메인에서 보낸 이메일 중 인증에 실패한 이메일에 응답하는 방법을 수신 메일 서버에 지정할 수 있습니다. 또한 DMARC는 정상적인 메시지가 스팸 폴더에 도착할 위험도 줄여줍니다. DMARC는 주로 직접 도메인 스푸핑(정확한 도메인 이름 사용)을 방지하며 유사 도메인 스푸핑(시각적으로 유사한 도메인 이름 사용)은 본질적으로 방지하지 못한다는 점에 유의해야 합니다.
DMARC는 두 가지 표준 인증 방식, 즉 SPF와 DKIM을 사용합니다. 이를 통해 전자 메일의 진위 여부를 확인합니다. Office 365 DMARC 정책을 적용하면 사칭 공격 및 스푸핑에 대한 보호 기능을 강화할 수 있습니다.
현재 상황에서 비즈니스 이메일에 DMARC를 설정하는 것이 그 어느 때보다 중요한 이유는 다음과 같습니다:
- 연방 기관들은 해커들이 부재하거나 취약한 취약한 DMARC 정책
- DMARC 규정 준수는 다음 경우에 필수입니다. 야후 및 구글 대량 발신자
- 그리고 FBI의 IC3 보고서 는 피싱 공격의 가장 큰 피해 국가로 미국을 지목했습니다.
- IBM 보고서 5개 기업 중 1개 기업이 자격 증명 분실 또는 도난으로 인한 데이터 유출의 영향을 받는다고 합니다.
Office 365를 사용하면서 DMARC가 정말 필요한가요?
기업들 사이에서 흔히 오해하는 것이 있는데, 바로 Office 365가 스팸 및 사기성 전자 메일로부터 안전을 보장한다고 생각하는 것입니다. 하지만 2020년 5월에 일련의 피싱 공격 피싱 공격이 여러 중동 보험 회사를 대상으로 수행되었습니다. 공격자들은 Office 365를 사용하여 상당한 데이터 손실과 보안 침해를 일으켰습니다. 이를 통해 얻은 교훈은 다음과 같습니다:
이유 1: Microsoft의 보안 솔루션은 완벽하지 않습니다.
그렇기 때문에 단순히 Microsoft의 통합 보안 솔루션에 의존하는 것만으로는 충분하지 않습니다. 도메인을 보호하기 위해 외부에서 노력해야 하는 것은 큰 실수가 될 수 있습니다.
이유 2: 아웃바운드 공격으로부터 보호하려면 Office 365용 DMARC를 구성해야 합니다.
Office 365의 통합 보안 솔루션은 인바운드 전자 메일 위협 및 피싱 시도로부터 보호할 수 있지만, 자체 도메인에서 보낸 아웃바운드 메시지가 고객 및 파트너의 받은 편지함에 도착하기 전에 효과적으로 인증되도록 해야 합니다. 이것이 바로 Office 365용 DMARC가 필요한 이유입니다.
이유 3: DMARC는 이메일 채널을 모니터링하는 데 도움이 됩니다.
DMARC는 직접적인 도메인 스푸핑 및 피싱 공격으로부터 도메인을 보호할 뿐만 아니라 이메일 채널도 보호합니다. 또한 이메일 채널을 모니터링하는 데도 도움이 됩니다. "거부/검역"과 같은 강제 정책을 사용하든, "없음"과 같은 보다 관대한 정책을 사용하든, 다음을 통해 인증 결과를 추적할 수 있습니다. DMARC 보고서. 이러한 보고서는 이메일 주소로 전송되거나 DMARC 보고서 분석기 도구로 전송됩니다. 모니터링을 통해 합법적인 이메일이 성공적으로 전달되는지 확인할 수 있습니다.
Office 365에서 DMARC는 어떻게 작동하나요?
Office 365에서 DMARC를 구현하려면 도메인 소유자가 DNS 설정에 DMARC 레코드를 게시해야 합니다. 이 레코드는 수신 메일 서버에 지정된 정책(없음, 격리 또는 거부)에 따라 도메인에서 보낸 것으로 주장하지만 SPF 또는 DKIM 검사에 실패한 이메일을 처리하는 방법을 알려줍니다. 정책을 'p=거부'로 설정하여 수신 서버에서 스푸핑된 Office 365 이메일을 거부하도록 구성할 수 있습니다.
Office 365 관리자는 Exchange 관리 센터 또는 PowerShell 명령을 통해 DMARC 설정을 관리할 수 있습니다.
또한 Office 365에서 DMARC를 구현하여 타사에서 도메인의 이메일을 처리하는 방식과 인증 검사에 대한 성능에 대한 집계(RUA) 및 포렌식(RUF) 보고서를 요청할 수도 있습니다.
Microsoft 365에서 DMARC에 실패한 인바운드 이메일을 처리하는 방법
이해해야 할 중요한 점은 *발신자의* DMARC 정책에 지정된 DMARC 검사에 실패한 인바운드 이메일을 Microsoft 365에서 처리하는 방식입니다. 기본적으로 발신자의 DMARC 정책이 "p=거부"로 설정되어 있어도 DMARC에 실패한 Microsoft 365 인바운드 이메일은 자동으로 거부되지 않습니다.
Microsoft 365는 주로 합법적인 이메일을 차단(오탐)하지 않기 위해 이 접근 방식을 사용합니다. 이는 다음과 같은 이유로 발생할 수 있습니다:
- 이메일 전달 시나리오 또는 메일링 리스트가 SPF 및 DKIM 정렬을 깨뜨릴 수 있습니다.
- 발신자 측의 구성 문제 또는 불완전한 롤아웃.
Microsoft 365 전자 메일 보안은 일반적으로 이러한 메시지를 거부하는 대신 스팸으로 표시합니다. 이렇게 하면 합법적인 메일의 잠재적 손실을 방지할 수 있지만, p=거부 정책으로 도메인을 스푸핑하는 악성 이메일이 완전히 차단되지 않고 사용자의 정크 메일 폴더에 도달할 수 있습니다. 또한 사용자가 발신자를 '안전 발신자' 목록에 추가하여 실수로 이 정책을 우회할 수도 있습니다.
전송 규칙을 사용하여 인바운드 메일에 DMARC 적용하기
DMARC 검사에 실패한 인바운드 이메일을 보다 엄격하게 제어하려면 Exchange Online 관리 센터에서 Exchange 메일 흐름 규칙(전송 규칙)을 만들 수 있습니다. 이러한 규칙을 사용하면 기본 동작을 재정의하여 DMARC 실패에 따른 특정 동작을 정의할 수 있습니다. 발신자가 내부 또는 외부인지 여부에 따라 이러한 규칙을 대상으로 지정할 수 있습니다.
다음은 DMARC 적용을 위한 전송 규칙을 만드는 일반적인 프로세스입니다:
- Exchange 온라인 관리 센터에 로그인합니다.
- 로 이동합니다. 메일 흐름 > 규칙.
- 클릭 + 규칙 추가 을 클릭하고 새 규칙 만들기.
- 규칙에 이름을 지정합니다(예: "DMARC 실패 - 내부 스푸핑 검역", "DMARC 실패 - 외부 거부").
- "다음과 같은 경우 이 규칙을 적용하세요.", "메시지 헤더..." 다음 "에는 다음 단어가 포함됩니다.".
- "텍스트 입력..."를 클릭하고 헤더 이름을 지정합니다: 인증 결과
- 클릭 "단어 입력..."를 클릭하고 문구를 추가합니다: dmarc=실패
- 원하는 경우 다른 조건을 추가하여 발신자의 위치를 지정할 수 있습니다:
- 내 도메인의 스푸핑을 대상으로 합니다: 조건 추가 "발신자..." > "도메인은..."를 추가하고 내부 도메인을 입력합니다. "메시지에서 발신자 주소 일치"를 "헤더"로 설정합니다.
- DMARC에 실패한 외부 도메인을 대상으로 하려면: 조건 추가 "발신자..." > "는 외부/내부" > "조직 외부".
- "다음 작업을 수행합니다..."를 클릭하고 원하는 작업을 선택합니다:
- 격리: "메시지 속성 수정..." > "스팸 신뢰 수준(SCL)을 설정합니다."을 9로 설정하거나 "호스팅된 검역소로 메시지 전달"를 사용하세요.) 내부 스푸핑이 의심되는 경우에 자주 사용됩니다.
- 면책 조항을 추가합니다: " 선택메시지에 면책 조항 적용..." > "면책 조항 추가". 경고 텍스트를 추가합니다(예: "주의: 이 이메일은 DMARC 인증에 실패했으며 사기성일 수 있습니다."). 사용자에게 경고하고 싶지만 잘못 구성되었을 가능성이 있는 정상 메일은 차단하지 않으려는 외부 도메인 장애에 유용합니다.
- 거부합니다: " 선택메시지 차단..." > "메시지를 거부하고 설명 포함" 또는 "아무에게도 알리지 않고 메시지 삭제". 이것은 가장 엄격한 옵션입니다.
- 필요한 경우 예외를 구성합니다(예: 규칙을 우회해야 하는 특정 발신자 IP 또는 도메인).
- 설정을 검토하고 저장. 규칙을 활성화합니다.
참고: 메일을 격리하거나 거부하는 규칙을 적용하기 전에 처음에는 '정책 팁 없이 테스트' 모드에서 또는 제한된 사용자 그룹을 대상으로 철저히 테스트하는 것이 좋습니다. 합법적인 이메일이 의도치 않게 차단되는 일이 없도록 승인된 발신자가 DMARC 검사를 올바르게 통과하는지 확인하세요.
Office 365에서 DMARC 정책을 사용하도록 설정하지 않으면 어떻게 되나요?
Office 365 도메인에 대한 DMARC 레코드를 게시하지 않거나 모니터링 없이 'p=none'의 정책으로 게시하는 경우 도메인이 스푸핑될 위험이 상당히 높습니다.
DMARC는 이메일 시스템에 액세스하여 사기나 피싱에 사용하려는 이메일 발신자가 도메인을 스푸핑하지 못하도록 보호하도록 설계되었습니다.
DMARC 레코드가 없으면 수신 메일 서버는 내 도메인에서 보낸 것으로 주장하는 이메일을 확인하는 방법이나 확인에 실패할 경우 어떻게 해야 하는지에 대한 지침을 받지 못합니다. 'p=없음' 정책을 사용하는 경우 실패한 이메일이 계속 전달되므로 스푸핑에 대한 보호 기능이 제공되지 않습니다(보고를 통해 가시성을 제공할 수는 있지만). 즉, 권한이 없더라도 누구나 도메인을 대신하여 이메일을 보내려고 시도할 수 있습니다. 또한 수신자가 도메인과 관련된 인증된 출처에서 진짜로 보낸 메시지인지 확인하기가 더 어려워집니다.
도메인 소유자는 도메인 스푸핑 공격과 피싱 공격을 통해 도메인 또는 브랜드 네임을 악의적인 활동에 사용하는 위협 행위자를 항상 경계해야 합니다. 어떤 이메일 교환 솔루션을 사용하든 스푸핑 및 사칭으로부터 도메인을 보호하는 것은 브랜드 신뢰도를 보장하고 소중한 고객층 사이에서 신뢰를 유지하는 데 필수적입니다.
Office 365에서 PowerDMARC를 사용하는 이유는 무엇인가요?
Microsoft Office 365는 사용자에게 통합 스팸 방지 필터와 함께 다양한 클라우드 기반 서비스 및 솔루션을 제공합니다. 하지만 다양한 장점에도 불구하고 보안 관점에서 보면 다음과 같은 단점도 있습니다:
- 도메인에서 보낸 아웃바운드 메시지의 유효성을 검사하는 솔루션이 없습니다(수동 SPF/DKIM/DMARC 설정 필요).
- 인증 검사에 실패한 이메일에 대한 사용자 친화적인 보고 메커니즘이 내장되어 있지 않습니다(원시 XML 보고서는 구문 분석이 필요함).
- 전체 이메일 에코시스템 및 인증 태세에 대한 가시성 제한
- 여러 도메인에 걸쳐 DMARC 배포를 관리하고 모니터링할 수 있는 중앙 집중식 대시보드가 없습니다.
- SPF 레코드가 조회 제한 10개 미만으로 유지되도록 하는 자동화된 메커니즘이 없습니다(수동 관리 또는 SPF 평탄화와 같은 도구가 필요함).
PowerDMARC를 사용한 DMARC 보고 및 모니터링
PowerDMARC는 Office 365와 원활하게 통합되어 도메인 소유자에게 BEC 및 직접 도메인 스푸핑과 같은 정교한 소셜 엔지니어링 공격으로부터 보호하는 고급 인증 솔루션을 제공합니다.
PowerDMARC에 가입하면 모든 이메일 인증 모범 사례(SPF, DKIM, DMARC)를 조합하는 멀티테넌트 SaaS 플랫폼에 가입하는 것입니다, MTA-STS, TLS-RPT 및 BIMI) 뿐만 아니라 이메일 에코시스템에 대한 완벽한 가시성을 제공하는 광범위하고 심층적인 dmarc 보고 메커니즘도 제공합니다. DMARC 보고서 는 두 가지 형식으로 생성됩니다:
- 집계 보고서(RUA)
- 포렌식 보고서(RUF - 리포터가 활성화하고 지원하는 경우)
저희는 다양한 업계 문제를 해결하여 더 나은 인증 경험을 제공하기 위해 노력해 왔습니다. 저희는 사용자 경험과 명확성을 향상시키기 위해 DMARC 포렌식 보고서의 암호화를 보장하고 집계 보고서를 7가지 보기로 표시합니다.
이메일 흐름과 인증 실패를 모니터링하는 데 도움이 되는 PowerDMARC와 블랙리스트 전 세계의 악성 IP 주소를 차단할 수 있습니다. 당사의 DMARC 분석기 는 도메인에 맞게 DMARC를 올바르게 구성하고 모니터링에서 시행으로 즉시 전환할 수 있도록 도와줍니다. 이를 통해 복잡한 설정에 대한 걱정 없이 DMARC Office 365를 사용할 수 있습니다.
Office 365용 DMARC FAQ
콘텐츠 검토 및 사실 확인 프로세스
Office 365 DMARC 설정 프로세스에 대한 정보는 주로 Microsoft 공식 문서와 실제 경험을 바탕으로 작성되었습니다. 이 문서는 Microsoft에서 업데이트할 수 있습니다. 전송 규칙 사용 및 점진적인 정책 롤아웃을 포함하여 이 문서에 언급된 권장 사항은 업계 모범 사례와 실제 고객 경험을 기반으로 합니다.
"`
- DKIM 도메인 정렬 실패 - RFC 5322 수정 사항 - 2025년 6월 5일
- DMARCbis 설명 - 변화하는 사항과 준비 방법 - 5월 19, 2025
- BIMI란 무엇인가요? BIMI 로고 요구 사항 및 설정에 대한 완벽한 가이드 - 2025년 4월 21일