Microsoft 365의 전자 메일 인증을 위한 보안 운영 가이드

Email 인증은 organization 통신을 보호하는 중요한 구성 요소입니다. Microsoft 365에서 전자 메일을 받으면 서비스에서 인증 결과 헤더를 추가합니다. 이 헤더는 SPF, DKIM, DMARC 및 복합 인증(compauth)을 비롯한 다양한 전자 메일 인증 검사의 결과를 보여 줍니다.

이 가이드에서는 이러한 결과로 발생할 수 있는 일반적인 시나리오에 대해 설명합니다.

• 메시지가 전자 메일 인증을 통과하거나 실패한 이유입니다.
• 전자 메일 원본 또는 전자 메일 대상이 결과에 대한 책임이 있는지 여부입니다.
• 전자 메일 인증 결과를 개선하는 데 권장되는 작업(있는 경우)입니다.

하지만 먼저 다음 표에 설명된 몇 가지 정의가 있습니다.

Email 인증 통과 시나리오

이러한 시나리오에서는 전자 메일 인증 검사를 통과 했거나 수락된 메시지(특정 구성으로 인해)에 대해 설명합니다. 일반적으로 전자 메일 인증이 통과되면 수정 작업이 필요하지 않습니다. 그러나 일부 시나리오에는 보안을 강화하기 위해 구성 개선 사항을 권장하는 주의 사항이 포함되어 있습니다.

발신자는 원본 organization 관리자를 참조합니다. 받는 사람은 대상 organization 관리자를 참조합니다.

통과된 모든 인증 검사

• 헤더 예제: dmarc=pass (및 일반적으로 spf=pass 및 dkim=pass).
• 의미: 모든 전자 메일 인증 검사(SPF, DKIM 및 DMARC) 가 성공했습니다. 이 결과는 표준 이메일 인증 프로토콜에 따라 메시지가 완전히 인증되었음을 나타냅니다.
• 책임 있는 사람: 보낸 사람입니다.
• 권장 작업: 없음. Email 인증이 올바르게 구성되고 의도한 대로 작동합니다. 받는 사람은 이 메시지를 올바르게 인증한 보낸 사람 도메인을 신뢰할 수 있습니다.

통과된 복합 인증

• 헤더 예제: compauth=pass (복합 인증 통과).

• 의미: 메시지가 Microsoft 365 복합 인증을 통과했습니다.

  • DMARC 요구 사항이 충족되었습니다. SPF 또는 DKIM이 전달 되고 MAIL FROM 및 From 주소가 정렬됩니다.

    또는

  • Microsoft의 암시적 신뢰 논리는 메시지를 합법적인 것으로 식별했습니다. 예를 들어 메시지는 Microsoft의 안전한 보낸 사람 기록 또는 보낸 사람의 신뢰를 나타내는 스푸핑 인텔리전스 를 기반으로 복합 인증을 전달할 수 있습니다.

• 책임 있는 사람: 보낸 사람입니다.

• 권장 작업: 없음. 인증 검사가 성공했고 시스템에서 문제를 감지하지 못했습니다. 이 시나리오에서는 SPF 또는 DKIM을 변경할 필요가 없습니다.

DMARC 정책 없이 DMARC 통과(DMARC 레코드 없음)

• 헤더 예제: dmarc=bestguesspass action=none
• 의미: 보낸 사람의 도메인에 게시된 DMARC 레코드가 없기 때문에 기본적으로 메시지가 DMARC를 전달했습니다. 도메인에 DMARC 정책이 없는 경우 대상 전자 메일 서버는 DMARC에서 메시지를 실패할 수 없습니다. 실제로 DMARC 검사 적용되지 않습니다. DMARC=bestguesspass action=none는 도메인에 유효한 DMARC 레코드가 있으면 메시지에 대한 DMARC 검사 전달됩니다.
• 책임 있는 사람: 보낸 사람입니다.
• 권장 작업: 보낸 사람은 해당 도메인에 대한 DMARC 레코드를 게시해야 합니다 . 메시지가 수락되었지만 DMARC 정책의 부재는 좋은 징조가 아닙니다. 도메인 소유자는 DMARC 유효성 검사에 실패한 메시지에 대해 DMARC 정책(p=quarantine 또는 p=reject)을 적용하도록 DMARC TXT 레코드를 설정하는 것이 좋습니다. 자세한 내용은 DMARC TXT 레코드 구문을 참조하세요.

ARC 유효성 검사(복잡한 라우팅 시나리오)

• 헤더 예제: compauth=pass reason=130 (ARC로 인해 통과된 복합 인증).
• 의미: ARC(인증된 수신 체인) 재정의로 인해 인증을 통과한 메시지입니다. 이 결과는 일반적으로 복잡한 메일 라우팅 또는 전자 메일 전달 시나리오에서 발생합니다. 중간 메일 서버에서 메시지를 수정하고 SPF 또는 DKIM이 실패하는 경우 신뢰할 수 있는 ARC 서명은 원래 인증이 유효하다는 것을 Microsoft 365에 알릴 수 있습니다. 이 경우 직접 SPF 또는 DKIM 검사가 실패할 수 있지만 시스템은 유효한 ARC 체인을 기반으로 메시지를 수락했습니다.
• 책임 있는 사람: 보낸 사람(원래 보낸 사람 또는 중개자)입니다. 잘못된 구성은 없습니다. ARC를 사용하는 중개자에서 메시지를 처리했습니다.
• 권장 작업: 이 시나리오가 필요한 경우 직접 작업이 필요하지 않습니다 (예: ARC를 구현하는 알려진 서비스에 의해 메시지가 처리됨). Microsoft가 아닌 중간 서비스를 운영하는 경우 ARC 헤더를 추가하고 수신 서버(예: Microsoft 365)가 ARC 서명을 신뢰하는지 확인합니다. 이 구성을 사용하면 인바운드 메시지가 ARC를 통해 호환성을 전달할 수 있습니다.

테넌트 허용/차단 목록에서 스푸핑된 보낸 사람의 허용 항목으로 인해 전달된 메시지

• 의미: 스푸핑된 보낸 사람의 허용 항목이 테넌트 허용/차단 목록에 있기 때문에 메시지가 일반 인증 실패 작업을 무시했습니다. Microsoft 365에서는 스푸핑된 보낸 사람의 허용 항목이 오류를 재정의할 수 있습니다. 전자 메일 인증 검사가 일반적으로 실패하더라도 이 명시적 신뢰 구성으로 인해 메시지가 허용됩니다.

• 헤더 예제: compauth=fail reason=000 (그러나 organization 정책에서 테넌트 허용/차단 목록 스푸핑 허용됨) 메시지를 허용했습니다.

• 책임 있는 사람: 받는 사람입니다. 받는 사람의 organization 관리자는 이 특정 도메인 쌍에 대한 테넌트 허용/차단 목록에서 스푸핑 허용 항목을 구성했습니다. 발신자는 다른 받는 사람의 배달 가능성 문제를 방지하기 위해 인증 문제를 resolve 합니다.

• 권장 작업: 받는 사람 관리자는 Email 엔터티 페이지의모든 재정의 섹션을 검사 테넌트 허용/차단 목록 재정의가 관련되어 있는지 확인할 수 있습니다. 이러한 메시지에는 허용된 organization 정책: 테넌트 허용/차단 목록 스푸핑이 허용됩니다.

  일반적으로 이러한 메시지는 의도적으로 허용되므로 즉각적인 조치는 없습니다 . 그러나 관리자가 스 푸핑된 보낸 사람의 허용 항목을 주기적으로 검토 하여 필요한 보낸 사람만 허용되는지 확인하는 것이 좋습니다. 테넌트 허용/차단 목록을 과도하게 사용하면 일반적으로 인증 검사에 실패하는(악의적일 수 있음) 메시지를 배달할 수 있습니다.

PTR(역방향 DNS) 맞춤을 통해 인증됨

• 헤더 예제: compauth=pass PTR 레코드 사용을 나타내는 또는 reason=111 과 같은 reason=116 코드가 있습니다.
• 의미: 대체 항목으로 PTR(역방향 DNS) 유효성 검사를 기반으로 인증을 통과한 메시지입니다. SPF 및 DKIM 검사가 결정적인 통과를 생성하지 않는 경우 Microsoft 365는 보낸 사람의 PTR 레코드를 볼 수 있습니다. 보내는 서버의 IP 주소에 메시지의 보낸 사용자 주소에 있는 도메인과 일치하는 PTR 레코드(역방향 DNS)가 있는 경우 시스템에서 메시지를 인증된 것으로 처리할 수 있습니다.
• 책임 있는 사람: 보낸 사람입니다. 보낸 사람의 전자 메일 서버는 DNS의 PTR 레코드를 통해 확인되었습니다. 이 결과는 일반적으로 SPF 및 DKIM이 올바르게 구성되지 않았고 시스템이 PTR 조회에 의존했음을 의미합니다.
• 권장 작업: 보낸 사람은 SPF 및 DKIM이 해당 도메인에 대해 올바르게 구성되었는지 확인해야 합니다. 보내는 도메인을 보내는 IP 주소에 매핑하는 올바른 역방향 DNS(PTR) 레코드는 좋지만 DMARC 맞춤을 대체하는 것은 아닙니다. 보낸 사람은 SPF 및 DKIM 구성을 개선하기 위해 PTR 패스를 지표로 처리해야 합니다. 받는 사람이 이 결과를 알릴 때 알리는 것 외에는 받는 사람에 대한 조치가 없습니다.

Email 인증 실패 시나리오

이러한 시나리오에서는 실패한 인증 검사 또는 메시지가 인증되지 않은 것으로 표시된 기타 조건을 다룹니다. 인증 검사 실패했다고 해서 항상 메시지가 거부된 것은 아닙니다. 일부 오류로 인해 메시지가 격리되거나 경고와 함께 전달됩니다. 다음 시나리오에서는 오류가 발생한 이유, 오류를 해결해야 하는 사용자 및 기본 문제를 해결하는 방법을 설명합니다.

발신자는 원본 organization 관리자를 참조합니다. 받는 사람은 대상 organization 관리자를 참조합니다.

DMARC 실패(메시지가 거부되거나 격리됨)

• 헤더 예제: dmarc=fail action=quarantine (또는 action=reject); 종종 compauth=fail 코드와 함께 제공됩니다(예: , reason=000reason=001또는 reason=601).

• 의미: 메시지에 대한 DMARC 유효성 검사가 실패했습니다 . 이 결과는 다음을 의미합니다.

  • SPF 또는 DKIM이 보낸 주소 도메인에 대한 맞춤을 전달하지 않았습니다.

    그리고

  • 보낸 사용자 주소 도메인의 DMARC 레코드에는 또는 p=reject 정책이 포함됩니다p=quarantine.

  결과적으로 Microsoft 365는 지정된 정책 작업에 대한 메시지를 표시했습니다. 정크 Email 폴더로 배달, 격리 또는 거부.

• 책임 있는 사람: 보낸 사람 또는 받는 사람입니다. 이 오류는 보낸 사람의 도메인이 DMARC를 전달하지 못하거나 DMARC가 실패하게 한 받는 사람의 복잡한 메일 라우팅 구성 때문입니다.

  보낸 사람이 해당 도메인에 대해 SPF, DKIM 및 DMARC를 올바르게 구성할 책임이 있지만 인증 실패로 인해 받는 사람의 organization 문제가 발생할 수 있습니다. 예시:

  • 받는 사람의 organization 커넥터에 대한 향상된 필터링을 구성하지 않고 인터넷 Microsoft 365 간에 Microsoft가 아닌 필터링 서비스를 사용합니다. Microsoft 365에서 메시지를 받으면 SPF 유효성 검사가 실패할 수 있습니다.
  • Microsoft가 아닌 필터링 서비스에서 배달 전에 메시지를 수정하는 경우 보낸 사람의 DKIM 레코드가 올바르게 구성되어 있더라도 DKIM이 실패할 수 있습니다.

  따라서 초기 수신 시점의 평결(MX 레코드)과 메시지가 받는 사람의 사서함에 도달할 때의 평결을 구분하는 것이 중요합니다.

• 권장 작업:

  • 보낸 사람은 전자 메일 인증 구성을 수정해야 합니다. 특히 발신자는 다음 단계를 수행해야 합니다.

    • 해당 SPF 레코드에 도메인의 전자 메일에 대한 모든 합법적인 원본 IP 주소가 포함되어 있는지 확인합니다.
    • 도메인에 대한 DKIM 을 설정하고 서명이 발신 메일에 올바르게 적용되는지 확인합니다.
    • SPF 또는 DKIM(또는 둘 다)이 DMARC에서 요구하는 대로 보낸 사람 주소 도메인과 도 일치하는 지 확인합니다.
    • DMARC 레코드 구문 및 DMARC 정책을 확인합니다. 예: p=quarantine 또는 p=reject.

  • 받는 사람은 복잡한 메일 라우팅 구성을 수정해야 합니다. 특히 받는 사람은 다음 단계를 수행해야 합니다.

    • 커넥터에 대한 향상된 필터링 구성
    • 사용 가능한 경우 전송 중인 메시지 수정으로 인한 오류를 재정의하도록 신뢰할 수 있는 ARC 실러 를 구성합니다.
    • Microsoft 365를 사용하여 비 Microsoft 서비스 대신 메시지 수정(바닥글, 고지 사항, 제목 등)을 적용하는 것이 좋습니다.

SPF 검사 실패

• 헤더 예제: spf=fail 또는 spf=softfail. spf=temperror 일시적인 DNS 문제를 나타내거나 spf=permerror SPF 구성 문제를 나타내는지 확인합니다.

• 의미: 다음 가능성 중 하나입니다.

  • 보내는 서버의 IP 주소는 도메인의 SPF 레코드에 의해 권한이 부여되지 않으므로 SPF는 실패를 반환 합니다.
  • SPF 검사 제대로 완료할 수 없습니다. 예를 들어 DNS 조회 문제(spf=temperror) 또는 리디렉션이 너무 많습니다(spf=permerror).

  DMARC 패스 없이 SPF가 실패하면 DMARC도 실패합니다.

• 책임 있는 사람: 보낸 사람입니다. 문제는 보낸 사람 도메인의 SPF 레코드 구성 또는 보내는 서버 설정에 있습니다.

• 권장 작업: 보낸 사람에서 도메인의 SPF 레코드를 업데이트하고 수정해야 합니다.

  • 도메인 에 대한 모든 합법적인 원본 IP 주소 가 SPF 레코드에 포함되어 있는지 확인합니다.
  • 도메인이 잘못 정렬되어 DMARC가 실패하는 경우(MAIL FROM 주소 도메인이 보낸 사람 주소 도메인과 다릅니다) 다음 단계 중 하나 또는 둘 다를 수행하여 수정할 수 있습니다.
    • MAIL FROM 및 From 주소에 사용되는 도메인을 정렬합니다.
    • 보낸 사람의 주소 도메인과 일치하는 도메인을 사용하여 보내는 메시지의 DKIM 서명을 설정합니다. DMARC에는 SPF 또는 DKIM 유효성 검사가 모두 필요하지 않습니다.
  • spf=temperror 일반적으로 수신자에게 SPF 레코드를 해결하는 데 문제가 있음을 나타냅니다(예: 일시적인 DNS 문제). 보낸 사람은 도메인의 DNS 서버가 정상이고 연결할 수 있는지 확인해야 합니다. TTL(Time to Live) 값이 너무 낮고 시간 제한이 자주 발생하는 경우 TTL을 최소 1시간으로 늘리는 것이 좋습니다.
  • spf=permerror 일반적으로 10개 이상의 DNS 조회가 필요한 등 SPF 레코드 자체의 문제를 나타냅니다. 불필요한 include: 문을 제거하고 구문 오류를 수정하여 SPF 레코드를 간소화합니다.

SPF 문제를 해결한다는 것은 메시지가 DMARC 인증을 통과할 가능성이 더 높다는 것을 의미합니다. 받는 사람은 SPF 오류에 대해 보낸 사람에게 알리고 문제를 해결하기 위한 권장 조치를 알려야 합니다.

DKIM 검사 실패(서명에 대한 키 없음)

• 헤더 예제: dkim=fail 공개 키가 누락된 경우(서명에 대한 키 없음)

• 의미: 다음 가능성 중 하나입니다.

  • DKIM 서명이 있었지만 수신자가 DNS에서 일치하는 공개 키를 찾을 수 없습니다(키 없음).

    또는

  • 키가 서명과 일치하지 않습니다(서명을 확인할 수 없음).

• 책임 있는 사람: 보낸 사람입니다. 보낸 사람의 도메인에 손상된 DKIM 설정이 있습니다.

  • 공개 키는 DNS의 DKIM CNAME 또는 TXT 레코드에 없습니다.

    또는

  • 보낸 사람 쪽 또는 수신자 쪽에 DNS 문제가 있습니다.

• 권장 작업: 보낸 사람은 다음 단계를 수행하여 도메인에 대해 설정된 DKIM을 수정 해야 합니다.

  • DNS에 DKIM 공개 키를 게시 합니다. DKIM CNAME 또는 TXT 레코드에 메시지에 서명하는 데 사용되는 프라이빗 키와 일치하는 유효한 선택기(예: selector._domainkey.contoso.com)가 포함되어 있는지 확인합니다.
  • 키가 게시되면 Microsoft 365에서 레코드를 쿼리하려고 할 때 시간 제한이 발생할 수 있습니다. TTL(Time to Live) 값이 1 시간 이상으로 설정되어 있는지 확인합니다.

DKIM이 제대로 구성되고 정렬되면 수신자는 메시지가 DMARC를 통과하는 데 도움이 되는 메시지를 확인 dkim=pass 합니다.

수정 후 DKIM 실패(서명이 확인하지 않음)

• 헤더 예제: dkim=fail (서명이 확인하지 않음).
• 의미: 메시지에 유효한 DKIM 서명이 포함되어 있지만 DKIM 서명에 포함된 헤더가 서명된 후 전송 중에 수정되었기 때문에 메시지가 DKIM 확인에 실패했습니다. 이 수정은 일반적으로 DKIM 서명이 처음 적용된 후 중개자(예: 메일 그룹, 전달 서비스 또는 보안 어플라이언스)가 서명된 헤더(예: Subject:, From:또는 To:)를 변경할 때 발생합니다. DKIM-Signature의 값은 h= 원래 해시에 포함된 헤더를 식별합니다. 이러한 헤더를 수정하면 DKIM이 실패합니다.
• 책임 있는 사람: 메시지 헤더를 변경한 보낸 사람 또는 중개 자입니다. 원래 보낸 사람 DKIM이 메시지에 올바르게 서명했지만 중개자가 손상된 DKIM 서명을 담당할 수 있습니다.
• 권장 작업: DKIM이 메시지에 서명한 후 헤더를 변경하지 마세요.
  • 보낸 사람: 메시지가 DKIM 서명된 순간부터 사용자 환경을 떠날 때까지 서명된 헤더가 변경되지 않은 상태로 유지되는지 확인합니다.
  • 중간자: 고객이 전송 중 메시지 수정으로 인한 DKIM 오류를 재정의하도록 신뢰할 수 있는 ARC 실러 로 서비스를 구성할 수 있습니다.

수정 후 DKIM 실패(본문 해시 실패)

• 헤더 예제: dkim=fail (본문 해시 실패).
• 의미: 메시지에 유효한 DKIM 서명이 포함되어 있지만 서명된 후 메시지 본문이 전송 중에 수정되었기 때문에 메시지가 DKIM 확인에 실패했습니다. 이 수정은 일반적으로 중간자(예: 메일 그룹, 전달 서비스 또는 보안 어플라이언스)가 DKIM 서명이 처음 적용된 후 메시지 본문 콘텐츠를 변경할 때 발생합니다. 그 결과 수신 메일 시스템에서 계산한 해시가 DKIM 서명의 해시와 일치하지 않으므로 DKIM 검사 실패합니다.
• 책임 있는 사람: 메시지를 변경한 보낸 사람 또는 중개 자입니다. 원래 보낸 사람 DKIM이 메시지에 올바르게 서명했지만 중개자가 손상된 DKIM 서명을 담당할 수 있습니다.
• 권장 작업: 서명 후 전자 메일 콘텐츠에 대한 의도하지 않은 변경 내용이 없는지 확인합니다.
  • 보낸 사람: 다음 단계를 수행합니다.
    • 서명된 헤더는 메시지가 DKIM 서명된 순간부터 환경이 떠날 때까지 변경되지 않은 상태로 유지되는지 확인합니다.
    • Microsoft 365를 사용하여 비 Microsoft 서비스 대신 메시지 수정(바닥글, 고지 사항, 제목 등)을 적용하는 것이 좋습니다.
  • 중간자: 고객이 전송 중 메시지 수정으로 인한 DKIM 오류를 재정의하도록 신뢰할 수 있는 ARC 실러 로 서비스를 구성할 수 있습니다.

빠른 참조 테이블

이 섹션에는 시나리오, 권장 솔루션 및 추가 읽기를 위해 관련 문서에 대한 링크를 요약하는 간소화된 테이블이 포함되어 있습니다.

발신자 는 보내는 도메인의 관리자를 참조합니다. 받는 사람은 수신 organization 관리자를 나타냅니다.

모범 사례 및 팁

• SPF, DKIM 및 DMARC 구현: 이러한 기술은 서로를 보완하고 심층 방어를 제공합니다. 아무것도 덜 보호에 격차를 떠난다.

• DNS 레코드 유지 관리: 모든 전자 메일 원본을 사용하여 SPF 레코드를 최신 상태로 유지합니다. 필요에 따라 DKIM 키를 회전 및 관리하고 DMARC 보고서를 모니터링하여 인증 실패를 식별합니다.

• 인증 결과 모니터링: 정기적으로 인증-결과 헤더를 검사 또는 도구/보고서(예: Microsoft 365 스푸핑 인텔리전스 인사이트)를 사용하여 들어오는 메시지가 어떻게 수행되는지 확인합니다. 이 활동은 SPF/DKIM을 설정하지 않았거나 사용자 고유의 메시지가 인증에 실패하는 경우 파트너를 표시할 수 있습니다.

• 릴레이 시나리오에 ARC 사용: organization 메일 전달을 수행하거나 메시지를 수정하는 비 Microsoft 서비스를 사용하는 경우 Microsoft 365에서 신뢰할 수 있는 ARC 실러를 구성하는 것이 좋습니다. ARC는 메시지가 중간자를 통해 전송되는 경우 인증을 유지하고 거짓 오류를 방지하는 데 도움이 될 수 있습니다.

• 허용 목록에 주의: organization 허용 항목이 아닌 가능한 경우 표준 인증 결과에 의존합니다. 허용 항목은 예외여야 하며 불필요한 항목을 제거하기 위해 주기적으로 확인해야 합니다.

• 정보 유지: 다음 리소스를 따르세요.

  • Office 365용 Microsoft Defender 블로그
  • Exchange 팀 블로그
  • Office 365용 Microsoft Defender의 새로운 기능
  • Microsoft 365 메시지 센터.