DMARC

DMARC
이 글은 이메일 인증 시스템에 대한 것입니다.텔레포니 접속점에 대해서는, 「분계점」을 참조해 주세요.
dMarc Broadcing과 혼동하지 마십시오.

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 전자 메일 인증 프로토콜입니다.일반적으로 이메일 스푸핑이라고 하는 무단 사용으로부터 도메인을 보호할 수 있도록 설계되었습니다.DMARC의 실장의 목적과 주된 성과는 비즈니스 이메일 침해 공격, 피싱 이메일, 이메일 사기 및 기타 사이버 위협 활동에서 도메인을 사용하는 것을 방지하는 것입니다.

DMARC DNS 엔트리가 퍼블리시 되면, 수신하는 전자 메일서버는, DNS 엔트리내의 도메인 소유자가 퍼블리시 한 지시에 근거해 착신 전자 메일을 인증할 수 있습니다.이메일이 인증에 합격하면 전송되어 신뢰할 수 있습니다.이메일이 체크에 불합격할 경우 DMARC 레코드에 보관된 지침에 따라 이메일이 배달, 검역 또는 거부될 수 있습니다.예를 들어, 하나의 전자 메일 전송 서비스가 메일을 배달하지만 "From: no-reply@<forwarding service>"[1]로 배달합니다.

DMARC는 기존의 2개의 전자 메일 인증 메커니즘, SPF(Sender Policy Framework)와 DMIM(DomainKeys Identified Mail)을 확장합니다.도메인 관리자 소유자는 DNS 레코드에 정책을 게시하여 도메인에서 전자 메일을 보낼 때 어떤 메커니즘(DKIM, SPF 또는 둘 다)을 사용할지 지정할 수 있습니다.또한 도메인에서 전자 메일을 보낼 때 어떤 메커니즘(DKIM, SPF 또는 둘 다)을 사용하는지,From:최종 사용자에게 표시되는 필드, 수신자가 장애에 대처하는 방법, 그리고 이러한 정책에 따라 실행되는 액션에 대한 보고 메커니즘.

DMARC는 Internet Engineering Task Force의 공개 문서에 정의되어 있습니다. 2015년 3월호 RFC7489는 "정보"[2]로 규정되어 있다.

DMARC 레코드에서[3] 사용할 수 있는 파라미터는 얼라인먼트모드나 rua/ruf 등, 수신인 메일서버로부터 DMARC 리포트를 매일 취득할 수 있는 파라미터가 많이 있습니다.

개요

DMARC 정책을 사용하면 송신자의 도메인이 자신의 전자 메일메시지가 SPF 및/또는 DKIM에 의해 보호되고 있음을 나타낼 수 있습니다.또, 이러한 인증 방법이 모두 통과하지 않았을 경우(메시지 거부 또는 검역 등)의 대처법을 수신자에게 지시할 수 있습니다.또한 이 정책은 전자 메일 수신기가 통과 [4]및/또는 실패한 메시지에 대해 보낸 사람의 도메인에 보고하는 방법을 지정할 수 있습니다.

이러한 정책은 TXT 레코드로 퍼블릭 Domain Name System(DNS; 도메인네임 시스템)에 게시됩니다.

DMARC는 이메일이 스팸인지 사기인지 여부를 직접 다루지 않습니다.대신 DMARC는 메시지가 DKIM 또는 SPF 검증을 통과할 뿐만 아니라 얼라인먼트를 통과할 것을 요구할 수 있습니다.DMARC에서는 메시지가 SPF 또는 DKIM을 통과해도 [5]얼라인먼트에 실패해도 실패할 수 있습니다.

DMARC 를 설정하면, 정규의 [6]송신원으로부터의 메시지의 전달 능력이 향상하는 일이 있습니다.

얼라인먼트

DMARC는 메시지 내의 도메인이 다음 중 하나인지 여부를 체크함으로써 동작합니다.From:필드('RFC5322'라고도 불립니다).From)[2]은 인증된 다른 도메인 이름과 "정렬"됩니다.SPF 또는 DKIM 얼라인먼트체크 중 하나에 합격하면 DMARC 얼라인먼트테스트에 합격합니다

정렬은 엄격 또는 완화로 지정할 수 있습니다.엄밀하게 정렬하려면 도메인 이름이 동일해야 합니다.쉽게 정렬하려면 최상위 "조직 도메인"이 일치해야 합니다.조직 도메인은 퍼블릭 DNS 접미사 목록을 확인하고 다음 DNS 레이블을 추가하면 찾을 수 있습니다.예를 들어 "com.au"과 "example.com.au"은 동일한 조직 도메인을 가집니다. 왜냐하면 "com.au"에서 고객에게 이름을 제공하는 레지스트라가 있기 때문입니다.DMARC 사양 당시에는 도메인 경계에 IETF 워킹그룹이 존재했지만 오늘날 조직 도메인은 퍼블릭서픽스 리스트에서만 취득할 [7]수 있습니다.

SPF 및 DKIM과 마찬가지로 DMARC는 도메인 소유자 개념, 즉 특정 DNS 도메인을 변경할 수 있는 엔티티를 사용합니다.

SPF 는, 송신측 서버의 IP 주소가 SMTP 에 표시되는 도메인의 소유자에 의해서 허가되고 있는 것을 확인합니다.MAIL FROM명령어를 입력합니다.(MAIL FROM 의 전자 메일 주소는, 바운스 주소, 봉투 송신원, 또는 RFC5321 이라고도 불립니다.메일 송신원).DMARC는 SPF 체크에 합격할 것을 요구할 뿐만 아니라 RFC5321을 체크합니다.Mail From은 5322와 일치합니다.보낸 사람.[2]

DKIM 에서는, 전자 메일 메시지의 일부를 암호화 서명할 수 있습니다.서명은 [From]필드를 커버해야 합니다.DKIM-Signature 메일 헤더 내에서d=(도메인) 및s=(셀렉터) 태그는 DNS에서 시그니처의 공개 키를 취득하는 위치를 지정합니다.유효한 서명은 서명인이 도메인 소유자이며 서명 적용 후 From 필드가 변경되지 않았음을 증명합니다.전자 메일 메시지에는 여러 개의 DKIM 서명이 있을 수 있습니다.DMARC에는 유효한 서명이 1개 필요합니다.d=태그는, 에 기재되어 있는 송신자의 도메인과 일치합니다.From:헤더 필드

DNS 레코드

DMARC 레코드는 서브 도메인라벨과 함께 DNS에 공개됩니다._dmarc,예를들면_dmarc.example.com이것을 SPF 와 비교합니다.example.com, 및 DKIM:selector._domainkey.example.com.

TXT 자원 레코드의 내용은 다음과 같습니다.name=value태그는 SPF 및 DKIM과 마찬가지로 세미콜론으로 구분됩니다.예를 들어 다음과 같습니다.

"v=DMARC1;p=none;sp=mailto:dmarcreports@example.com";pct=100;rua=mailto:dmarcreports@example.com;"

여기서,v버전입니다.p정책입니다(아래 참조).sp서브 도메인 정책,pct정책을 적용하는 "불량" 전자 메일의 비율입니다.rua는, 집약 리포트를 송신하는 URI 입니다.이 예에서는 example.com DNS 도메인을 제어하는 엔티티는 SPF 및/또는 DKIM 장애율을 감시하려고 하며 example.com의 서브 도메인에서 이메일이 전송될 것으로 예상하지 않습니다.서브도메인은 독자적인 DMARC 레코드를 퍼블리시할 수 있습니다.리시버는 조직 도메인레코드로 폴백하기 전에 체크 아웃 할 필요가 있습니다.

단계적 도입

이 프로토콜은 메일 관리자가 DMARC를 전혀 구현하지 않은 상태에서 양보하지 [8][9][10]않는 설정으로 점차적으로 전환할 수 있도록 다양한 래칫 또는 과도 상태를 제공합니다.단계적 채택의 개념은 DMARC의 목표가 가장 강력한 설정이라고 가정합니다.이것은 모든 도메인에서 해당되는 것은 아닙니다.이러한 메커니즘은 의도와 관계없이 유연성을 높일 수 있습니다.

정책.

우선 세 가지 정책이 있습니다.

  • none은 엔트리 레벨의 정책입니다.수신자가 특별히 취급할 필요는 없지만 도메인이 피드백 보고서를 수신할 수 있습니다.
  • quarantine은 수신자에게 DMARC 체크에 불합격한 메시지를 의심스럽게 처리하도록 요구합니다.메시지에 플래그를 지정하거나 스팸 폴더에 메시지를 배달하는 등 수신자마다 구현하는 방법이 다릅니다.
  • reject는 DMARC 체크에 실패한 메시지를 완전히 거부하도록 수신자에게 요구합니다.

게시된 정책은 DMARC 체크에 실패한 메시지의 일부에만 적용함으로써 경감할 수 있습니다.수신자는 간단한 Bernouli 샘플링 알고리즘에 의해 지정된 비율의 메시지를 선택하도록 요구됩니다.나머지 메시지에는 하위 정책이 적용됩니다.즉, none:p=quarantine, 격리는 다음과 같은 경우p=reject지정하지 않으면 pct는 기본적으로 메시지의 100%가 됩니다.케이스p=quarantine; pct=0;메일링 리스트 매니저에게 From: 필드를 강제로 다시 쓰도록 하기 위해 사용되고 있습니다.일부에서는, 다음의 경우에, From: 필드를 고쳐 쓰지 않는 경우도 있습니다.p=none를 클릭합니다.[11]

마지막으로 서브도메인 정책,sp=새로 추가된 no-domain 정책을[12] 사용하면 특정 서브도메인에 대한 정책을 조정할 수 있습니다.

리포트

DMARC는 두 가지 유형의 보고서를 생성할 수 있습니다.집약 리포트는, 다음의 지정된 주소로 송신됩니다.rua법의학 보고서는 다음 주소로 이메일로 전송됩니다.ruf 태그. 이러한 메일 주소는 URImailto 형식(예: mailto:worker@example.net )으로 지정해야 합니다.복수의 리포트 주소는 유효하며, 각각 완전한 URI 형식(쉼표로 구분)이어야 합니다.

대상 전자 메일 주소는 외부 도메인에 속할 수 있습니다.이 경우 타깃 도메인은 DMARC 레코드를 셋업하여 수신에 동의해야 합니다.그렇지 않으면 스팸 증폭에 대한 보고서를 악용할 수 있습니다.예를 들어 다음과 같이 입력합니다.receiver.example메일 메시지를 수신하다From: someone@sender.example신고하려고 합니다.발견되면ruf=mailto:some-id@thirdparty.example타겟이 관리하는 네임스페이스에서 다음과 같이 확인 DNS 레코드를 검색합니다.

sender.displaces.displaces 를 지정합니다._리포트.TXT "v=DMARC1;"의 _dmarc.thirdparty.dline

보고서 집약

집약 보고서는 보통 하루에 한 번씩 XML 파일로 전송됩니다.제목에서는 보고서가 생성된 DNS 도메인 이름을 나타내는 "Report Domain"과 보고서를 발행하는 엔티티인 "Submitter"가 언급됩니다.payload는 보고서 발행 리시버, Unix 스타일의 타임스탬프로서 보고된 기간의 시작 및 종료 에폭, 옵션 고유 식별자 및 가능한 압축(사용되는 경우)에 따라 달라지는 확장자 등 뱅으로 구분된 요소로 구성된 긴 파일 이름을 가진 첨부 파일에 있습니다..zip를 참조해 주세요.[13]

예를 들어 다음과 같습니다.example.com!example.org!1475712000!1475798400.xml.gz.

XML 콘텐츠는 보고서의 기반이 되는 정책과 보고서 메타데이터를 포함하는 헤더와 그 뒤에 다수의 레코드가 있습니다.레코드를 관계로서 데이터베이스에 격납해, 표 형식으로 표시할 수 있습니다.XML 스키마는 사양의[14] 부록 C에 정의되어 있으며, raw 레코드는 [15]dmarc.org에 예시되어 있습니다.여기서는 데이터의 특성을 보다 잘 전달하는 관계형 예를 계속 사용합니다.DMARC 레코드는 XSL 스타일시트를 적용하여 HTML로 직접 변환할 수도 있습니다.

집계 레코드의 DMARC 행이 표 형식으로 표시됩니다.
송신원 IP 세어보세요 처분 SPF DKIM 발신인 헤더 SPF 도메인(결과) DKIM 도메인(결과)
192.0.2.1 12 없음. ✓ 통과하다 ✓ 통과하다 example.org example.org (접수 패스) example.org (접수 패스)
192.0.2.1 1 없음. ✓ 통과하다 ✗ 실패하다 example.org example.org (접수 패스) example.org (실패)
192.0.2.28 42 없음. ✗ 실패하다 ✓ 통과하다 example.org example.org (실패) example.org (접수 패스) forwarder.example (© Pass )
192.0.2.82 21 없음. ✗ 실패하다 ✗ 실패하다 example.org documentlist.example(「패스」) example.org (실패) documentlist.example(「패스」)
...

행은 소스 IP 및 인증 결과에 따라 그룹화되어 각 그룹의 카운트만 통과합니다.SPF 및 DKIM이라는 라벨이 붙은 맨 왼쪽 결과 열에는 정렬을 고려한 DMARC별 결과가 표시됩니다.가장 오른쪽에는 유사한 라벨이 붙어 있으며 ID 정렬에 관계없이 메시지 전송에 참여한다고 주장하는 도메인 이름과 원래 프로토콜(SPF 또는 DKIM)에 따라 해당 클레임의 인증 상태를 괄호 안에 표시합니다.오른쪽에는 SPF가 최대 2회 표시될 수 있으며, 1회에는Return-Path:테스트 및 테스트 1회HELOtest: 메시지에 있는 시그니처별로 DKIM을 1회 표시할 수 있습니다.이 예에서 첫 번째 행은 example.org로부터의 메인 메일플로우를 나타내고 두 번째 행은 전송 중 사소한 변경으로 인한 시그니처 파손 등의 DKIM 글리치입니다.세 번째 행과 네 번째 행은 각각 전달자(Forwarder)와 메일링 리스트(Mailing List)의 일반적인 실패 모드를 나타냅니다.DMARC 인증이 실패한 것은 마지막 행뿐입니다.example.org 가 엄격한 정책을 지정한 경우 메시지 처리에 영향을 줄 수 있습니다.

디스포지션에는 메시지에 실제로 적용된 게시된 정책, 없음, 검역 또는 거부 정책이 반영됩니다.이와 함께 DMARC는 표에 나타나 있지 않지만 정책 오버라이드를 제공합니다.리시버가 요청된 정책과 다른 정책을 적용할 수 있는 몇 가지 이유는 이미 사양에 나와 있습니다.

전송되었다
같은 바운스 주소를 유지하면서 보통 DKIM을 깨지 않지만
표본 추출한
송신자는 정책을 메시지의 비율에만 적용하도록 선택할 수 있습니다.
신뢰할 수 있는 포워더
그 메시지는 지역적으로 알려진 소식통으로부터 도착했다
메일링 리스트
수신인은 경험적으로 메시지가 메일링 리스트에서 도착했다고 판단했습니다.
지역 정책
수신자는 분명히 자신이 좋아하는 정책을 자유롭게 적용할 수 있습니다.송신자에게 알리는 것은 멋진 일입니다.
다른.
위의 어느 것도 해당되지 않을 경우 설명 필드에서 더 많은 내용을 표시할 수 있습니다.

법의학 보고서

Failure Reports라고도 불리는 포렌식 리포트는 실시간으로 생성되며 SPF, DKIM 또는 둘 다에 실패한 개별 메시지의 수정된 복사본으로 구성됩니다.이 복사본은 에서 지정된 값에 따라 결정됩니다.fo태그. 남용 보고 형식의 확장판인 이 형식은 "message/rfc822" 또는 "text/rfc822-headers"를 포함하고 있다는 점에서 일반적인 바운스와 유사합니다.

법의학 보고서에는 다음 내용도 포함되어 있습니다.

  • 송신원 IP 주소
  • 보낸 사람 이메일 주소
  • 수신자 이메일 주소
  • 이메일 제목 줄
  • SPF 및 DKIM 인증 결과
  • 수령시간
  • 송신 호스트, 전자 메일메시지 ID, DKIM 시그니처 및 기타 커스텀헤더 [16]정보를 포함하는 전자 메일메시지 헤더

호환성.

포워더

전자 메일 전송에는 몇 가지 유형이 있으며, 그 중 일부는 SPF를 [17]손상시킬 수 있습니다.

메일링 리스트

메일 목록은 제목 헤더에 접두사를 추가하는 등 원래 작성자의 도메인 DKIM 서명이 제대로 파손되는 경우가 많습니다.몇 가지 해결 방법이 있으며,[18] 메일링 리스트 소프트웨어 패키지가 [19]해결 방법을 찾고 있습니다.

모든 메시지 수정 끄기

이 회피책은 표준 메일링 리스트워크플로를 유지하고 여러 대형 메일링 리스트 연산자에 의해 채택되지만, 바닥글과 제목 [20]접두사를 추가하는 리스트는 제외됩니다.이렇게 하려면 서명된 헤더의 순서 변경이나 변경을 방지하기 위해 메일링 소프트웨어를 신중하게 구성해야 합니다.잘못 설정된 전자 메일서버는 메일링 리스트로 송신된 메시지의 DKIM 에 List-id 를 넣을 수 있습니다.그 후, 리스트 오퍼레이터는 그것을 거부하거나 From: rewrite 를 실행합니다.

From:리라이트

가장 일반적이고 가장 침입이 적은 회피책 중 하나는 다음 명령어를 다시 쓰는 것입니다.From:헤더 필드그러면 원본 작성자의 주소를 다음에 추가할 수 있습니다.Reply-To:필드.[21] 다시 쓰기는 단순히 추가되는 것부터 가능합니다..INVALID[note 1] 도메인 이름에 불투명한 ID가 사용되는 임시 사용자 ID를 할당하여 사용자의 "실제" 전자 메일 주소를 목록에서 비공개로 유지합니다.또, 작성자와 리스트(또는 리스트 오퍼레이터)[22]의 양쪽 모두를 표시하도록 표시명을 변경할 수 있다.이러한 예는 각각 다음 중 하나에 해당될 것이다.

발신자: John Doe < user@example.com >발신인: John Doe <243576@mailinglist.example.org> 발신인: John Doe via Mailing List <list@mailinglist.example.org> 회신인: John Doe <user@example.com>

마지막 한 줄,Reply-To:작성자에 대한 회신 기능에 대응할 수 있도록 설계해야 합니다.이 경우 목록 회신 기능은 위의 변경으로 커버됩니다.From:헤더 필드이렇게 하면 그 필드의 원래 의미가 반전됩니다.

저자를 변경하는 것은 일반적으로 공평하지 않으며, 그 기준의 의미와 외관 사이의 예상된 관계를 깨뜨릴 수 있다.또한 자동 사용도 중단됩니다.메일링 리스트를 사용하여 작업을 조정하고 툴을 도입하는 커뮤니티가 있습니다.From:첨부 [23]파일에 대한 작성자 속성을 지정하는 필드입니다.

기타 회피책

래핑된 메시지를 이해하는 전자 메일 클라이언트를 사용하는 사용자에게 메시지를 래핑하는 것이 좋습니다.변경을 하지 않는 것이 아마도 가장 명백한 해결책일 것입니다.단, 일부 국가에서는 변경이 법적으로 요구되고 있어 통상적으로 SPF 인증을 상실하면 전체적인 인증이 더욱 [24]취약해질 수 있습니다.

[ Sender ]필드

에 대한 변경From:DKIM 얼라인먼트를 통과하기 위한 헤더필드는 RFC 5322 섹션 3.6.2에 준거하지 않는 메시지를 가져올 수 있습니다.「From:」필드는, 메시지의 작성자, 즉, 메시지의 기입을 담당하는 사람의 메일 박스를 지정합니다.우편함은 작성자의 이메일 주소를 나타냅니다.그Sender:헤더는 다른 사람을 대신하여 전자 메일이 발송되었음을 나타낼 수 있지만 DMARC는 보낸 사람 도메인 정책만 확인하고 보낸 사람 [note 2]도메인은 무시합니다.

ADSP와 DMARC[5] 모두 기술 이외의 이유로 Sender 필드 사용을 거부합니다.많은 사용자 에이전트는 이 필드를 수신자에게 표시하지 않습니다.

역사

DMARC 사양서 초안은 2012년 [25]1월 30일부터 유지되고 있습니다.

2013년 10월 GNU Mailman 2.1.16은 DMARC 정책에 따라 도메인에서 포스터를 처리할 수 있는 옵션과 함께 출시되었습니다.p=reject변경은 (순수히 트랜잭션 메일 도메인이 아닌) 인간 사용자와의 도메인에 제한적인 정책이 적용될 경우 예상되는 상호운용성 문제를 예측하려고 했습니다.[19]

2014년 4월 Yahoo는 DMARC 정책을 다음과 같이 변경했습니다.p=reject이로 인해 여러 메일목록에서 [26]오류가 발생합니다.며칠 후 AOL은 DMARC 정책도 변경했습니다.p=reject이러한 이동으로 인해 상당한 중단이 발생했으며, 이러한 우편함 공급자는 보안 장애에 따른 비용을 제3자에게 [28]강요하고 있다는 비난을 받아 왔습니다.[27]2020년 현재 공식 DMARC Wiki의 FAQ에는 엄격한 DMARC [29]정책을 가진 도메인으로부터의 메시지를 처리하기 위한 메일링 리스트에 대한 몇 가지 제안이 포함되어 있습니다.이 중 가장 널리 구현되고 있는 것은 메일링 리스트가 "From" 헤더를 자체 도메인의 주소로 변경하는 것입니다.

IETF 작업 그룹은 DMARC 문제를 해결하기 위해 2014년 8월에 구성되었으며, 상호 운용성 우려에서 시작하여 개정된 표준 사양 및 [30]문서를 계속 사용할 수 있습니다.한편, 기존의 DMARC 규격은 많은 사람들이 동의하고 실행하는 편집 상태에 도달했다.2015년 3월에 [31]RFC 7489로 "정보"(비표준) 카테고리에 있는 독립 제출 스트림에서 발행되었다.

2017년 3월, 연방거래위원회는 [32]기업별 DMARC 사용에 관한 연구를 발표했다.조사 결과 569개 기업 중 약 3분의 1이 DMARC 구성을 구현했으며, 10% 미만이 DMARC를 사용하여 서버에 인증되지 않은 메시지를 거부하도록 지시했으며, 대다수가 SPF를 구현한 것으로 나타났습니다.

기부자

DMARC 사양의 기여자는 다음과 같습니다.[33][34]

「 」를 참조해 주세요.

메모들

  1. ^ INVALID는 RFC 2606에서 이러한 용도로 예약된 최상위 도메인입니다.
  2. ^ RFC 4871의 섹션 B.1.4 및 B.2.3에서 (DMARC가 아닌 DKIM의 컨텍스트에서) 리메일러에 의한 Sender 필드의 사용에 대해 설명합니다.

레퍼런스

  1. ^ "FAQ". ForwardEmail. Retrieved 15 June 2020. If a sender has configured DMARC on their domain such that usual forwarding would fail, then we use this 'friendly from' rewrite approach to ensure the email lands in your inbox instead of being rejected.
  2. ^ a b c Murray Kucherawy; Elizabeth Zwicky (18 March 2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF. doi:10.17487/RFC7489. RFC 7489.
  3. ^ "Authentication". MutantMail. Retrieved 20 January 2022. DMARC extends the SPF and DKIM protocols for Email Authentication and prevent spoofing
  4. ^ Terry Zink (27 September 2016). "How we moved microsoft.com to a p=quarantine DMARC record". MSDN blog. If that sounds like a lot of work, that’s because it was
  5. ^ a b Kucherawy, M.; Zwicky, E. (15 July 2013). "Domain-based Message Authentication, Reporting and Conformance (DMARC) [draft 01]". IETF. Appendix A.3, Sender Header Field. Retrieved 24 May 2016.
  6. ^ "Bulk Senders Guidelines – Gmail Help". support.google.com. Retrieved 24 April 2015.
  7. ^ John Levine (2 November 2017). "Use of the public suffix list". Mailman developers (Mailing list).
  8. ^ "Tutorial: Recommended DMARC rollout". google.com.
  9. ^ "Implementation Guidance: Email Domain Protection". cyber.gc.ca. 12 August 2021.
  10. ^ "User Guide for Cisco Domain Protection" (PDF). cisco.com. 25 May 2021.
  11. ^ Jonathan Kamens (9 October 2018). ""p=none" vs. "p=quarantine; pct=0"" (Mailing list).
  12. ^ Scott Kitterman (26 July 2021). Tim Wicinski (ed.). Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains. IETF. doi:10.17487/RFC9091. RFC 9091.
  13. ^ "What is the rationale for choosing ZIP for the aggregate reports?". DMARC.org. 2012. Retrieved 3 April 2019. Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft
  14. ^ Murray S. Kucherawy; Elizabeth Zwicky, eds. (March 2015). "DMARC XML Schema". Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF. sec. C. doi:10.17487/RFC7489. RFC 7489. Retrieved 3 March 2019.
  15. ^ "I need to implement aggregate reports, what do they look like?". DMARC.org. Retrieved 26 May 2016.
  16. ^ "The Ultimate Guide to DMARC Reporting in 2022". 23 August 2019.
  17. ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (September 2016). "Alias". Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. IETF. sec. 3.2.1. doi:10.17487/RFC7960. RFC 7960. Retrieved 14 March 2017.
  18. ^ dmarc.org 위키
  19. ^ a b Mark Sapiro (16 October 2013). "Mailman and DMARC". list.org. Retrieved 13 August 2015.
  20. ^ "Upcoming changes for lists.debian.org". lists.debian.org.
  21. ^ Al Iverson (9 April 2014). "Spam Resource: Run an email discussion list? Here's how to deal with DMARC". spamresource.com. Retrieved 18 April 2014.
  22. ^ "How Threadable solved the DMARC problem". Threadable Blog. Retrieved 21 May 2016.
  23. ^ Theodore Ts'o (18 December 2016). "Realistic responses to DMARC". IETF-Discussion (Mailing list). Retrieved 14 March 2017. The fact that the from field is not rewritten is IMPORTANT because rewriting the from field would break the 'git am' command, since it uses the From: field to fill in the git commit's from field
  24. ^ John Levine (31 May 2014). "Mitigating DMARC damage to third party mail". wiki. ASRG. Retrieved 1 June 2014.
  25. ^ "이력", dmarc.org
  26. ^ Lucian Constantin (8 April 2014). "Yahoo email anti-spoofing policy breaks mailing lists". PC World. Retrieved 15 April 2014.
  27. ^ Vishwanath Subramanian (22 April 2014). "AOL Mail updates DMARC policy to 'reject'". AOL. Archived from the original on 13 August 2015. Retrieved 13 August 2015.
  28. ^ John Levine (13 August 2016). "DMARC and ietf.org". IETF (Mailing list). Retrieved 10 October 2016.
  29. ^ "FAQ in DMARC wiki". Retrieved 15 July 2020.
  30. ^ "WG Action: Formed Domain-based Message Authentication, Reporting & Conformance (dmarc)". IETF-Announce (Mailing list). 11 August 2014. Retrieved 10 October 2016.
  31. ^ "DMARC FAQ". dmarc.org.
  32. ^ "Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication" (PDF). Federal Trade Commission. 3 March 2017.
  33. ^ Kucherawy, Murray; Zwicky, Elizabeth. "Acknowledgements". Domain-based Message Authentication, Reporting, and Conformance (DMARC). sec. E. I-D draft-kucherawy-dmarc-base-01.
  34. ^ DMARC 관계자(PDF)
  35. ^ Vitaldevara, Krish (10 December 2012). "Outlook.com increases security with support for DMARC and EV certificates". Outlook Blog. Microsoft. Retrieved 12 December 2012.
  36. ^ Martin, Franck (20 September 2012). "DMARC: a new tool to detect genuine emails". LinkedIn Engineering Blog. Linkedin. Retrieved 17 August 2013.
  37. ^ Josh Aberant (21 February 2013). "Introducing DMARC for Twitter.com emails". twitter.com. Retrieved 10 April 2014.
  38. ^ a b c d e f g "History – dmarc.org". dmarc.org. Retrieved 23 September 2020.

외부 링크