사용자 지정 클라우드 도메인에 대한 유효한 전자 메일 원본을 식별하도록 SPF 설정

Microsoft Defender Office 365 플랜 2의 기능을 무료로 사용해 볼 수 있다는 사실을 알고 계셨나요? Microsoft Defender 포털 평가판 허브에서 90일 간의 defender for Office 365 평가판을 사용합니다. Office 365 Microsoft 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 설정을 상속합니다(하위 도메인당 재정의할 수 있습니다). 자세한 내용은 클라우드 발신자에 대한 '보낸 사람' 주소 도메인을 확인하도록 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 TXT 레코드의 기본 구문은 다음과 같습니다.

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

또는:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName2>... 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 레코드에 지정되지 않은 발신 서버는 아마도 해당 도메인에 대해 메일을 보낼 권한이 없으므로 메시지는 수락하되 표시해야 합니다. 메시지에 실제로 어떤 일이 발생하는지는 대상 전자 메일 시스템에 따라 달라집니다. 예를 들어 메시지는 스팸으로 격리되거나, 정크 메일 폴더로 배달되거나, 제목이나 메시지 본문에 식별자가 추가된 상태로 받은 편지함에 배달될 수 있습니다.

      참고

      DMARC는 -all (하드 실패) 및 ~all (소프트 실패)를 SPF 오류로 처리합니다. 그러나 메시지에 DKIM 서명도 포함되어 있지 않으면 SPF ~all 오류에 대해 DMARC 정책이 효과적으로 무시됩니다. 메시지에 DKIM 서명이 없는 경우 SPF에 실패한 메시지에 대해 DMARC가 작동할 수 있도록 하는 것이 좋습니다 -all .

    • ?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 전자 메일만

Microsoft 365에서 전자 메일에 contoso.com을 사용하며, contoso.com의 전자 메일은 Microsoft 365에서만 발송됩니다.

  • 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 Department of Defense (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
    

시나리오: 주차된 도메인

contoso.net 도메인과 contoso.org 소유하고 있지만 전자 메일에는 사용하지 않습니다. contoso.net 또는 contoso.org에서 전자 메일을 보낼 권한이 아무에게도 없다고 지정하려고 합니다.

  • contoso.net 대한 SPF TXT 레코드:

    v=spf1 -all
    
  • contoso.org 대한 SPF TXT 레코드:

    v=spf1 -all
    

참고

이 문서에서 앞에서 설명한 것처럼 각 하위 도메인에는 자체 SPF TXT 레코드가 필요합니다. 주차된 도메인의 경우 필요한 하위 도메인을 추측하는 것은 사실상 불가능합니다. 도메인 등록 기관에서 와일드카드 레코드를 지원하는 경우 다음 구문을 사용하여 아무도 주차된 도메인의 하위 도메인에서 전자 메일을 보낼 권한이 없음을 지정할 수 있습니다.

호스트 이름: _*.contoso.net 또는 _*.contoso.org
TXT 값: v=spf1 -all

시나리오: 온-프레미스 전자 메일 및 비 Microsoft 전자 메일 서비스가 포함된 Microsoft 365 전자 메일

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 오류, 원인 및 수정 사항에 대한 빠른 참조 테이블은 Microsoft 365에서 전자 메일 인증 문제 해결을 참조하세요.

  • 도메인 또는 하위 도메인당 하나의 SPF 레코드: 동일한 도메인 또는 하위 도메인에 대한 여러 SPF TXT 레코드로 인해 SPF가 반환 permerror 되므로(수신 시스템에서 평가할 레코드를 확인할 수 없음) 도메인 또는 하위 도메인당 하나의 SPF 레코드만 사용합니다.

  • TTL(Time to Live): DNS 조회 시간 제한을 방지하려면 SPF TXT 레코드에서 최소 TTL 값 3600초(1시간)를 사용하는 것이 좋습니다.

  • 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: 구문이 있다고 해서 DNS 조회도 10회 미만이라고 보장할 수는 없습니다.

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

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

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

DNS 조회로 간주되는 항목

다음 SPF 메커니즘 및 한정자는 각각 하나의 DNS 조회로 계산됩니다.

  • include:
  • a
  • mx
  • exists
  • redirect

다음 요소는 10개 조회 제한에 포함되지 않습니다 .

  • ip4: 값(개별 주소 또는 CIDR 범위)
  • ip6: 값(개별 주소 또는 CIDR 범위)
  • all 메커니즘

중첩된 include: 구문은 SPF 레코드의 직접 조회 외에 추가 조회를 발생시킨다는 점에 유의하세요. 예를 들어, include: 구문이 세 개 더 포함된 다른 SPF 레코드를 가리키는 include:는 총 4회의 조회를 추가합니다(초기 조회 1회와 중첩 조회 3회).

DNS 조회 줄이기

SPF 레코드가 조회 한도 10을 초과하는 경우 다음 전략을 사용하여 조회 수를 줄입니다.

  • include 값을 IP 주소로 바꾸기: Microsoft 이외 공급업체에 안정적이고 문서화된 발신 IP 주소 집합이 있는 경우 해당 include: 문을 ip4: 또는 ip6: 값으로 바꾸세요. 이 방법을 사용하려면 공급업체에서 IP 주소 변경 내용을 모니터링해야 합니다.
  • 하위 도메인 사용: Microsoft 이외의 전자 메일 서비스를 하위 도메인으로 이동합니다. 예를 들어 자체 SPF 레코드가 있는 마케팅 전자 메일에 marketing.contoso.com 사용합니다. 각 하위 도메인에는 10개의 조회 예산이 있습니다.
  • 전자 메일 서비스 통합: 가능하면 도메인에서 전자 메일을 보내는 비 Microsoft 서비스 수를 줄입니다.

SPF 레코드의 일반적인 구문 오류

TXT 레코드에 서식 오류가 포함된 경우 SPF 유효성 검사가 실패합니다. 다음 예제에서는 일반적인 실수를 보여 줍니다.

잘못된 입력 문제 올바른 항목
v=spf1 include:spf.protection.outlook.com. -all 도메인 이름 뒤의 후행 기간입니다. v=spf1 include:spf.protection.outlook.com -all
v=spf1 include=spf.protection.outlook.com -all include 뒤에 콜론 대신 등호를 사용합니다. v=spf1 include:spf.protection.outlook.com -all
v=spf1 include: spf.protection.outlook.com -all 콜론과 도메인 이름 사이의 공간입니다. v=spf1 include:spf.protection.outlook.com -all

도메인이 include: 확인되지 않거나 SPF 레코드가 없는 경우 SPF 유효성 검사가 반환 permerror 되고 메시지가 거부될 수 있습니다. include: 항목을 참조된 도메인의 DNS TXT 레코드를 조회하여 확인합니다.

SPF 평면화

SPF 평면화는 DNS 조회를 줄이기 위해 메커니즘을 확인된 IP 주소로 바꾸는 include: 방법입니다.

평면화가 적절한 경우:

  • 안정적인 문서화된 IP 주소 범위를 사용하는 Microsoft 공급업체가 아닌 공급업체입니다.
  • 보내는 IP 주소를 거의 변경하지 않는 서비스입니다.
  • 조회 한도 10개에 근접하거나 초과하는 경우 다른 전략(하위 도메인, 통합)은 불가능합니다.

평면화해서는 안 되는 경우:

  • Microsoft 365(include:spf.protection.outlook.com). Microsoft 전송 인프라는 자주 변경되는 동적 IP 주소를 사용합니다.
  • 동적 또는 자주 변경되는 IP 주소가 있는 모든 클라우드 서비스입니다.

SPF 레코드를 평면화한 경우:

  • 대체한 include: 항목과 시기를 문서화합니다.
  • IP 주소 변경에 대한 공급업체 설명서를 모니터링합니다.
  • 적어도 분기별로 평면화된 항목을 검토하고 업데이트합니다.
  • 각 변경 후 SPF 유효성 검사를 테스트합니다.

비 Microsoft SPF 평면화 서비스는 공급업체 IP 변경 내용을 추적하고 SPF 레코드를 업데이트하는 프로세스를 자동화할 수 있습니다. 조직에서 수동 유지 관리가 비실용적인 경우 이러한 서비스를 평가합니다.

다음 단계

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

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

전자 메일 인증 실패를 진단하고 해결하려면 Microsoft 365에서 전자 메일 인증 문제 해결을 참조하세요.