SMTP TLS 보고(TLS-RPT)란 무엇인가요?

조직에서 이메일을 주요 커뮤니케이션 수단으로 점점 더 많이 사용함에 따라 잠재적인 위협으로부터 이러한 채널을 강화하는 것의 중요성은 아무리 강조해도 지나치지 않습니다.TLS(전송 계층 보안)는 네트워크를 통해 전송되는 데이터의 기밀성과 무결성을 보장합니다. 

SMTP TLS 보고(TLS-RPT)는 이메일이 안전하게 전달되도록 MTA-STS와 함께 작동하는 중요한 프로토콜입니다. TLS-RPT는 이메일 전송 문제에 대한 자세한 피드백을 제공함으로써 도메인 소유자가 커뮤니케이션의 무결성과 기밀성을 유지할 수 있도록 도와줍니다. 이 종합 가이드에서는 SMTP TLS 보고가 무엇인지, 어떻게 작동하는지, 이메일 보안 전략에 왜 필수적인지 살펴볼 것입니다."

여러 프로토콜은 사이버 공격자가 이메일 통신을 가로채지 못하도록 SMTP 메시지 채널을 암호화하는 데 도움이 됩니다. 여기에는 STARTTLS, DANE, MTA-STS가 포함됩니다. 그러나 이러한 프로토콜을 사용하는 동안 암호화 시도가 실패하면 이메일이 전달되지 않을 수 있습니다. TLS-RPT( RFC 8460)는 이러한 배달 실패를 보고하는 피드백 메커니즘을 제공합니다.

TLS-RPT를 다음과 함께 사용할 것을 적극 권장합니다. MTA-STS 프로토콜과 함께 사용할 것을 적극 권장합니다. 이 두 프로토콜이 어떻게 함께 작동하여 이메일 보안.

TLS-RPT란 무엇인가요?

TLS-RPT(전송 계층 보안 보고)는 이메일이 TLS로 암호화되지 않은 경우 이메일 전송 문제를 보고하기 위한 표준입니다. 이메일 인증에서 이 기능이 중요한 이유는 이메일에 TLS 암호화를 사용하도록 설정하는 이유와도 밀접한 관련이 있습니다. 

TLS 암호화는 사용자에게 전송되는 모든 이메일이 안전하게 전달되도록 보장합니다. 연결이 안전하지 않은 경우 이메일이 전달되지 않는 경우가 많습니다. 도메인 소유자는 TLS-RPT를 통해 이메일 전송 및 연결 실패를 모니터링할 수 있습니다. 보고서에는 다음에 대한 정보가 포함될 수 있습니다: 

• MTA-STS 정책 처리 문제 
• 배송 실패 이유 및 유형
• 이메일 송수신 메일 전송 에이전트의 IP 주소
• 성공 및 실패한 TLS 연결 세션의 총 개수 

이를 통해 이메일 채널에 대한 가시성을 확보하고 전달률 문제에 더 빠르게 대응할 수 있습니다.

PowerDMARC로 SMTP TLS 보고를 간소화하세요!

TLS 보고는 어떻게 작동하나요?

SMTP 이메일 통신에서 TLS 암호화는 "기회주의적" 암호화입니다. 즉, 암호화된 채널을 협상할 수 없는 경우 이메일은 여전히 암호화되지 않은(일반 텍스트) 형식으로 전송됩니다. 사실 거의 40년 전만 해도 SMTP 이메일 프로토콜은 TLS 암호화를 지원하지 않았습니다. 이 기능은 나중에 STARTTLS 명령의 형태로 추가되어야 했습니다. 

STARTTLS 명령은 양쪽이 모두 TLS 암호화를 지원하는 경우에만 SMTP 통신에서 실행됩니다. 그렇지 않으면 이메일은 여전히 일반 텍스트로 전송됩니다. 

SMTP에서 기회주의적 암호화를 없애기 위해 MTA-STS가 도입되었습니다(RFC 8461). MTA-STS 프로토콜은 이메일이 전달되기 전에 암호화되도록 합니다. 이메일 서버 또는 MTA(메일 전송 에이전트)는 수신 서버와 협상하여 STARTTLS 명령을 지원하는지 확인합니다. 지원하는 경우 이메일이 TLS로 암호화되어 배달됩니다. 그렇지 않으면 배달에 실패합니다.

TLS-RPT 작동 방식에 대한 단계별 설명

1. TLS 핸드셰이크 프로세스 이해

TLS 핸드셰이크(전송 계층 보안 핸드셰이크)는 통신하는 두 MTA(메일 전송 에이전트) 간에 보안 연결을 설정하는 프로세스입니다. 이 프로세스에는 다음 단계가 포함됩니다: 

• 이메일을 보내는 MTA는 수신하는 MTA에 "클라이언트 안녕하세요" 메시지를 보냅니다. 이 메시지에는 TLS 버전 및 암호 모음과 같은 유용한 매개 변수가 포함되어 있습니다. 
• 이메일을 수신하는 MTA는 이 메시지를 수신하고 "서버 안녕하세요" 메시지로 응답합니다. 여기에는 선택한 TLS 버전과 암호 세트가 포함됩니다. 
• TLS 핸드셰이크가 시작된 후 수신 MTA는 신뢰할 수 있는 CA(인증 기관)에서 발급한 SSL/TLS 인증서를 전송합니다. 이 인증서에는 공개 키가 포함되어 있습니다.
• 통신하는 두 MTA는 암호화 키를 안전하게 교환하고 TLS로 암호화된 연결을 설정합니다. 이렇게 하면 양 당사자 간의 안전한 이메일 통신이 보장됩니다. 

2. 실패한 TLS 핸드셰이크 시나리오 

다양한 이유로 인해 TLS 핸드셰이크가 실패할 수 있습니다: 

• 인증 오류: 만료된 인증서 또는 신뢰할 수 없는 인증 기관에서 발급한 인증서로 인해 TLS 핸드셰이크가 실패할 수 있습니다.
• 버전 불일치: 송신 및 수신 MTA에서 지원하는 TLS 버전이 일치하지 않으면 핸드셰이크 실패로 이어질 수 있습니다.
• STARTTLS 실패: STARTTLS 명령이 올바르게 구현되지 않으면 다시 TLS 암호화 실패로 이어질 수 있습니다.
• MTA-STS 적용: 이메일 수신자가 MTA-STS 정책 모드를 '적용'으로 설정한 경우 TLS 핸드셰이크에 실패하면 메시지가 거부될 수 있습니다.

3. 보고서 생성 및 전달

TLS 암호화 실패가 발생할 때마다 보내는 서버는 추가 평가 및 문제 해결을 위해 TLS-RPT 보고서를 생성하여 도메인 소유자에게 보냅니다. 

보고서 내용

서버 세부 정보 보내기: 발신자의 IP 주소 및 도메인 이름입니다.

서버 세부 정보 수신: 수신자 도메인 및 이메일 서버 정보입니다.

오류 설명: 오류의 유형 및 세부 정보(예: 인증서 오류, 프로토콜 불일치)입니다.

실패 시간: 문제가 발생한 타임스탬프입니다.

정책 모드: 도메인이 "테스트" 모드인지 "적용" 모드인지 여부입니다.

보고서 전달

이러한 TLS 보고서는 도메인 소유자의 TLS-RPT DNS TXT 레코드에 지정된 이메일 주소로 JSON 형식으로 전송됩니다. 

SMTP에서 기회주의적 암호화의 역할

SMTP는 전통적으로 기회 암호화를 사용합니다. 즉, TLS를 사용하려고 시도하지만 수신 MTA가 TLS를 지원하지 않는 경우 암호화되지 않은 배달로 되돌아갑니다.

그러나 기회주의 암호화에는 한 가지 큰 제한이 있습니다. 의무를 설정하지 않는 이 유형의 암호화에서는 TLS 암호화에 실패할 경우 이메일이 일반 텍스트 또는 일반 텍스트(암호화되지 않은 형식)로 전송될 수 있습니다. 이러한 암호화되지 않은 메시지는 가로채기에 취약합니다.

MTA-STS와 TLS-RPT가 함께 작동하는 방식

메일 전송 에이전트 엄격한 전송 보안(MTA-STS)과 TLS-RPT는 이메일 인증 에코시스템에서 상호 보완적인 프로토콜입니다. MTA-STS는 전송하는 MTA가 반드시 TLS를 사용하여 전달하도록 하고 암호화에 실패하면 이메일을 거부합니다,

도메인 소유자는 TLS-RPT를 통해 실패한 TLS 핸드셰이크를 모니터링하고 문제를 해결할 수 있습니다. 함께 구현하면 전송 중 메시지 가로채기를 방지하고 이메일 전달성 문제를 최소화할 수 있습니다. 

DANE과 TLS-RPT의 관계

DANE(DNS 기반 명명된 엔티티 인증)는 도메인 소유자가 중간자 공격을 방지하기 위해 DNSSEC를 통해 확인된 TLS 인증서를 지정할 수 있는 프로토콜입니다. TLS-RPT가 TLS 실패를 모니터링하는 동안 DANE는 신뢰할 수 있는 인증서만 사용되도록 합니다. 이를 통해 DANE은 공격자가 TLS 다운그레이드 및 인증서 스푸핑 공격을 수행하지 못하도록 적극적으로 방지하여 이메일 통신의 무결성을 유지합니다. 

SMTP TLS 보고가 필요한 이유는 무엇인가요?

도메인 소유자는 MTA-STS 사용 도메인에서 보낸 이메일의 TLS 암호화 실패로 인한 이메일 배달 문제에 대한 정보를 계속 파악해야 합니다. TLS 보고는 이 정보를 제공함으로써 이를 가능하게 합니다. 

• 이메일 보안: 암호화되지 않은 이메일 통신의 위험성(예: 가로채기, 중간자 공격)을 강조합니다.
• 규정 준수: 조직이 데이터 보호에 대한 규제 요건을 충족하는 데 TLS-RPT가 어떻게 도움이 되는지 언급하세요.
• 배달 가능성: TLS-RPT가 암호화 문제를 식별하고 해결하여 이메일 전달성을 향상시키는 방법을 설명합니다.

TLS-RPT 설정 단계

TLS-RPT용 TXT 레코드를 만들고 DNS에 게시하여 도메인에 대한 TLS 보고를 사용 설정할 수 있습니다. 이 레코드는 하위 도메인인 smtp.tls.yourdomain.com

1단계: TLS-RPT 레코드 생성하기(TLS-RPT 레코드 생성기 사용)

당신은 할 수 있습니다 가입 에 무료로 가입하고 TLS-RPT 레코드 생성기를 사용하여 레코드를 생성할 수 있습니다.

2단계: 보고 이메일 주소 입력

SMTP TLS 보고서를 수신할 이메일 주소를 입력합니다.

3단계: DNS에 TLS 레코드 게시하기

도메인 등록기관에 문의하여 TLS-RPT용 TXT 레코드를 새로 만들 수 있습니다. 자체 DNS를 관리하는 경우 해당 레코드를 포함하도록 DNS 설정을 편집하세요.

TLS-RPT 레코드 구문 및 예제

구문: v=TLSRPTv1; rua=mailto:[email protected];

제공된 TLS 보고 레코드의 두 가지 구성 요소를 분석해 보겠습니다:

1. v=TLSRPTv1: 이 태그는 사용 중인 TLS-RPT 프로토콜의 버전을 지정합니다. 이 경우 "TLSRPTv1" 은 프로토콜의 첫 번째 버전을 나타냅니다.
2. rua=mailto:[email protected]: rua는 '집계 데이터에 대한 보고 URI(들)의 약자입니다. 이 태그는 수신자의 메일 서버가 집계된 TLS 보고서를 보낼 위치를 지정합니다.

보고서를 받을 대상을 두 개 이상 구성할 수 있습니다. 여러 대상의 경우 각 항목을 쉼표(,)로 구분하세요. "mailto:"를 사용하여 이 단계의 이메일 주소를 지정하거나, rua= 필드에 "https:"를 사용하여 엔드포인트 URL에 대한 POST를 통해 보고서를 제출하도록 MTA에 지시할 수 있습니다. "https:"를 사용하는 경우 필드가 유효한 인증서가 있는 HTTPS 사용 웹 서버의 URL을 정의하는지 확인하세요. "mailto:"와 "https:"는 쉼표로 구분하여 하나의 레코드에 모두 사용할 수도 있습니다. 

예: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

참고: 참고: 실제로는 "yourdomain.com" 을 이러한 보고서를 수신하려는 실제 도메인 이름으로 대체합니다.

TLS-RPT JSON 보고서 이해

TLS-RPT JSON 보고서의 구조

TLS 보고서는 JSON 형식으로 전송됩니다. 다음은 JSON TLS 보고서의 모습에 대한 예시입니다:

{

  "조직 이름": "조직 주식회사",

  “date-range”: {

    "시작-시간": “2020-10-22T00:00:00Z”,

    "종료 시간": “2020-10-22T23:59:59Z”

  },

  "contact-info": "[email protected]",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "정책": [

    {

      “policy”: {

        "정책 유형": "sts",

        "정책 문자열": [

          "version: STSv1",

          "모드: 테스트",

          "mx: mx.domain.com",

          "mx: mx2.domain.com",

          "mx: mx3.domain.com",

          "max_age: 604800"

        ],

        "정책-도메인": "domain.com"

      },

      “summary”: {

        "총-성공-세션-수": 15,

        "총-실패-세션-수": 0

      }

주요 필드와 그 의미

다음은 이 JSON TLS 보고서의 주요 필드에 대한 분석입니다:

필드	설명
조직	TLS-RPT 레코드를 소유한 도메인 조직입니다.
이메일	집계된 보고서가 전송되는 이메일 주소입니다.
시작_날짜	보고 기간의 시작일입니다.
end_date	보고 기간의 종료일입니다.
정책	보고 기간 동안 적용된 정책을 설명하는 정책 개체 배열입니다.
정책	적용된 정책에 대한 정보가 포함되어 있습니다.
정책 유형	정책 유형을 지정합니다.
정책 문자열	정책과 연결된 정책 문자열을 지정합니다.
모드	MTA-STS 정책 모드(적용/테스트)를 지정합니다.
요약	시도한 세션에 대한 요약 정보를 포함합니다.
총_성공_세션_수	성공적으로 설정된 TLS 세션의 총 개수입니다.
총_실패_세션_수	TLS 세션 실패의 총 횟수입니다.
실패 _ 세부 정보	특정 장애에 대한 세부 정보를 제공하는 개체 배열입니다.
이유	실패 이유를 나타내는 문자열(예: "인증서_만료됨")입니다.
카운트	특정 이유로 실패한 세션의 수입니다.

TLS-RPT JSON 보고서 형식 및 데이터 해석

보고서 메타데이터

{

  "조직 이름": "MTA 조직 보내기",

  “date-range”: {

    "시작-시간": “2025-02-25T00:00:00Z”,

    "종료 시간": “2025-02-25T23:59:59Z”

  },

  "report-id": “unique-report-id-12345”

}

JSON 보고서의 이 섹션에는 이메일 발신자의 조직 이름, 시작 날짜 및 시간, 종료 날짜 및 시간, 생성된 TLS 보고서의 고유 ID와 같은 기본 정보가 요약되어 있습니다.

정책 세부 정보

“policy”: {

  "정책 유형": "sts",

  "정책 문자열": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

이 섹션에서는 구현된 MTA-STS 정책 모드(이 경우 적용 모드)에 대해 설명하지만 테스트 모드로 설정할 수도 있습니다. 

실패 세부 정보

"실패 세부 정보": [

  {

    "결과 유형": "인증서 만료",

    "sending-mta": "smtp.example.org",

    "receiving-mta": "mail.example.com",

    "실패 이유": "만료된 인증서로 인해 TLS 핸드셰이크에 실패했습니다."

  }

]

이 섹션은 TLS 보고서에서 가장 중요한 부분으로, 암호화 및 잠재적인 전송 실패에 대한 근거를 자세히 설명합니다. 이 예에서는 만료된 인증서가 TLS 핸드셰이크 실패의 원인임을 나타냅니다. 이는 TLS 핸드셰이크 실패 시 오류를 감지하는 데 중요한 역할을 하며 안전한 TLS 통신을 위한 신속한 문제 해결을 촉진합니다. 

TLS 암호화 실패 이유 및 문제 해결

TLS 암호화 실패에는 여러 가지 이유가 있을 수 있습니다. 어느 한쪽에서 암호화를 지원하지 않는 것 외에도 SMTP 다운그레이드 공격과 같은 더 불길한 이유로 인해 TLS 연결이 실패할 수 있습니다. 그러나 도메인 소유자는 배달 실패에 대해 알고 싶어 할 것입니다. TLS 보고(TLS-RPT)는 이를 알려주는 프로토콜입니다. 전송에 실패하면 TLS-RPT 레코드에 정의된 이메일 주소로 JSON 파일 형식의 TLS 보고서를 받게 됩니다. 다음은 암호화 실패의 몇 가지 일반적인 이유와 문제 해결 팁입니다:

1. 인증서 발급

인증서_만료

원격 서버에서 제공한 인증서의 만료 날짜가 지났습니다. 따라서 암호화를 위해 신뢰할 수 없습니다. 이 경우 인증서를 갱신해야 합니다.

인증서_not_valid_yet

원격 서버에서 제공한 인증서가 아직 유효하지 않습니다. 서버 시간이 잘못되었거나 인증서를 너무 일찍 사용했기 때문일 수 있습니다. 이 경우 인증서 공급업체에 문의하는 것이 가장 좋습니다.

인증서_취소

원격 서버에서 제공한 인증서가 보안 문제로 인해 인증 기관에 의해 해지되었습니다. 이 경우 인증서 공급업체에 문의하는 것이 가장 좋습니다.

no_valid_signature

원격 서버에서 제공하는 인증서 체인을 발신자의 메일 서버 또는 클라이언트에서 신뢰할 수 없으므로 잠재적인 보안 위험이 있습니다. 이 경우 인증서 공급업체에 문의하는 것이 가장 좋습니다.

지원되지 않는 인증서

원격 서버에서 제공하는 인증서가 발신자의 메일 서버에서 지원하지 않는 암호화 알고리즘이나 키 길이를 사용하여 보안 연결이 되지 않는 경우입니다. 이 경우 인증서 공급업체에 문의하는 것이 가장 좋습니다.

2. 호스트 이름과 ID 불일치

호스트 이름_불일치

서버의 인증서에 지정된 호스트 이름이 발신자의 메일 서버가 연결하려는 서버의 호스트 이름과 일치하지 않습니다. 중간자 공격 또는 구성 문제가 있을 수 있음을 나타냅니다.

MTA-STS 정책 파일에서 MX 레코드를 확인하여 도메인의 MX 레코드와 일치하는지 확인할 수 있습니다.

3. 악수 및 프로토콜 문제

핸드셰이크_실패

발신자의 메일 서버와 수신자의 메일 서버 간에 초기 TLS 핸드셰이크 프로세스 중에 문제가 발생하여 보안 채널이 설정되지 않았습니다. SMTP STARTTLS 연결이 설정되었는지 다시 확인하세요. STARTTLS 지원 부족 또는 TLS 다운그레이드 공격 등 암호화 실패의 원인에는 여러 가지가 있을 수 있습니다.

4. MTA-STS 정책 문제

MTA_STS_정책_못_찾음

이 오류는 발신자의 메일 서버가 수신자 도메인에 대한 MTA-STS 정책을 찾을 수 없을 때 발생합니다. MTA-STS 정책 파일을 검토합니다. MTA-STS 레코드가 올바르게 게시되었는지 확인해야 합니다.

mta_sts_정책_무효

이 실패는 수신자 도메인의 DNS에 있는 MTA-STS 정책이 유효하지 않거나 오류가 있거나 MTA-STS 사양을 준수하지 않을 때 발생합니다. MTA-STS 정책 파일을 검토합니다. 적절한 MTA-STS 정책 모드를 지정합니다. 없음, 적용 또는 테스트 중 하나를 선택할 수 있습니다. 이렇게 하면 보내는 서버에 MTA-STS 정책 유효성 검사에 실패한 이메일을 처리하는 방법을 지시합니다. 

mta_sts_정책_페치_오류

이 오류는 발신자의 메일 서버가 수신자 도메인의 DNS 레코드에서 MTA-STS 정책을 검색하는 동안 오류가 발생할 때 발생합니다. DNS에서 MTA-STS 레코드의 유효성을 검사하여 레코드 구문이 올바른지 확인해야 합니다.

MTA_STS_연결_실패

이 실패는 발신자의 메일 서버가 MTA-STS를 사용하여 보안 연결을 설정하려고 시도하지만 신뢰할 수 없는 인증서, 지원되지 않는 암호 모음 또는 기타 TLS 문제와 같은 이유로 인해 실패할 때 발생합니다. 인증서 유효기간을 확인하고 인증서가 최신 TLS 표준으로 최신 상태인지 확인해야 합니다.

mta_sts_invalid_hostname

이 오류는 MTA-STS 정책에 지정된 수신자 메일 서버의 호스트 이름이 서버의 실제 호스트 이름과 일치하지 않을 때 발생합니다. MTA-STS 정책 파일에서 MX 레코드를 확인하여 도메인의 MX 레코드와 일치하는지 확인해야 합니다.

TLS-RPT 구현 모범 사례

TLS 보고서 정기 모니터링

배달되지 않은 메시지를 놓치지 않도록 TLS 보고서를 정기적으로 모니터링해야 합니다. 메일함에서 JSON 보고서를 수동으로 모니터링하거나 다음과 같은 보고서 분석기 도구를 사용하여 모니터링할 수 있습니다. PowerTLS-RPT.

MTA-STS 정책이 올바르게 구성되었는지 확인

TLS-RPT를 올바르게 구현하려면 구문 오류 없이 MTA-STS 정책을 올바르게 구성해야 합니다. 레코드를 확인하려면 MTA-STS 검사기 를 사용하여 기록을 확인할 수 있습니다.

암호화 실패를 즉시 해결하기

TLS 보고서에 요약된 암호화 실패를 감지하면 향후 이메일 전달성 문제를 방지하기 위해 신속하게 조치를 취하는 것이 중요합니다. 

보안 TLS 프로토콜 버전 사용

원치 않는 암호화 실패를 방지하려면 지원되는 최신 TLS 프로토콜 버전만 사용하는 것이 필수적입니다. 

PowerDMARC로 간소화된 SMTP TLS 보고

PowerDMARC의 SMTP TLS 보고 환경은 호스팅 서비스를 통해 보안을 개선하는 동시에 생활을 더욱 편리하게 만들어줍니다.

번역된 TLS 보고서

복잡한 TLS-RPT JSON 보고서가 몇 초 만에 훑어보거나 자세히 읽을 수 있는 간소화된 정보로 변환됩니다. 

문제 자동 감지

PowerDMARC 플랫폼은 사용자가 직면한 문제를 정확히 파악하고 강조 표시하여 시간 낭비 없이 문제를 해결할 수 있도록 도와줍니다.

PowerDMARC 플랫폼은 사용하기 쉽고 이해하기 쉬운 레이아웃과 호스팅된 DMARC 제어가 가능한 모든 기능을 갖추고 있어 마음에 드는 점이 한 두 가지가 아닙니다, SPF 평탄화를 쉽게 확장하여 레코드의 세부 사항을 검사할 수 있고, 심지어 MTA-STS 및 TLS-RPT를 완벽하게 지원합니다!

딜런 B(비즈니스 소유자)

전송 계층 보안에 관해 자주 묻는 질문

1. TLS는 무엇을 의미하나요?

TLS는 전송 계층 보안의 약자입니다. 

2. TLS 인증서는 누가 발급하나요? 

CA(인증 기관)는 TLS 인증서를 발급할 수 있습니다. 인증서를 발급하는 절차에는 인증서 소유자의 신원 확인이 포함됩니다. 본인 확인에 성공하면 인증서가 발급됩니다. 

3. TLS 인증서가 필요한 이유는 무엇인가요?

TLS 인증서는 인터넷을 통한 통신을 보호하는 데 중추적인 역할을 합니다. 이 인증서는 민감한 정보 민감한 정보를 암호화하는 데 도움이 됩니다. 가장 일반적인 용도로는 이메일 통신 보안과 HTTPS가 있습니다.

4. 현재 TLS 표준은 무엇인가요?

TLS 1.3은 전송 계층 보안의 최신 버전입니다. TLS-RPT는 모든 버전의 TLS를 사용하여 구현할 수 있습니다. 여기에는 프로토콜의 이전 버전이나 향후 버전이 포함될 수 있습니다. 버전은 일반적으로 통신하는 서버의 기능과 같은 기준에 따라 결정됩니다. 

추가 리소스

1. TLS-RPT 레코드 생성기 
2. TLS-RPT 레코드 검사기
3. MTA-STS 
4. DMARC