Microsoft 365 도메인에 대한 유효한 전자 메일 원본을 식별하도록 SPF 설정

• 적용 대상:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

팁

Microsoft Defender XDR Office 365 플랜 2의 기능을 무료로 사용해 볼 수 있다는 사실을 알고 계셨나요? Microsoft Defender 포털 평가판 허브에서 90일 Office 365용 Defender 평가판을 사용합니다. 여기에서 등록 및 평가판 조건에 대해 알아봅니 다.

SPF(보낸 사람 정책 프레임워크)는 Microsoft 365 organization 보낸 메일의 유효성을 검사하여 BEC(비즈니스 전자 메일 손상), 랜섬웨어 및 기타 피싱 공격에 사용되는 스푸핑된 보낸 사람 방지를 돕는 이메일 인증 방법입니다.

SPF의 주요 목적은 도메인에 대한 전자 메일 원본의 유효성을 검사하는 것입니다. 특히 SPF는 DNS의 TXT 레코드를 사용하여 도메인에 대한 유효한 메일 원본을 식별합니다. 전자 메일 시스템 수신은 SPF TXT 레코드를 사용하여 메시지의 SMTP 전송 중에 사용된 보낸 사람 주소(MAIL FROM 주소, 주소, 5321.MailFrom P1 보낸 사람 또는 봉투 보낸 사람)의 전자 메일이 해당 도메인에 대해 지정된 알려진 메일 원본인지 확인합니다.

예를 들어 Microsoft 365의 전자 메일 도메인이 contoso.com 경우 contoso.com 도메인에 대한 DNS에 SPF TXT 레코드를 만들어 Microsoft 365를 contoso.com 승인된 메일 원본으로 식별합니다. 대상 전자 메일 시스템은 contoso.com SPF TXT 레코드를 검사 메시지가 contoso.com 전자 메일에 대한 권한 있는 원본에서 온 것인지 여부를 확인합니다.

시작하기 전에 전자 메일 도메인을 기반으로 Microsoft 365의 SPF에 대해 알아야 할 내용은 다음과 같습니다.

• 전자 메일(예: contoso.onmicrosoft.com)에 Microsoft Online Email MOERA(라우팅 주소) 도메인만 사용하는 경우: 아무 작업도 수행할 필요가 없습니다. SPF TXT 레코드가 이미 구성되어 있습니다. Microsoft는 onmicrosoft.com 도메인을 소유하므로 해당 도메인 및 하위 도메인에서 DNS 레코드를 만들고 유지 관리할 책임이 있습니다. *.onmicrosoft.com 도메인에 대한 자세한 내용은 "onmicrosoft.com" 도메인이 있는 이유는 무엇인가요?를 참조하세요.

• 전자 메일에 하나 이상의 사용자 지정 도메인(예: contoso.com)을 사용하는 경우: Microsoft 365 등록 프로세스에서는 Microsoft 365를 인증된 메일 원본으로 식별하기 위해 사용자 지정 도메인에 대한 DNS에서 SPF TXT 레코드를 만들거나 수정해야 했습니다. 하지만 최대 전자 메일 보호를 위해 수행해야 할 작업이 더 있습니다.

  • 하위 도메인 고려 사항:

    • 직접 제어되지 않는 전자 메일 서비스(예: 대량 메일 서비스)의 경우 기본 전자 메일 도메인(예: contoso.com) 대신 하위 도메인(예: marketing.contoso.com)을 사용하는 것이 좋습니다. 해당 전자 메일 서비스에서 보낸 메일에 대한 문제가 기본 전자 메일 도메인의 직원이 보낸 메일의 평판에 영향을 주지 않도록 합니다. 하위 도메인을 추가하는 방법에 대한 자세한 내용은 사용자 지정 하위 도메인 또는 여러 도메인을 Microsoft 365에 추가할 수 있나요?를 참조하세요.

    • Microsoft 365에서 전자 메일을 보내는 데 사용하는 각 하위 도메인에는 자체 SPF TXT 레코드가 필요합니다. 예를 들어 contoso.com SPF TXT 레코드는 marketing.contoso.com 다루지 않습니다. marketing.contoso.com 자체 SPF TXT 레코드가 필요합니다.

      팁

      Email 정의되지 않은 하위 도메인에 대한 인증 보호는 DMARC에서 다룹니다. 모든 하위 도메인(정의 여부)은 부모 도메인의 DMARC 설정을 상속합니다(하위 도메인당 재정의할 수 있습니다). 자세한 내용은 Microsoft 365에서 보낸 사람의 보낸 사람 주소 도메인의 유효성을 검사하도록 DMARC 설정을 참조하세요.

  • 등록되었지만 사용되지 않는 도메인을 소유하고 있는 경우: 전자 메일 또는 아무것도 전혀 사용되지 않는 등록된 도메인( 주차된 도메인이라고도 함)을 소유한 경우 이 문서의 뒷부분에 설명된 대로 해당 도메인에서 전자 메일이 들어오지 않도록 SPF TXT 레코드를 구성합니다.

• SPF만으로는 충분하지 않습니다. 사용자 지정 도메인에 대한 최상의 전자 메일 보호 수준을 위해 전체 전자 메일 인증 전략의 일부로 DKIM 및 DMARC를 구성해야 합니다. 자세한 내용은 이 문서의 끝에 있는 다음 단계 섹션을 참조하세요.

  중요

  도메인에 대한 유효한 모든 메일 원본을 식별하기 어려운 복잡한 조직에서는 도메인에 대한 DKIM 서명 및 DMARC('작업 없음' 모드)를 신속하게 구성하는 것이 중요합니다. DMARC 보고 서비스는 도메인에 대한 이메일 원본 및 SPF 오류를 식별하는 데 매우 유용합니다.

이 문서의 나머지 섹션에서는 Microsoft 365에서 사용자 지정 도메인에 대해 만들어야 하는 SPF TXT 레코드에 대해 설명합니다.

팁

도메인에서 SPF 레코드를 관리할 수 있는 Microsoft 365에는 관리 포털 또는 PowerShell cmdlet이 없습니다. 대신 도메인 등록 기관 또는 DNS 호스팅 서비스(종종 동일한 회사)에서 SPF TXT 레코드를 만듭니다.

Microsoft는 많은 도메인 등록 기관에서 Microsoft 365에 대한 도메인 소유권 증명 TXT 레코드를 만드는 지침을 제공합니다. 이러한 지침을 시작점으로 사용하여 SPF TXT 레코드 값을 만들 수 있습니다. 자세한 내용은 DNS 레코드 추가를 참조하여 도메인을 연결합니다.

DNS 구성에 익숙하지 않은 경우 도메인 등록 기관에 문의하고 도움을 요청하세요.

SPF TXT 레코드 구문

SPF TXT 레코드는 RFC 7208에 완전히 설명되어 있습니다.

Microsoft 365의 사용자 지정 도메인에 대한 SPF TX 레코드의 기본 구문은 다음과 같습니다.

v=spf1 <valid mail sources> <enforcement rule>

또는

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

예시:

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

• v=spf1 는 TXT 레코드를 SPF TXT 레코드로 식별합니다.

• 유효한 메일 원본: 도메인에 대해 유효한 메일 원본을 지정했습니다. 도메인, IP 주소 또는 둘 다를 사용합니다.

  • 도메인: include: 값은 다른 서비스 또는 도메인을 원래 도메인의 유효한 메일 원본으로 지정합니다. 이러한 값은 궁극적으로 DNS 조회를 사용하는 IP 주소로 이끕니다.

    대부분의 Microsoft 365 조직은 도메인에 대한 SPF TXT 레코드에 필요합니다 include:spf.protection.outlook.com . 다른 타사 전자 메일 서비스는 원래 도메인에서 유효한 전자 메일 원본으로 서비스를 식별하기 위해 추가 include: 값이 필요한 경우가 많습니다.

  • IP 주소: IP 주소 값에는 다음 요소가 모두 포함됩니다.

    • IP 주소의 형식을 식별하는 값 ip4: 또는 ip6: 입니다.
    • 원본 전자 메일 시스템의 공개적으로 확인할 수 있는 IP 주소입니다. 예시:
      • 개별 IP 주소(예: 192.168.0.10)입니다.
      • CIDR(클래스리스 Inter-Domain 라우팅) 표기법을 사용하는 IP 주소 범위(예: 192.168.0.1/26). 범위가 너무 크거나 너무 작지 않은지 확인합니다.

    Microsoft 365에서는 일반적으로 Microsoft 365 도메인에서 메일을 보내는 온-프레미스 전자 메일 서버(예: 하이브리드 배포 Exchange Server)가 있는 경우에만 SPF TXT 레코드의 IP 주소를 사용합니다. 일부 타사 전자 메일 서비스는 SPF TXT 레코드의 include: 값 대신 IP 주소 범위를 사용할 수도 있습니다.

• 적용 규칙: 대상 전자 메일 시스템에 도메인에 대한 SPF TXT 레코드에 지정되지 않은 원본의 메시지로 수행할 작업을 알려줍니다. 유효한 값은 다음과 같습니다.

  • -all (하드 실패): SPF TXT 레코드에 지정되지 않은 원본은 도메인에 대한 메일을 보낼 권한이 없으므로 메시지를 거부해야 합니다. 메시지에 실제로 발생하는 작업은 대상 전자 메일 시스템에 따라 달라지지만 메시지는 일반적으로 삭제됩니다.

    Microsoft 365 도메인의 경우 도메인에 DKIM 및 DMARC도 권장하므로 (하드 실패)하는 것이 좋습니다 -all . DMARC 정책은 SPF 또는 DKIM에 실패한 메시지에 대해 수행할 작업을 지정하고 DMARC 보고서를 통해 결과의 유효성을 검사할 수 있습니다.

    팁

    앞에서 설명한 것처럼 DMARC 보고 서비스로 구성된 DMARC는 도메인에 대한 이메일 원본 및 SPF 오류를 식별하는 데 크게 도움이 됩니다.

  • ~all (소프트 실패): SPF TXT 레코드에 지정되지 않은 원본은 도메인 에 대한 메일을 보낼 권한이 없으므로 메시지를 수락하지만 표시해야 합니다. 메시지에 실제로 발생하는 작업은 대상 전자 메일 시스템에 따라 달라집니다. 예를 들어 메시지는 스팸으로 격리되거나 정크 Email 폴더로 배달되거나 주체 또는 메시지 본문에 추가된 식별자를 사용하여 받은 편지함으로 배달될 수 있습니다.

    또한 Microsoft 365 도메인에 DKIM 및 DMARC를 권장하므로 (하드 실패)와 ~all (소프트 실패) 간의 -all 차이점이 효과적으로 제거됩니다(DMARC는 SPF 오류로 처리됨). DMARC는 SPF를 사용하여 MAIL FROM 및 From 주소의 도메인이 정렬 되고 메시지가 From 도메인에 대한 유효한 원본에서 온 것을 확인합니다.

  팁

  ?all (중립)은 확인되지 않은 원본의 메시지에 대한 특정 작업을 제안할 수도 있습니다. 이 값은 테스트에 사용되며 프로덕션 환경에서는 이 값을 사용하지 않는 것이 좋습니다.

기억해야 할 중요한 사항:

• DNS에서 정의된 각 도메인 또는 하위 도메인에는 SPF TXT 레코드가 필요하며 도메인 또는 하위 도메인당 하나의 SPF 레코드만 허용됩니다. Email 정의되지 않은 하위 도메인에 대한 인증 보호는 DMARC에서 가장 잘 처리됩니다.
• *.onmicrosoft.com 도메인에 대한 기존 SPF TXT 레코드는 수정할 수 없습니다.
• 대상 전자 메일 시스템이 SPF 레코드에서 유효한 전자 메일 원본을 확인하면 검사 DNS 조회가 너무 많은 경우 SPF 유효성 검사가 실패합니다. 자세한 내용은 이 문서의 뒷부분에 있는 SPF TXT 레코드 문제 해결 섹션을 참조하세요.

Microsoft 365의 사용자 지정 도메인에 대한 SPF TXT 레코드

팁

이 문서에서 앞에서 설명한 것처럼 도메인의 도메인 등록 기관에서 도메인 또는 하위 도메인에 대한 SPF TXT 레코드를 만듭니다. Microsoft 365에서는 SPF TXT 레코드 구성을 사용할 수 없습니다.

• 시나리오: Microsoft 365에서 전자 메일에 contoso.com 사용하고 Microsoft 365는 contoso.com 전자 메일의 유일한 원본입니다.

  Microsoft 365 및 Microsoft 365 GCC(Government Community Cloud)의 contoso.com SPF TXT 레코드:

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

  Microsoft 365 Government Community Cloud High(GCC High) 및 Microsoft 365 DoD(국방부)의 contoso.com SPF TXT 기록:

  v=spf1 include:spf.protection.office365.us -all
  

  21Vianet에서 운영하는 Microsoft 365의 contoso.com SPF TXT 레코드

  v=spf1 include:spf.protection.partner.outlook.cn -all
  

• 시나리오: Microsoft 365의 전자 메일에 contoso.com 사용하고 도메인의 모든 전자 메일 원본을 사용하여 contoso.com SPF TXT 레코드를 이미 구성했습니다. 또한 도메인 contoso.net 및 contoso.org 소유하고 있지만 전자 메일에는 사용하지 않습니다. contoso.net 또는 contoso.org 전자 메일을 보낼 권한이 없음을 지정하려고 합니다.

  contoso.net 대한 SPF TXT 레코드:

  v=spf1 -all
  

  contoso.org 대한 SPF TXT 레코드:

  v=spf1 -all
  

• 시나리오: Microsoft 365의 전자 메일에 contoso.com 사용합니다. 다음 원본에서 메일을 보낼 계획입니다.

  • 외부 전자 메일 주소가 192.168.0.10인 온-프레미스 전자 메일 서버입니다. 이 전자 메일 원본을 직접 제어할 수 있으므로 contoso.com 도메인의 보낸 사람에게 서버를 사용하는 것이 좋다고 간주합니다.
  • Adatum 대량 메일링 서비스입니다. 이 전자 메일 원본을 직접 제어할 수 없으므로 하위 도메인을 사용하는 것이 좋습니다. 따라서 해당 용도로 marketing.contoso.com 만듭니다. Adatum 서비스 설명서에 따르면 도메인에 대한 SPF TXT 레코드에 를 추가 include:servers.adatum.com 해야 합니다.

  contoso.com 대한 SPF TXT 레코드:

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

  marketing.contoso.com 대한 SPF TXT 레코드:

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

SPF TXT 레코드 문제 해결

• 도메인 또는 하위 도메인당 하나의 SPF 레코드: 동일한 도메인 또는 하위 도메인에 대한 여러 SPF TXT 레코드로 인해 SPF가 실패하는 DNS 조회 루프가 발생하므로 도메인 또는 하위 도메인당 하나의 SPF 레코드만 사용합니다.

• 10개 미만의 DNS 조회: 대상 전자 메일 시스템이 SPF TXT 레코드에서 MAIL FROM 주소 도메인에 대한 유효한 원본을 쿼리할 때 쿼리는 메시지 원본(궁극적으로 IP 주소)이 지정된 원본 중 하나와 일치할 때까지 레코드의 IP 주소 및 include: 문을 검색합니다. DNS 조회 수(DNS 쿼리 수와 다를 수 있는)가 10보다 크면 영구 오류(라고도 함 permerror)로 인해 메시지가 SPF에 실패합니다. 대상 전자 메일 시스템은 다음 오류 중 하나와 함께 배달 외 보고서(NDR 또는 반송 메시지라고도 함)의 메시지를 거부합니다.

  • 메시지가 홉 수를 초과했습니다.
  • 메시지에 너무 많은 조회가 필요했습니다.

  SPF TXT 레코드에서 개별 IP 주소 또는 IP 주소 범위는 DNS 조회를 유발하지 않습니다. 각 include: 문에는 하나 이상의 DNS 조회가 필요하며 값이 중첩된 리소스를 가리키는 경우 include: 더 많은 조회가 필요할 수 있습니다. 즉, 문이 10 include: 개 미만이면 10개 미만의 DNS 조회가 보장되지 않습니다.

  또한 대상 전자 메일 시스템은 SPF TXT 레코드의 원본을 왼쪽에서 오른쪽으로 평가합니다. 메시지 원본의 유효성이 검사되면 평가가 중지되고 더 이상 원본을 검사하지 않습니다. 따라서 SPF TXT 레코드에는 10개 이상의 DNS 조회를 유발할 수 있는 충분한 정보가 포함될 수 있지만 일부 대상의 일부 메일 원본 유효성 검사는 레코드의 깊이가 부족하여 오류가 발생하지 않습니다.

  기본 전자 메일 도메인의 평판을 유지하는 것 외에도 DNS 조회 수를 초과하지 않는 것은 제어하지 않는 다른 전자 메일 서비스에 하위 도메인을 사용하는 또 다른 이유입니다.

무료 온라인 도구를 사용하여 도메인에 대한 SPF TXT 레코드 및 기타 DNS 레코드를 볼 수 있습니다. 일부 도구는 SPF TXT 레코드에 필요한 DNS 레코드 조회 수를 계산하기도 합니다.

다음 단계

SPF, DKIM 및 DMARC가 함께 작동하여 전자 메일 메시지 보낸 사람 인증에 설명된 대로 SPF만으로는 Microsoft 365 도메인의 스푸핑을 방지하기에 충분하지 않습니다. 또한 최상의 보호를 위해 DKIM 및 DMARC를 구성해야 합니다. 해당 지침은 다음 항목을 참조하세요.

• DKIM을 사용하여 사용자 지정 도메인에서 전송한 아웃바운드 전자 메일의 유효성 검사
• DMARC를 사용하여 전자 메일의 유효성 검사

Microsoft 365로 들어오는 메일의 경우 organization 배달하기 전에 전송 중인 메시지를 수정하는 서비스를 사용하는 경우 신뢰할 수 있는 ARC Sealer를 구성해야 할 수도 있습니다. 자세한 내용은 신뢰할 수 있는 ARC 실러 구성을 참조하세요.