MTA-STS로 메일 흐름 향상

2025-01-15

Exchange Online에 SMTP MTA Strict Transport Security(MTA-STS) 표준에 대한 지원이 추가되었습니다. 이 표준은 이메일 서버 간의 연결에 항상 TLS를 사용하도록 개발되었습니다. 또한 보내는 서버가 받는 서버에 신뢰할 수 있는 인증서가 있는지 확인하는 방법을 제공합니다. TLS가 제공되지 않거나 인증서가 유효하지 않은 경우 보낸 사람이 메시지 배달을 거부합니다. 이러한 새로운 검사는 SMTP의 전반적인 보안을 개선하고 메시지 가로채기(man-in-the-middle) 공격으로부터 보호합니다.

MTA-STS는 인바운드 및 아웃바운드 보호의 두 가지 시나리오로 나눌 수 있습니다. 인바운드 보호는 MTA-STS를 사용하여 Exchange Online 호스트되는 도메인의 보호를 포함합니다. 아웃바운드 보호는 MTA-STS로 보호되는 도메인으로 전자 메일을 보낼 때 Exchange Online 수행되는 MTA-STS 유효성 검사를 포함합니다.

팁

E5 고객이 아닌 경우 90일 Microsoft Purview 솔루션 평가판을 사용하여 조직이 데이터 보안 및 규정 준수 요구 사항을 관리하는 데 도움이 되는 추가 Purview 기능을 살펴보세요. Microsoft Purview 평가판 허브에서 지금 시작합니다. 등록 및 평가판 조건에 대한 세부 정보를 알아봅니다.

아웃바운드 보호

Exchange Online MTA-STS로 보호되는 수신자에게 아웃바운드로 전송된 모든 메시지는 MTA-STS 표준에 의해 설정된 이러한 추가 보안 검사를 통해 유효성을 검사합니다. 관리자가 적용할 필요가 없습니다. 아웃바운드 구현은 MTA-STS 정책을 통해 받는 사람 도메인 소유자의 요구 사항을 준수합니다. MTA-STS는 Exchange Online 보안 인프라의 일부를 구성하므로 다른 핵심 SMTP 기능과 마찬가지로 항상 켜져 있습니다.

참고

스마트 호스트를 사용하는 아웃바운드 커넥터의 경우 받는 사람의 최종 대상 도메인이 아닌 스마트 호스트 도메인에 대해 MTA-STS 유효성 검사를 수행합니다.

아웃바운드 MTA-STS는 대상 도메인에 대한 MTA-STS 유효성 검사 결과에 따라 전자 메일이 배달되지 않도록 방지할 수 있습니다. 도메인이 안전하지 않고 MTA-STS 정책이 적용으로 설정된 경우 다음 오류 코드 중 하나를 사용하여 보낸 사람에게 NDR이 반환될 수 있습니다.

오류 코드	설명	가능한 원인	추가 정보
5.4.8	'{domain}'의 MX 호스트가 MTA-STS 유효성 검사에 실패했습니다.	대상 MX 호스트는 도메인의 STS 정책에 따라 예상되는 호스트가 아니었습니다.	이 오류는 일반적으로 MX 호스트를 포함하지 않는 대상 도메인의 MTA-STS 정책에 대한 문제를 나타냅니다. MTA-STS에 대한 자세한 내용은 를 참조하세요 https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	원격 인증서가 MTA-STS 유효성 검사에 실패했습니다. 이유: {validityStatus}	대상 메일 서버의 인증서는 신뢰할 수 있는 루트 인증 기관에 연결되어야 하며 일반 이름 또는 주체 대체 이름에는 STS 정책의 호스트 이름에 대한 항목이 포함되어야 합니다.	이 오류는 일반적으로 대상 메일 서버의 인증서에 문제가 있음을 나타냅니다. MTA-STS에 대한 자세한 내용은 를 참조하세요 https://datatracker.ietf.org/doc/html/rfc8461.

인바운드 보호

도메인 소유자는 MX 레코드가 Exchange Online을 가리키는 경우 MTA-STS를 사용하여 도메인으로 전송된 전자 메일을 보호하기 위한 조치를 취할 수 있습니다. MX 레코드가 중간 타사 서비스를 가리키는 경우 MTA-STS 요구 사항이 충족되는지 여부를 충족한 다음 해당 지침을 따라야 합니다.

도메인에 대해 MTA-STS가 설정되면 MTA-STS를 지원하는 발신자가 보낸 모든 메시지는 보안 연결을 보장하기 위해 표준에서 제시한 유효성 검사를 수행합니다. MTA-STS를 지원하지 않는 발신자로부터 이메일을 받는 경우 추가 보호 없이 이메일이 계속 전달됩니다. 마찬가지로, 아직 MTA-STS를 사용하지 않고 있지만 보낸 사람이 지원하는 경우 메시지가 중단되지 않습니다. 메시지가 배달되지 않는 유일한 시나리오는 양측이 MTA-STS를 사용하고 있고 MTA-STS 유효성 검사가 실패한 경우입니다.

MTA-STS를 채택하는 방법

MTA-STS를 사용하면 도메인에서 TLS 지원을 선언하고 예상할 MX 레코드 및 대상 인증서를 전달할 수 있습니다. 또한 문제가 있는 경우 보내는 서버에서 수행해야 하는 작업을 나타냅니다. 이 통신은 DNS TXT 레코드와 HTTPS 웹 페이지로 게시된 정책 파일의 조합을 통해 수행됩니다. HTTPS로 보호되는 정책은 공격자가 극복해야 하는 또 다른 보안 보호 기능을 도입합니다.

도메인의 MTA-STS TXT 레코드는 발신자에 대한 MTA-STS 지원을 나타내며, 그 후 발신자는 도메인의 HTTPS 기반 MTA-STS 정책을 검색합니다. TXT 레코드에는 v=STSv1; STSv2가 지원되고 정책에 대한 ID가 지원될 때까지 입니다. ID는 도메인 소유자 및 정책에 대해 고유해야 합니다. ID가 변경되면 보낸 사람에게 정책을 다시 가져와야 한다는 신호가 표시됩니다. ID는 전역적으로 고유할 필요가 없으며 다른 도메인 소유자의 정책 ID에 대해 걱정하지 마세요. MTA-STS 정책이 업데이트되면 ID를 업데이트해야 합니다. 또는 보낸 사람이 캐시된 정책의 max_age 만료될 때까지 도메인에 대해 캐시된 정책을 계속 사용합니다.

고유 ID를 설정하는 반복 가능한 패턴은 다음과 같이 UTC 시간을 사용하는 것입니다.
id=<yyyymmddhh0000>Z;

다음 TXT 레코드는 MTA-STS에 대한 지원을 선언하는 예제입니다. ID는 2022년 1월 1일 오전 8시 UTC 시간으로 설정되었습니다.

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

도메인의 MTA-STS 정책은 도메인의 웹 인프라에서 호스팅하는 미리 정의된 URL에 있어야 합니다. URL 구문은 https://mta-sts.<domain name>/.well-known/mta-sts.txt입니다. 예를 들어, Microsoft.com의 정책은 https://mta-sts.microsoft.com/.well-known/mta-sts.txt에 있습니다.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

MX 레코드가 Exchange Online 직접 가리키는 모든 고객은 자체 정책에서 에 https://mta-sts.microsoft.com/.well-known/mta-sts.txt표시된 것과 동일한 값을 지정할 수 있습니다. 정책의 고유한 필수 정보는 Exchange Online(*.mail.protection.outlook.com)을 가리키는 MX 레코드이며 모든 Exchange Online 고객이 동일한 인증서를 공유합니다. Exchange Online 와일드카드를 사용하면 보안이 약화되지 않도록 한 organization 지정된 도메인에 대한 전자 메일만 받을 수 있습니다. 그러나 다른 전자 메일 서비스의 경우는 그렇지 않을 수 있습니다. 정책을 테스트 모드로 게시하여 적용 모드로 변경하기 전에 유효한지 확인할 수 있습니다 . 구성을 확인할 수 있는 타사 유효성 검사 도구가 있습니다.

이러한 정책은 Exchange Online 고객을 대신하여 호스트할 수 있는 정책이 아니므로 고객은 원하는 서비스를 사용하여 도메인의 STS 정책을 구성해야 합니다. Azure 서비스는 정책 호스팅에 쉽게 사용할 수 있으며 이 문서의 뒷부분에 구성 연습이 있습니다. 정책은 하위 도메인 mta-sts.<domain name>에 대한 인증서를 사용하여 HTTPS로 보호되어야 합니다.

DNS TXT 레코드가 만들어지고 필요한 HTTPS URL에서 정책 파일을 사용할 수 있게 되면 도메인은 MTA-STS로 보호됩니다. MTA-STS에 대한 자세한 내용은 RFC 8461에서 확인할 수 있습니다.

Azure Services를 사용하여 인바운드 MTA-STS 구성

참고

이러한 구성 흐름은 Microsoft Exchange Online 고객이 Azure 리소스를 사용하여 MTA-STS 정책을 호스트하는 데 도움이 되도록 개발되었습니다. 이 구성 흐름은 사용자가 MTA-STS의 작동 방식과 요구 사항을 알고 있는 Exchange Online 고객이라고 가정합니다. 이 항목 이외의 프로토콜에 대한 자세한 내용은 RFC8461 참조하세요.

MTA-STS 정책을 호스트하는 데 사용할 수 있는 Azure 리소스에는 Azure Static Web App 및 Azure Functions 두 가지가 있습니다. 이 문서에서는 두 리소스를 모두 사용하여 정책을 배포하는 방법을 설명하지만 권장되는 방법은 STS 정책과 같은 정적 페이지를 호스팅하도록 설계된 Azure Static Web App 이며, Azure는 더 많은 구성 없이 MTA-STS 웹 페이지에 대한 TLS 인증서를 기본적으로 제공하여 구성을 간소화합니다. Azure Static Web App을 사용할 수 없는 경우 Azure Functions 사용하여 정책을 서버리스 코드로 호스트할 수도 있습니다. Azure Functions 다른 시나리오를 위해 설계된 기능이며 Azure Static Web Apps 달리 TLS 인증서를 자동으로 발급하지 않기 때문에 이 방법은 기본 방법이 아닙니다. 따라서 MTA-STS에 Azure Functions 사용하려면 고유한 "mta-sts.[ 도메인]" 인증서를 함수에 바인딩합니다.

어떤 방법을 사용했든 관계없이 정책이 제대로 구성되었는지 여부와 응답 시간이 허용되는지 여부를 확인하는 것이 좋습니다. RFC 지침당 시간 제한은 60초입니다.

이러한 구성 흐름은 MTA-STS 정책을 호스트하는 데 사용할 수 있고 Azure 기능의 충전 또는 비용에 대한 정보를 제공하지 않는 Azure 기능에 대한 기술 정보만 제공하기 위한 것입니다. Azure 기능의 비용을 알고 싶다면 Azure 가격 계산기를 사용합니다.

옵션 1(권장): Azure Static Web App

Azure DevOps organization 만들거나 이미 있는 organization 사용합니다. 이 예제에서는 "ContosoCorporation"이라는 organization MTA-STS 정책을 호스트하는 데 사용됩니다.
리포지 > 토리 파일에서 원하는 모든 IDE에 리포지토리를 복제합니다. 이 예제에서는 리포지토리가 Visual Studio에서 복제됩니다.
리포지토리가 복제되면 폴더 경로 home\.well-known\를 만듭니다. 그런 다음, 다음 파일을 만듭니다.
- 파일 1: home.well-known\mta-sts.txt
  
  참고
  
  이 구성을 사용하면 Exchange Online 도메인을 대신하여 메시지를 받을 수 있습니다. 여러 전자 메일 공급자를 사용하는 경우 해당 다른 공급자의 도메인에 대한 MX 호스트도 참조해야 합니다. 와일드카드 또는 '*'는 모든 MTA-STS 시나리오에서 MX 접두사로 사용해서는 안 됩니다. 아래 설정은 Exchange Online 전용이며 MTA-STS를 구성하기 위한 일반적인 지침으로 사용해서는 안 됩니다.
  1. 파일에 다음 텍스트를 입력합니다 mta-sts.txt .
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    참고
    
    정책 모드를 처음에 테스트로 설정하는 것이 좋습니다. 그런 다음 구성이 끝나고 정책이 예상대로 작동하는지 유효성을 검사한 후 모드가 적용되도록 파일을 업데이트 mta-sts.txt합니다.
    
    파일은 다음 스크린샷과 같이 콘텐츠만 포함해야 합니다.
- 파일 2: home\index.html
  1. index.html 파일을 만들고 다음 코드를 입력합니다.
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    파일은 다음 스크린샷과 같이 콘텐츠만 포함해야 합니다.
    
    폴더 경로 및 파일이 만들어지면 변경 내용을 커밋하고 기본 분기에 푸시하는 것을 잊지 마세요.
다음 구성을 사용하여 새 Azure Static Web App을 만듭니다.
- 이름: MTA-STS-StaticWebApp
- 계획 유형: Standard
- 배포 세부 정보: Azure DevOps
- 조직: ContosoCorporation
- 프로젝트: MTA-STS_Project
- 리포지토리: MTA-STS_Project
- 분기: master
- 빌드 사전 설정: Angular
- 앱 위치: /home
정적 웹앱 만들기가 완료되고 리소스가 프로비전되면 개요 > 배포 토큰 관리로 이동한 다음, 다음 단계에서 사용할 토큰을 복사합니다.
파이프라인 > 만들기 파이프라인 > Azure Repos Git > MTA-STS_Project 이동하여 다음 하위 작업을 수행합니다.
1. 변수 새 > 변수로 이동하여 다음을 입력합니다.
  1. 이름: 토큰
  2. 값: (이전에 복사한 토큰을 5단계에서 붙여넣기)
2. 변수가 저장되면 파이프라인 YAML 검토 로 돌아가서 다음 yml을 붙여넣고 저장하고 실행합니다.
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  Azure DevOps에서 배포 중에 호스트된 병렬 처리가 구매되지 않았거나 부여되지 않음 오류가 발생하는 경우 이 양식을 통해 요청하거나 조직 설정 > 병렬 작업을 > 통해 구성을 구현합니다. Microsoft 호스팅 유료 병렬 작업에서 "유료 병렬 작업"이 허용되도록 유료 병렬 작업을 변경 >> 합니다.
작업이 성공적으로 완료되면 Azure Static Web App > Environment > Browser로 이동하여 Azure Portal 통해 배포의 유효성을 검사할 수 있습니다. 파일의 콘텐츠가 index.html 표시되어야 합니다.
Azure Static Web App > 사용자 지정 도메인 추가에서 베니티 도메인을 추가합니다>. 영역이 사용자에게 속하는지 확인하려면 DNS 공급자(예: GoDaddy)를 통해 CNAME 레코드를 만들어야 합니다. 유효성 검사가 완료되면 Azure에서 인증서를 발급하고 정적 웹앱에 자동으로 바인딩합니다.
MTA-STS 정책이 [도메인]/.잘 알려진/mta-sts.txt 통해 https://mta-sts.게시되는지 확인합니다.
DNS 공급자를 통해 MTA-STS TXT DNS 레코드를 만듭니다. 형식:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain's STS policy>Z;
```
참고

MTA-STS TXT 레코드의 예는 MTA-STS를 채택하는 방법에서 찾을 수 있습니다.
DNS에서 TXT 레코드를 사용할 수 있게 되면 MTA-STS 구성의 유효성을 검사합니다. 구성의 유효성이 성공적으로 검사되면 정책 모드가 적용되도록 파일을 업데이트 mta-sts.txt 한 다음, TXT 레코드에서 정책 ID를 업데이트합니다.

옵션 2: Azure Function

다음 구성을 사용하여 새 Azure Function App을 만듭니다.
- 함수 앱 이름: [원하는 대로]
- 게시: 코드
- 런타임 스택: .NET
- 버전: 6
- 운영 체제: Windows
- 계획 유형: [원하는 대로]
함수 앱에 사용자 지정 도메인을 추가합니다. 도메인이 사용자에게 속하는지 여부를 확인하기 위해 CNAME 레코드를 만들어야 합니다.
"mta-sts를 바인딩합니다. [도메인]"을 함수 앱에 연결합니다.
앱 파일에서 함수 앱의 host.json 다음 확장을 추가하여 routePrefix를 제거합니다. 이 추가는 함수 URL에서 /api를 제거하는 데 필요합니다.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
함수 앱에서 함수 > 만들기 로 이동하여 다음 매개 변수를 구성합니다.

참고

이 예제에서는 포털을 통한 함수 개발에 대해 설명하지만 VS Code 또는 원하는 다른 도구를 자유롭게 사용할 수 있습니다.
- 개발 환경: [원하는 대로 이 예제에서는 "포털에서 개발"을 사용합니다.]
- 템플릿 선택: HTTP 트리거
- 새 함수: [원하는 대로]
- 권한 부여 수준: 익명
함수가 만들어지면 Code + Test 를 열고 C#에서 MTA-STS 정책이 될 간단한 비동기 HTTP 응답을 개발합니다. 다음 예제는 Exchange Online 이메일을 받을 것으로 예상됨을 나타냅니다.

참고

정책 모드를 처음에 테스트로 설정하는 것이 좋습니다. 그런 다음 구성이 끝나고 정책이 예상대로 작동하는지 유효성을 검사한 후 모드가 적용되도록 파일을 업데이트 mta-sts.txt합니다.
통합 > HTTP(req)에서 트리거를 다음 값으로 편집합니다.
- 경로 템플릿: .well-known/mta-sts.txt
- 선택한 HTTP 메서드: GET
MTA-STS 정책이 [도메인]/.well-known/mta-sts.txt 통해 https://mta-sts.게시되어 있는지 확인합니다.
다음 형식으로 DNS 공급자를 통해 MTA-STS TXT DNS 레코드를 만듭니다.
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain's STS policy>Z;
```
참고

MTA-STS TXT 레코드의 예는 MTA-STS를 채택하는 방법에서 찾을 수 있습니다.
DNS에서 TXT 레코드를 사용할 수 있게 되면 MTA-STS 구성의 유효성을 검사합니다. 구성의 유효성이 성공적으로 검사되면 정책 모드가 적용되도록 파일을 업데이트 mta-sts.txt 한 다음, TXT 레코드에서 정책 ID를 업데이트합니다.

"테스트" 모드로 전환하여 인바운드 MTA-STS 문제 완화

이 방법을 사용하면 적용을 일시 중지해야 한다는 신호를 보낸 사람에게 알리는 동안 MTA-STS 인프라를 그대로 유지할 수 있습니다. 엄격한 적용으로 인해 배달 오류가 발생할 수 있는 인시던트 중에 유용합니다.

1단계: 정책 파일 업데이트

정책 모드 값을 테스트로 변경합니다.

이 구성은 보낸 사람에게 정책을 가져오지만 적용하지 말고 TLS 보고서를 보내도록 지시합니다.

2단계: 업데이트된 정책 파일 업로드

다음 위치에서 업데이트된 파일을 도메인의 HTTPS 서버에 업로드합니다.

https://mta-sts.<your-domain>/.well-known/mta-sts.txt

3단계: DNS TXT 레코드 업데이트

_mta-sts.<your-domain> DNS TXT ID 값을 새 고유 문자열(예: UTC 타임스탬프)으로 변경하여 레코드를 업데이트합니다.

고유 ID를 설정하는 반복 가능한 패턴은 다음과 같이 정책 업데이트의 현재 UTC 시간을 사용하는 것입니다. id=<yyyymmddhh0000>Z;

다음 TXT 레코드는 업데이트된 MTA-STS txt 레코드의 예이며, 업데이트는 2022년 1월 1일 오전 8시 UTC 시간으로 발생합니다.