DMARC 란 무엇입니까? DMARC 레코드 이해

게시 됨: 2020-03-05

도메인 기반 메시지 인증, 보고 및 적합성(DMARC)은 SPF(Sender Policy Framework) 및 DKIM (DomainKeys 식별 메일 ) 을 사용하여 이메일 메시지의 신뢰성을 결정하는 프로토콜입니다.

DMARC 레코드를 사용하면 ISP(인터넷 서비스 공급자)가 수신자의 개인 정보를 피싱하기 위한 도메인 스푸핑과 같은 악의적인 이메일 관행을 쉽게 방지할 수 있습니다.

기본적으로 이메일 발신자는 SPF 또는 DKIM을 사용하여 인증되지 않은 이메일을 처리하는 방법을 지정할 수 있습니다. 발신자는 해당 이메일을 정크 폴더로 보내거나 모두 함께 차단하도록 선택할 수 있습니다. 그렇게 함으로써 ISP는 스패머를 더 잘 식별하고 악의적인 이메일이 소비자 받은 편지함에 침입하는 것을 방지하는 동시에 오탐을 최소화하고 시장의 투명성을 높이기 위해 더 나은 인증 보고를 제공할 수 있습니다.

DMARC 레코드는 DNS 레코드와 함께 게시되며 다음을 포함합니다.

  • SPF
  • A 레코드
  • 씨네임
  • (DKIM)

모든 수신 서버가 메시지를 수락하기 전에 DMARC 검사를 수행하는 것은 아니지만 모든 주요 ISP가 수행하고 구현이 증가하고 있다는 점에 유의하는 것이 중요합니다.

DMARC의 장점은 무엇입니까?

DMARC를 구현하려는 몇 가지 주요 이유는 다음과 같습니다.

  1. 평판: DMARC 레코드를 게시하면 인증되지 않은 당사자가 도메인에서 메일을 보내는 것을 방지하여 브랜드를 보호할 수 있습니다. 어떤 경우에는 단순히 DMARC 레코드를 게시하는 것만으로도 평판이 상승할 수 있습니다.
  2. 가시성: DMARC 보고서는 도메인에서 누가 이메일을 보내는지 알려줌으로써 이메일 프로그램에 대한 가시성을 높입니다.
  3. 보안: DMARC는 이메일 커뮤니티가 인증에 실패한 메시지를 처리하기 위한 일관된 정책을 수립하는 데 도움이 됩니다. 이를 통해 이메일 생태계가 전체적으로 더 안전하고 신뢰할 수 있게 됩니다.

DMARC 레코드는 어떻게 생겼나요?

터미널 에 <dig txt_dmarc.sendgrid.net >을 입력하면 DMARC 레코드가 어떻게 생겼는지 알 수 있습니다 . https://www.valimail.com/으로 이동하여 1개가 게시된 도메인에 대한 DMARC 레코드를 볼 수도 있습니다.

다음은 DMARC 레코드의 예입니다. 이것은 SendGrid의 DMARC 레코드입니다.

v=DMARC1\;p=없음\;rua=mailto:[email protected]\;ruf=mailto:[email protected]\;rf=afrf\;pct=100

부숴버리자

"v=DMARC1"

버전 – 수신 서버가 메시지를 수신한 도메인에 대한 DNS 레코드를 스캔할 때 찾는 식별자입니다. 도메인에 v=DMARC1로 시작하는 txt 레코드가 없으면 수신 서버는 DMARC 검사를 실행하지 않습니다.

"p=없음"

정책 – DMARC 레코드에서 선택한 정책은 참여하는 수신자 이메일 서버에 SPF 및 DKIM을 통과하지 않았지만 도메인에서 보낸다고 주장하는 메일을 어떻게 처리할지 알려줍니다. 이 경우 정책은 "없음"으로 설정됩니다. 설정할 수 있는 정책에는 3가지 유형이 있습니다.

    1. p=none – 수신자에게 부적격 메일에 대해 아무 작업도 수행하지 않고 위반에 대해 DMARC 레코드의 mailto:로 이메일 보고서를 보내도록 지시합니다.
    2. p=quarantine – 받는 사람에게 부적격 메일을 격리하도록 지시합니다. 이는 일반적으로 "스팸 폴더로 직접 보내기"를 의미합니다.
    3. p=reject – 수신자에게 도메인에 대한 자격이 없는 메일을 완전히 거부하도록 지시합니다. 이 기능을 활성화하면 도메인에서 100% 서명한 것으로 확인된 메일만 받은편지함을 볼 수 있습니다. 통과하지 못한 메일은 거부(반송되지 않음)되므로 가양성을 잡을 방법이 없습니다.

“rua= mailto:[email protected] ”

이 부분은 수신 서버에 DMARC 실패에 대한 집계 보고서를 보낼 위치를 알려줍니다. 집계 보고서는 DMARC 레코드가 속한 도메인의 관리자에게 매일 전송됩니다. 여기에는 DMARC 실패에 대한 상위 수준 정보가 포함되지만 각 사고에 대한 세부 정보는 제공되지 않습니다. 선택한 이메일 주소가 될 수 있습니다.

"ruf=mailto:[email protected]"

이 부분은 수신 서버에 DMARC 오류에 대한 포렌식 보고서를 보낼 위치를 알려줍니다. 이러한 포렌식 보고서는 DMARC 레코드가 속한 도메인의 관리자에게 실시간으로 전송되며 각 개별 장애에 대한 세부 정보가 포함됩니다. 이 이메일 주소는 DMARC 레코드가 게시된 도메인의 주소여야 합니다.

" rf=afrf"

보고 형식. 이 부분은 보험 계약자가 원하는 보고 유형을 수신 서버에 알려줍니다. 이 경우 rf=afrf 는 집계 실패 보고 형식을 의미합니다.

"pct=100"

백분율 – 이 부분은 수신 서버에 DMARC 정책 사양에 따라야 하는 메일의 양을 알려줍니다. 1에서 100 사이의 숫자를 선택할 수 있습니다. 이 경우 p=가 거부로 설정되면 DMARC에 실패한 메일은 100% 거부됩니다.

DMARC 레코드에 포함될 수 있는 다른 여러 메커니즘이 있습니다. 몇 가지 주목할만한 사항은 다음과 같습니다.

"sp=" 이 부분은 수신 서버에 DMARC 정책을 하위 도메인에 적용할지 여부를 알려줍니다.

"adkim=" DKIM 정렬을 설정합니다. 엄격함을 "r"로 설정하거나 완화를 위해 "r"로 설정할 수 있습니다. Strict는 DKIM 서명의 d= 필드가 from 도메인과 정확히 일치하는 경우에만 DMARC 인증의 DKIM 부분이 통과함을 의미합니다. 완화로 설정된 경우 DKIM d= 필드가 보낸 사람 주소의 루트 도메인과 일치하는 경우 메시지는 DMARC 인증의 DKIM 부분을 전달합니다.

"ri=" DMARC 실패에 대한 집계 보고서를 수신하려는 빈도에 대한 간격을 설정합니다.

Twilio SendGrid로 DMARC를 어떻게 구현합니까?

DMARC 구현 작업을 진행하기 전에 모든 사용자를 위한 것은 아니라는 점에 유의하세요. 작은 도메인을 소유하고 있다면 도메인 없이도 괜찮을 것입니다. 그러나 과거에 피싱으로 문제가 발생한 적이 있거나 민감한 정보를 처리하는 재정적 비즈니스가 있는 경우 현명한 조치입니다.

명심해야 할 또 다른 사항은 DMARC 집계 및 포렌식 보고서가 기계가 읽을 수 있도록 설계되었다는 것입니다. 사람이 이해하기 어려울 수 있으므로 보고서를 수집하고 정보에 액세스하려면 DMARC 보고서 모니터링 서비스를 사용해야 합니다. Twilio SendGrid는 ValiMail과 파트너 관계를 맺었습니다.

구현을 결정하고 올바른 서비스를 선택했으면 DMARC를 설정하는 프로세스에는 5단계가 포함됩니다.

1. Sendgrid IP에서 발신자 인증으로 DKIM 및 SPF 배포

귀하의 계정에 대한 발신인 인증 절차를 완료하십시오. 이렇게 하면 Twilio SendGrid 계정을 통해 보낸 이메일이 고유한 도메인에 대해 DKIM 및 SPF 를 사용하여 올바르게 서명됩니다.

이 첫 번째 단계를 완료하는 방법을 잘 모르겠다면 여기 에서 도움말을 참조하십시오.

2. 허용된 도메인에 대한 적절한 DKIM 및 SPF 서명 확인

모든 것이 올바르게 작동하는지 확인하는 데 도움이 되는 몇 가지 테스트 이메일을 자신에게 보냅니다. 이메일 헤더의 DKIM 및 SPF 서명이 SendGrid 계정을 허용하는 데 사용한 도메인과 일치하는지 확인하려고 합니다. 두 가지가 모두 통과하는 한 비즈니스입니다!

3. DNS 등록 대행자와 함께 DMARC 레코드를 게시한 다음 결과를 모니터링합니다.

DNS 등록 대행자 내에서 수신자가 DMARC 기본 설정을 결정하는 데 사용할 수 있는 TXT 리소스 레코드를 생성해야 합니다. 이것은 도메인 호스트의 DNS 등록 대행자 내에서 수행되며, 이는 발신자 인증을 위해 DNS 레코드를 생성한 위치와 동일할 수 있습니다. 이 레코드는 하위 도메인이 아닌 도메인의 루트 수준에서 만들어집니다.

간단한 DMARC 레코드는 다음과 같습니다.

“v=DMARC1; p=quarantine; pct=100;
 rua=mailto:[email protected]”

"v=DMARC1; p=격리; pct=100; rua=mailto:[email protected]”*

  • v=DMARC1;
     DMARC 버전 1을 사용하도록 설정되어 있으며 현재 다른 버전은 없습니다. 따라서 항상 1을 설정합니다.
  • p=격리;*
     이 정책은 수신자에게 정규화되지 않은 메일을 QUARANTINE이라고 알려줍니다. 일반적으로 "이것을 스팸 폴더로 직접 보내십시오"를 의미합니다.
  • pct=100;
     이것은 수신자가 도메인에서 온 것이라고 주장하는 메시지의 100%를 평가하도록 지시합니다. 이는 1에서 100 사이의 숫자일 수 있습니다.
  • rua=mailto:[email protected]
     이는 수신자에게 [email protected] 으로 집계 보고서를 보내도록 지시합니다 . 밀접하게 모니터링되는 귀하가 제어하는 ​​이메일 주소로 설정하십시오.

*이 예에서는 p=quarantine 정책을 사용하지만 처음에는 항상 p=none 정책을 사용하여 시작하는 것이 좋습니다.

4. 받은 피드백을 분석하고 필요에 따라 메일 스트림을 조정합니다.

비정규 이메일이 DMARC에 참여하는 수신자에게 전송되고 수신되는 경우 수신자는 이러한 메시지에 대한 보고서를 생성하여 DMARC 레코드에 지정된 mailto: 주소로 다시 보냅니다.

이 보고서에는 도메인을 대신하여 메일을 보낼 수 있는 서비스를 정확히 평가하는 데 도움이 되는 정보가 있습니다.

다음은 2개의 메일에 대한 결과를 보여주는 1개의 레코드만 있는 샘플 보고서입니다. (나열된 SPF 및 DKIM auth_results는 s= 정렬에 관계없이 원시 결과입니다. 파일 이름 형식은 다음과 같습니다. filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp ". ” 확장자(예: receiver.org!sender.com!1335571200!1335657599.zip))

<report_metadata>

<org_name>receiver.com

[email protected]

<extra_contact_info>http://receiver.com/dmarc/support

<report_id>9391651994964116463

<날짜_범위>

1335571200

1335657599

<policy_published> sender.com

아르 자형

아르 자형

없음

없음

100

<source_ip>72.150.241.94

2 <policy_evaluated> 없음

불합격

통과하다

<header_from>sender.com

<인증 결과>

sender.com

불합격

<인간 결과>

sender.net

통과하다

<인간 결과>

sender.com

통과하다

*참고: 집계 보고서는 .zip 첨부 파일로 전송되므로 정의하는 주소가 이 파일 형식의 첨부 파일을 수락할 수 있는지 확인하십시오.

5. 학습한 대로 DMARC 정책 태그를 에스컬레이션합니다.

메일 스트림을 테스트하고 조정하여 도메인에 대해 이메일을 보내는 사람을 정확히 확인했으므로 이제 수준을 높일 차례입니다.

지금까지는 잘못된 행동에 대한 보고를 받기 위해 p=none 정책만 사용해야 했으며 이메일이 어디에서 오는지 잘 알고 있어야 합니다. 다음 단계는 DMARC 레코드에 대한 정책을 조정하여 수신자가 도메인에서 보낸 것으로 주장하는 메일을 처리하는 방법을 제어하기 시작하는 것입니다. 기억하다:

  • p=none – 위반 보고서를 받지만 수신자는 메시지 자체를 처리하는 한 아무 조치도 취하지 않습니다.
  • p=quarantine – 검증되지 않은 메일은 스팸으로 바로 이동하지만 복구할 수 있습니다. 이것은 메일이 오는 모든 위치를 알고 있지만 100% 확신할 때까지 자격이 없는 메시지를 '소프트페일'하려는 경우에 유용합니다.
  • p=reject – 도메인에 대해 이메일을 보내는 모든 서버와 서비스를 알고 있고 이러한 각 서비스에 대해 서명이 되어 있고 대담하게 주장하는 모든 항목이 그렇지 않으면 완전히 거부되기를 원하는 경우 이 옵션을 사용합니다. 인증되지 않은 메일은 수신자 메일 서버에서 완전히 삭제되어 다시는 볼 수 없습니다.

DMARC가 중요한 이유

DMARC 레코드는 이메일 인증의 중요한 발전입니다. 이것은 이메일 채널을 보호하기 위해 협력하는 이메일 발신자와 ISP의 또 다른 좋은 예일 뿐입니다. DMARC에 대해 자세히 알아보려면 조직 웹사이트(www.dmarc.org)를 방문하세요. 인증에 대해 자세히 알아보려면 이 블로그 게시물을 읽으십시오.

추가 리소스

  • DMARC.org의 FAQ
  • Yahoo의 DMARC 정책 업데이트
  • 최초의 야후와 지금은 AOL. DMARC를 준수하려면 무엇을 변경해야 합니까?