이메일 인증 모범 사례 - SPF, DKIM, DMARC를 구축하는 최적의 방법
목차
소개
이 가이드에서는 현재 사용 중인 3가지 주요 이메일 인증 기술인 SPF, DKIM, DMARC에 대해 설명하고 구현의 다양한 측면을 살펴봅니다. 몇 가지 실제 이메일 아키텍처 상황과 Cisco Email Security 제품군에서 구현하기 위한 가이드라인에 대해 설명합니다. 이 가이드는 실습 모범 사례 가이드이므로 복잡한 자료는 생략합니다. 필요한 경우 제시된 사항을 쉽게 이해할 수 있도록 특정 개념을 간소화하거나 요약했습니다.
제품 정보 요구 사항
이 가이드는 높은 수준의 문서입니다. 제시된 자료를 이해하려면 Cisco Email Security Field Engineer 인증 수준의 Cisco Email Security Appliance에 대한 제품 지식을 보유해야 합니다. 또한 DNS 및 SMTP에 대한 뛰어난 수행 및 운영 능력을 갖추어야 합니다. SPF, DKIM, DMARC의 기본 사항을 잘 알고 있으면 도움이 됩니다.
이메일 인증 – 요약 개요
SPF(Sender Policy Framework)
Sender Policy Framework는 2006년에 RFC4408로 처음 게시되었습니다. 현재 버전은 RFC7208에 지정되어 있으며 RFC7372에 업데이트됩니다. 기본적으로 도메인 소유자가 DNS를 사용하여 수신자에게 합법적인 이메일 소스를 광고할 수 있는 간단한 방법을 제공합니다. SPF는 주로 반환 경로(MAIL FROM) 주소를 인증하지만, 사양에서는 SMTP HELO/EHLO 인수(SMTP 대화 중에 전송되는 발신자 게이트웨이의 FQDN)도 인증하도록 권장하며 메커니즘을 제공합니다.
SPF는 간단한 구문의 TXT 유형 DNS 리소스 레코드를 사용합니다.
spirit.com text = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"
위의 Spirit Airlines 레코드는 특정 /24 서브넷, FQDN으로 식별된 두 대의 시스템, Microsoft Office365 환경으로부터 수신되는 @spirit.com 주소의 이메일이 허용됩니다. 끝에 있는 "~all" 한정자는 수신자에게 다른 소스를 SPF의 두 가지 실패 모드 중 하나인 소프트 실패로 간주하도록 지시합니다. 발신자는 실패한 메시지에 대해 수신자가 수행해야 하는 작업이 아니라 실패의 정도를 지정합니다.
한편 Delta에서는 다른 SPF 방식을 사용합니다.
delta.com text = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"
Delta에서는 필요한 DNS 쿼리 수를 최소화하기 위해 모든 SMTP 게이트웨이를 나열하는 단일 "A" 레코드를 생성했습니다. 또한 “_spf.vendor.delta.com”에서 벤더에 대해 별도의 SPF 레코드를 제공합니다. 또한 SPF("-all" 한정자)로 인증되지 않은 모든 메시지의 하드 실패에 대한 지침도 포함됩니다. 벤더의 SPF 레코드를 추가적으로 조회할 수 있습니다.
_spf.vendor.delta.com text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"
따라서 예를 들어 Air France의 이메일 게이트웨이로부터 발신자가 @delta.com인 이메일이 합법적으로 수신될 수 있습니다.
반면 United는 훨씬 단순한 SPF 체계를 사용합니다.
united.com text = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"
자체 기업 메일 게이트웨이 외에 이메일 마케팅 제공자("usa.net"및 "enviaremails.com.br"), 레거시 Continental Air Lines 게이트웨이, MX 레코드에 나열된 모든 항목("MX" 메커니즘)을 포함합니다. MX(도메인의 수신 메일 게이트웨이)가 발신과 동일하지 않을 수 있습니다. 소규모 기업의 경우에는 대개 동일하지만 대규모 조직에서는 수신 메일을 처리하는 별도의 인프라와 발신 메일 전달을 처리하는 별도의 인프라가 있습니다.
또한 위의 모든 예에서는 추가 DNS 참조("include" 메커니즘)를 광범위하게 활용합니다. 그러나 성능상의 이유로 SPF 사양에서는 최종 레코드를 검색하는 데 필요한 총 DNS 조회 횟수가 10회로 제한됩니다. DNS 재귀 수준이 10개가 넘는 SPF 조회는 실패합니다.
DKIM(Domain Keys Identified Mail)
RFC 5585, 6376 및 5863에 지정된 DKIM은 Yahoo's DomainKeys 및 Cisco's Identified Internet Mail이라는 두 가지 역사적 제안이 통합된 것입니다. 이를 통해 발신자는 편리하게 발신 메시지에 암호로 서명하고 이메일 헤더("DKIM-Signature")에 (다른 확인 메타데이터와 함께) 서명을 첨부할 수 있습니다. 발신자가 DNS에 공개 키를 게시하므로 모든 수신자가 키를 쉽게 검색하고 서명을 확인할 수 있습니다. DKIM은 물리적 메시지의 소스를 인증하지 않지만 소스가 발신자 조직의 개인 키를 소유하고 있는 경우 자신을 대신하여 이메일을 보낼 암묵적인 권한이 있다는 사실을 이용합니다.
DKIM을 구현하기 위해 전송 조직은 하나 이상의 공개 키 쌍을 생성하고 공개 키를 DNS에 TXT 레코드로 게시합니다. "선택기"에서 각 키 쌍을 참조하므로 DKIM 검증자는 키를 구분할 수 있습니다. 발신 메시지에 서명되고 DKIM-Signature 헤더가 삽입됩니다.
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;
b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=
서명 형식은 매우 간단합니다. "a" 태그는 서명에 사용되는 알고리즘을 지정하고, "c"는 사용되는 정규화 체계를 지정하며 [1], "s"는 선택기 또는 키 참조, "d"는 서명 도메인입니다. 이 DKIM-Signature 헤더의 나머지 부분은 메시지 전용입니다. "h"는 서명된 헤더를 나열하고 "i"는 서명 사용자의 ID를 나열하며, 마지막으로 헤더가 두 개의 별도의 해시로 끝납니다. "bh"는 서명된 헤더의 해시이고 "b"는 메시지 본문의 해시 값입니다.
DKIM 서명 메시지를 수신하면 수신자는 다음 DNS 쿼리를 구성하여 공개 키를 조회합니다.
<selector>._domainkey.<signing domain>
DKIM-Signature 헤더에 지정된 대로 수행합니다. 위의 예에서 쿼리는 “united._domainkey.news.united.com”입니다.
united._domainkey.news.united.com 텍스트 = "g=*\; k=rsa\; n=" "연락처" "postmaster@responsys.com" "with" "any" "질문" "관련" "this" "서명" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjl gkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\;"
반환된 DNS 레코드에는 키 및 기타 선택적 매개변수가 포함되어 있습니다. [2]
DKIM의 주요 문제점은 초기 사양에서 발신자가 DKIM을 사용하는 광고를 허용하지 않았다는 점입니다. 따라서 메시지에 서명이 없는 경우 수신자는 메시지가 서명되어 있어야 하며 이 경우 인증 메시지가 아닐 가능성이 높음을 쉽게 알 수 없습니다. 하나의 조직에서 여러 선택기를 사용할 수 있으며 실제로 대부분의 조직이 여러 선택기를 사용하기 때문에 도메인이 DKIM에 기반하는지 여부를 "추측"하는 것이 쉽지 않습니다. 이 문제를 해결하기 위해 별도의 표준인 Author Domain Signing Practices가 개발되었지만, 낮은 사용량과 기타 문제로 인해 2013년에 후속 솔루션 없이 지원이 중단되었습니다.
DMARC(Domain-Based Message Authentication, Reporting And Conformance)
DMARC는 설명하는 세 가지 이메일 인증 기술 중 가장 최신 기술로, SPF와 DKIM의 단점을 모두 해결하기 위해 특별히 개발되었습니다. 다른 두 가지 기술과 달리, 메시지의 Header From을 인증하고 다른 두 가지 기술이 이전에 수행한 확인에 연결합니다. DMARC는 RFC7489에 지정되어 있습니다.
SPF 및 DKIM에 대한 DMARC의 강점은 다음과 같습니다.
- 사용 가능한 모든 ID(HELO, MAIL FROM 및/또는 DKIM 서명 도메인)가 From 헤더와 일치(정확하게 일치 또는 종속)하는지 확인
- 발신자 도메인 소유자가 수신자에게 실패한 메시지를 반드시 처리해야 하는 방식에 대한 정책을 지정할 수 있는 수단 제공
- 발신자 도메인 소유자에게 실패한 메시지를 알릴 수 있는 피드백 기능을 제공하여 SPF/DKIM/DMARC 정책 할당에서 피싱 캠페인 또는 오류를 쉽게 식별할 수 있습니다.
DMARC는 간단한 DNS 기반 정책 배포 메커니즘도 사용합니다.
_dmarc.aa.com text = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"
DMARC 정책 사양의 유일한 필수 태그는 "p"이며, 실패한 메시지에 사용할 정책을 지정합니다. 없음, 격리, 거부 중 하나일 수 있습니다.
가장 자주 사용되는 선택적 매개 변수는 보고와 관련이 있습니다. "rua"는 특정 도메인에서 온 것으로 간주되는 모든 실패 메시지에 대한 일일 집계 보고서를 보낼 URL(mailto: 또는 POST 메서드를 사용하는 http:// URL)을 지정합니다. "ruf"는 모든 실패 메시지에 대해 즉시 상세한 실패 보고서를 제출할 URL을 지정합니다.
사양에 따라 수신자는 알려진 정책을 반드시 준수해야 합니다. 그렇지 않은 경우 집계 보고서에서 발신자 도메인 소유자에게 반드시 알려야 합니다.
DMARC의 중심 개념은 식별자 일치입니다. 식별자 일치는 메시지가 DMARC 확인을 통과할 수 있는 방법을 정의합니다. SPF 및 DKIM 식별자는 개별적으로 일치되며 메시지는 DMARC를 전체적으로 통과하려면 메시지가 식별자를 통과해야 합니다. 그러나 한 일치는 통과하고 다른 일치는 실패하는 경우에도 발신자가 실패 보고서를 생성하도록 요청할 수 있는 DMARC 정책 옵션이 있습니다. 위의 예에서 “fo” 태그가 “1”로 설정된 것을 확인할 수 있습니다.
메시지는 DKIM 또는 SPF 식별자 일치를 엄격한 방식과 완화된 방식으로 준수할 수 있습니다. 엄격한 준수는 Header From의 FQDN이 DKIM 서명의 서명 도메인 ID("d" 태그) 또는 SPF에 대한 MAIL FROM SMTP 명령의 FQDN과 완전히 일치해야 함을 의미합니다. 반면 완화된 준수에서는 Header From FQDN을 앞서 언급한 두 가지의 하위 도메인으로 지정할 수 있습니다. 이는 이메일 트래픽을 서드파티에 위임할 때 중요한 영향을 미치며, 이 문서의 뒷부분에서 설명합니다.
SPF 구축 고려 사항
수신기용 SPF
SPF 확인은 Cisco Email Security 어플라이언스 또는 Cloud Email Security 가상 어플라이언스에서 쉽게 구성할 수 있습니다. 이 문서의 나머지 부분에서 ESA에 대한 참조에는 CES도 포함됩니다.
SPF 확인은 Mail Flow Policies(메일 플로우 정책)에서 구성됩니다. 이 작업을 전역적으로 실행하는 가장 쉬운 방법은 해당 리스너의 Default Policy Parameters(기본 정책 매개변수) 섹션에서 활성화하는 것입니다. 수신 메일 수집과 발신 메일 수집에 동일한 리스너를 사용하는 경우 "RELAYED" 메일 플로우 정책에 SPF 확인이 "Off"로 설정되어 있는지 확인하십시오.
SPF에서는 정책 작업의 지정을 허용하지 않으므로 SPF 확인(및 DKIM, 뒷부분 참조)은 메시지를 확인하고 수행된 각 SPF 검사에 대해 헤더 집합을 삽입합니다.
Received-SPF: Pass(mx1.hc4-93.c3s2.smtpi.com: 도메인
united.5765@envfrm.rsys2.com designates 12.130.136.195 as
permitted sender) identity=mailfrom;
client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;
envelope-from="united.5765@envfrm.rsys2.com";
x-sender="united.5765@envfrm.rsys2.com";
x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: 없음(mx1.hc4-93.c3s2.smtpi.com: 발신자 없음)
authenticity information available from domain of
postmaster@omp.news.united.com) identity=helo;
client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;
envelope-from="united.5765@envfrm.rsys2.com";
x-sender="postmaster@omp.news.united.com";
x-conformance=sidf_compatible
이 메시지의 경우 SPF에서 두 개의 "ID"를 확인했습니다. "mailfrom"은 사양에 따라, "helo"는 동일한 지침에 따라 확인되었습니다. "mailfrom"은 SPF 규정 준수와 관련이 있지만 일부 수신자는 HELO ID에 대한 SPF 레코드를 포함하지 않는 발신자를 승인할 수 있으므로 메시지는 공식적으로 SPF를 전달합니다. 따라서 SPF 레코드에 발신 메일 게이트웨이의 호스트 이름을 포함하는 것이 좋습니다.
메일 플로우 정책에서 메시지를 확인하면 수행할 작업을 구성하는 것은 로컬 관리자의 책임입니다. 이 작업은 메시지 필터 규칙 SPF-status() [3]를 사용하거나, 이 규칙을 사용하여 수신 콘텐츠 필터를 만들고 적절한 수신 메일 정책에 적용하여 수행됩니다.
그림 1: SPF 확인 콘텐츠 필터 조건
권장되는 필터 작업은 실패하는 메시지(SPF 레코드의 "-all") 및 정책 격리에서 소프트 실패(SPF 레코드의 "~ all")하는 메시지를 격리하기 위한 것이지만 이는 보안 요구 사항에 따라 달라질 수 있습니다. 일부 수신자는 실패한 메시지에 태그를 지정하거나 눈에 보이는 조치를 취하지 않고 관리자에게 보고합니다.
최근 SPF 인기가 급격히 증가했지만 많은 도메인에서 불완전하거나 잘못된 SPF 레코드를 게시하고 있습니다. 만약을 위해 모든 SPF 실패 메시지를 격리하고 얼마 동안 격리를 모니터링하여 "오탐"이 없는지 확인하는 것이 좋습니다.
다른 도메인 또는 서드파티용 이메일 서비스를 제공하는 경우
서드파티용 이메일 전달 또는 호스팅 서비스를 제공하는 경우, 메시지를 자신의 SPF 레코드로 전달하는 데 사용하는 호스트 이름 및 IP 주소를 추가해야 합니다. 가장 쉬운 방법은 제공자가 "umbrella" SPF 레코드를 생성하고 고객이 SPF 레코드에 "include" 메커니즘을 사용하도록 하는 것입니다.
suncountry.com text = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20.247.57 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exacttarget.com ~all"
보시다시피, Sun Country에서는 이메일 일부를 자체적으로 제어하고 있지만 마케팅 이메일은 서드파티로 아웃소싱됩니다. 참조된 레코드를 클릭하면 마케팅 메일 서비스 제공자가 사용하는 현재 IP 주소 목록이 표시됩니다.
cust-spf.exacttarget.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 -all"
이러한 유연성 덕분에 이메일 서비스 제공자는 DNS 레코드를 수정하기 위해 각 고객에게 연락하지 않고도 확장할 수 있습니다.
서드파티 이메일 서비스를 사용하는 경우
이전 단락과 마찬가지로, 서드파티 이메일 서비스를 사용 중이며 SPF 확인이 완료된 메일 플로우를 설정하려는 경우에는 SPF 레코드를 자신의 SPF 레코드에 포함해야 합니다.
jetblue.com descriptive text "v=spf1 include:_spf.qualtrics.com ?all"
JetBlue는 Qualtrics 분석 서비스를 사용하며, Qualtrics의 올바른 SPF 레코드를 포함하기만 하면 됩니다. 마찬가지로 대부분의 다른 ESP는 고객 레코드에 포함할 SPF 레코드를 제공합니다.
ESP 또는 이메일 마케팅 담당자가 SPF 레코드를 제공하지 않는 경우 발신 메일 게이트웨이를 사용자의 목록에 직접 나열해야 합니다. 그러나 이러한 레코드를 정확하게 유지하는 것은 사용자의 책임이며, 제공자가 게이트웨이를 추가하거나 IP 주소 또는 호스트 이름을 변경하면 메일 플로우가 위태로워질 수 있습니다.
SPF를 의식하지 않는 서드파티의 추가 위험은 리소스 공유에서 발생합니다. ESP가 동일한 IP 주소를 사용하여 여러 고객의 이메일을 전달하는 경우, 한 고객이 동일한 인터페이스를 통해 전달하는 다른 고객인 것처럼 가장하여 SPF 유효 메시지를 생성하는 것이 기술적으로 가능합니다. 따라서 SPF 제한을 적용하기 전에 MSP의 보안 정책 및 이메일 인증에 대한 인식을 조사해야 합니다. SPF가 인터넷상의 기본적인 신뢰 메커니즘 중 하나임을 고려할 때 질문에 대한 답이 없을 경우 MSP 선택을 재고하는 것이 좋습니다. 보안뿐 아니라 MSP에서 사용하는 SPF, DKIM, DMARC 및 기타 발신자 모범 사례 [4]도 제공이 보장됩니다. MSP가 이 모범 사례를 따르지 않거나 잘못 따를 경우, 대형 수신 시스템에서 신뢰도가 낮아지고 메시지가 지연되거나 차단될 수 있습니다.
이메일 트래픽이 없는 (하위) 도메인
오늘날 대부분의 조직은 마케팅 목적으로 여러 도메인을 소유하고 있지만 기업 이메일 트래픽에는 주로 하나만 사용합니다. SPF가 프로덕션 도메인에 올바르게 구축되어 있더라도 악의적인 공격자는 조직의 ID를 스푸핑하기 위해 이메일에 주로 사용되지 않는 다른 도메인을 계속 사용할 수 있습니다. SPF는 DNS에 “v=spf1 –all”을 게시하고 이메일 트래픽을 생성하지 않는 모든 도메인(및 하위 도메인)에 대해 특수한 "deny all" SPF 레코드를 통해 이러한 문제가 발생하는 것을 방지할 수 있습니다. SPF Council 웹사이트 openspf.org를 대표적인 예로 들 수 있습니다.
SPF 위임은 단일 도메인에 대해서만 유효하므로, 이메일을 생성하지 않을 수 있는 사용 중인 하위 도메인에 대해서도 "deny all" SPF 레코드를 게시해야 합니다. 프로덕션 도메인에 "정기적인" SPF 레코드가 있더라도 트래픽이 없는 하위 도메인에 "deny all" 레코드를 추가하려면 추가 작업을 수행해야 합니다. 다시 한 번 강조하지만, 수신이 전송과 같지 않다는 점을 잊지 마십시오. 도메인은 이메일을 수신하는 것이 가장 좋은 방법일 수 있지만 소스가 될 수는 없습니다. 단기적인 마케팅 도메인(예: 이벤트, 기간 한정 프로모션, 제품 출시)의 경우 특히 그렇습니다. 여기서 해당 도메인으로 수신되는 이메일이 프로덕션 도메인으로 전달되고 해당 이메일에 대한 모든 응답이 프로덕션 도메인으로부터 전달됩니다. 이러한 단기 도메인에는 유효한 MX 레코드가 있지만 이메일 소스가 없는 것으로 식별하는 SPF 레코드가 있어야 합니다.
DKIM 구축 고려 사항
수신기용 DKIM
ESA에서 DKIM 확인을 구성하는 것은 SPF 확인과 유사합니다. 메일 플로우 정책의 기본 정책 매개변수에서 DKIM 확인을 "On"으로 전환하면 됩니다. DKIM은 정책 사양을 허용하지 않으므로 서명이 확인되고 "Authentication-Results" 헤더가 삽입됩니다.
Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified) header.i=MileagePlus@news.united.com
DKIM 확인 결과를 기반으로 하는 모든 작업은 콘텐츠 필터를 통해 수행해야 합니다.
그림 2: DKIM 확인 콘텐츠 필터 조건
DKIM은 간단한 SPF와 달리 실제 메시지 텍스트를 조작하므로 일부 매개변수가 제한될 수 있습니다. 원하는 경우 DKIM 확인 프로파일을 생성하고 메일 플로우 정책마다 다른 확인 프로파일을 할당할 수 있습니다. 이를 통해 수락할 서명의 키 크기를 제한하고 키 검색 실패 작업을 설정하며 DKIM 확인의 심도를 구성할 수 있습니다.
메시지가 여러 게이트웨이를 통과하면서 여러 번 서명될 수 있으므로 여러 서명을 포함할 수 있습니다. 메시지가 DKIM 확인을 통과하려면 서명을 확인해야 합니다. 기본적으로 ESA는 최대 5개의 서명을 확인합니다.
SMTP 및 이메일의 기록은 공개적이며 인터넷은 전체적으로 (바람직한) 변화에 적응하는 것을 꺼려하기 때문에, DKIM 서명이 합법적으로 실패하는 경우(예: 메일 링 리스트 관리자가 직접 릴레이하지만 메시지를 수정하는 경우, 또는 메시지가 새로운 메시지에 대한 첨부 파일로서가 아니라 직접 전달되는 경우)가 있습니다. 따라서 일반적으로 DKIM에 실패한 메시지는 삭제하지 않고 격리하거나 태그를 지정하는 것이 좋습니다.
DKIM으로 서명 준비
RELAYED 메일 플로우 정책에서 DKIM 서명을 사용 설정하려면 먼저 키를 생성/가져오고, DKIM 서명 프로파일을 생성하고, 공개 키를 DNS에 게시해야 합니다.
단일 도메인에 서명하는 경우에는 프로세스가 간단합니다. 키 쌍을 생성하고 Mail Policies의 Domain Keys 섹션에서 단일 서명 프로파일을 생성한 다음 프로파일이 준비되면 "DNS Text Record"의 "Generate" 옵션을 클릭합니다. DNS에 생성된 대로 키를 게시합니다. 마지막으로 메일 플로우 정책에서 DKIM 서명을 켭니다.
여러 도메인에 서명하는 경우 더 복잡해집니다. 이 경우 두 가지 옵션이 있습니다.
- 단일 서명 프로파일을 사용하여 모든 도메인에 서명합니다. "기본" 도메인의 DNS 영역에 (단일) 공개 키를 저장하면 DKIM 서명이 해당 키를 참조합니다. 이 기법은 과거에 ESP에서 자주 사용되었기 때문에 개별 고객의 DNS 공간과 상호 작용할 필요 없이 대규모로 서명할 수 있었습니다 [5].
- 서명하는 각 도메인마다 별도의 서명 프로파일을 생성합니다. 따라서 초기 구성이 더 복잡해지지만 더 많은 유연성이 제공됩니다. 각 도메인에 대한 키 쌍을 생성하고 "Profile Users" 섹션에서 하나의 도메인(및 하위 도메인)만 지정하는 프로파일을 생성한 다음 해당 도메인의 DNS 영역에 관련 공개 키를 게시합니다.
1번 옵션은 시작하기가 더 쉽지만, 결국에는 DMARC에 손상을 일으킵니다. DMARC에서는 서명 도메인 ID가 Header From과 일치해야 하므로 식별자가 DKIM과 일치하지 않게 됩니다. SPF를 올바르게 구성하고 SPF 식별자 일치를 통해 DMARC 확인을 통과하면 문제가 발생하지 않을 수 있습니다.
그러나 처음부터 2번 옵션을 구현하면 DMARC에 대해 걱정할 필요가 없으며 단일 도메인에 대한 서명 서비스를 아주 쉽게 취소하거나 재구성할 수 있습니다. 또한 서드파티 도메인용 일부 이메일 서비스를 제공하는 경우에는 해당 도메인에서 사용할 키를 가져와 ESA로 가져와야 합니다. 이 키는 도메인에 따라 다르므로 별도의 프로파일을 생성해야 합니다.
서드파티 이메일 서비스를 사용하는 경우
일반적으로 DKIM 서명을 사용하고 일부 이메일 처리(예: 마케팅 이메일)를 서드파티에 위임하는 경우 프로덕션 환경에서 사용하는 것과 동일한 키를 서드파티가 사용하지 않도록 해야 합니다. 이것이 DKIM에 선택기가 존재하는 주요 이유 중 하나입니다. 대신 새로운 키 쌍을 생성하고 DNS 영역에 공개 부분을 게시한 다음 비밀 키를 상대방에게 전달해야 합니다. 이렇게 하면 문제가 발생할 경우에도 프로덕션 DKIM 인프라를 그대로 유지하면서 특정 키를 신속하게 취소할 수 있습니다.
DKIM에는 필요하지 않지만(동일한 도메인에 대한 메시지에 여러 키로 서명할 수 있음) 서드파티에서 처리하는 이메일에 대해서는 별도의 하위 도메인을 제공하는 것이 좋습니다. 따라서 더 쉽게 메시지를 추적할 수 있으며, 나중에 DMARC를 훨씬 명확하게 구현할 수 있습니다. 예를 들어 Lufthansa의 여러 메시지에 있는 다음 5개의 DKIM-Signature 헤더를 살펴보겠습니다.
DKIM 서명: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;
Lufthansa는 두 개의 기본 프로덕션 도메인(lufthansa.com, milesandmore.com)의 5개 개별 하위 도메인에서 5개의 키(선택기)를 사용하고 있음을 알 수 있습니다. 즉, 각 키를 따로 제어할 수 있으며 각 키를 다른 메시징 서비스 제공자에게 아웃소싱할 수 있습니다.
DMARC 구축 고려 사항
수신기용 DMARC
ESA의 DMARC 확인은 프로파일 기반이지만 DKIM과 달리 사양을 준수하도록 기본 프로파일을 수정해야 합니다. ESA의 기본 동작은 고객이 명시적으로 지시하지 않는 한 어떤 메시지도 삭제하지 않는 것입니다. 따라서 기본 DMARC 확인 프로파일에는 모든 작업이 "No Action"으로 설정됩니다. 또한 올바른 보고서 생성을 활성화하려면 "Mail Policies"의 DMARC 섹션에서 "Global Settings"을 수정해야 합니다.
프로파일이 설정된 후에는 다른 두 가지와 마찬가지로 Mail Flow Policies의 Default Policy Settings 섹션에 DMARC 확인이 설정됩니다. 집계 피드백 보고서를 전송하려면 확인란을 선택해야 합니다. 이는 발신자에게 DMARC의 가장 중요한 기능입니다. 본 문서를 작성하는 현재 ESA는 메시지별 실패 보고서(DMARC 정책의 "ruf" 태그) 생성을 지원하지 않습니다.
발신자가 DMARC 정책 작업을 권장하므로 SPF 또는 DKIM과 달리 프로파일 구성 외부에서 구성 가능한 구체적인 작업이 없습니다. 콘텐츠 필터를 생성할 필요가 없습니다.
DMARC 확인은 Authentication-Results 헤더에 필드를 추가합니다.
Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com
위의 예에서는 DKIM 식별자 일치에 따라 DMARC가 확인되었으며 발신자가 "none" 정책을 요청한 것을 확인할 수 있습니다. 이는 현재 DMARC 구축의 "모니터링" 단계에 있음을 나타냅니다.
다른 도메인 또는 서드파티용 이메일 서비스를 제공하는 경우
DMARC 규정 준수에 대한 ESP의 최대 관심사는 적절한 식별자 일치를 달성하는 것입니다. DMARC를 계획할 때 SPF가 올바르게 설정되어 있는지, 모든 관련 기타 도메인의 SPF 레코드에 발신 게이트웨이가 있는지, MAIL FROM 및 Header From ID에 기본으로 다른 도메인을 사용하여 일치에 실패할 메시지를 제출하지 않는지 확인해야 합니다. 이 오류는 애플리케이션 작성자가 이메일 ID의 불일치로 인한 결과를 대부분 인식하지 못하기 때문에 이메일 알림 또는 경고를 전송하는 애플리케이션에서 가장 자주 발생합니다.
앞에서 설명한 대로 각 도메인에 대해 별도의 DKIM 서명 프로파일을 사용하고 서명 프로파일이 Header From에 사용된 서명 도메인을 올바르게 참조하는지 확인해야 합니다. 자체적인 하위 도메인을 사용하는 경우 단일 키로 서명할 수 있지만 DMARC 정책("adkim ="r")에서 DKIM 준수를 완화하도록 설정해야 합니다.
일반적으로 직접 관리할 수 없는 많은 서드파티에 대해 이메일 서비스를 제공하는 경우에는 전달 가능성이 가장 높은 이메일을 제출하는 방법에 대한 가이드라인 문서를 작성하는 것이 좋습니다. 사용자 간 이메일은 일반적으로 잘 동작하므로, 위에서 언급한 예에서 주로 애플리케이션 작성자를 위한 정책 문서 역할을 합니다.
서드파티 이메일 서비스를 사용하는 경우
서드파티를 사용하여 일부 이메일 트래픽을 전달하는 경우 최적의 방법은 별도의 하위 도메인(또는 완전히 다른 도메인)을 서드파티 제공자에게 위임하는 것입니다. 이렇게 하면 필요에 따라 SPF 레코드를 관리하고, 별도의 DKIM 서명 인프라를 보유할 수 있으며, 프로덕션 트래픽을 방해하지 않습니다. 그러면 아웃소싱되는 이메일에 대한 DMARC 정책이 사내 정책과 다를 수 있습니다. 이미 언급한 것처럼, 서드파티에서 전달한 이메일을 고려할 때는 항상 식별자가 일치해야 하며 DMARC 정책에서 DKIM 및 SPF 준수가 적절하게 설정되어 있는지 확인하십시오.
이메일 트래픽이 없는 (하위) 도메인
이전 이메일 인증 기술에 비해 DMARC에서 개선된 또 다른 사항은 하위 도메인을 처리하는 방식입니다. 기본적으로 특정 도메인의 DMARC 정책은 모든 하위 도메인에 적용됩니다. DMARC 정책 레코드를 검색할 때 Header From FQDN 레벨에 레코드가 없으면 수신자는 발신자의 조직 도메인 [6]을 확인하고 정책 레코드를 조회해야 합니다.
그러나 조직 도메인에 대한 DMARC 정책은 명시적 DMARC 정책이 게시되지 않은 하위 도메인에 적용되는 별도의 하위 도메인 정책(DMARC 레코드의 “sp” 태그)을 지정할 수도 있습니다.
SPF 장의 앞부분에서 설명한 시나리오에서는 다음을 수행합니다.
- 합법적인 이메일 소스인 하위 도메인에 대해 명시적인 DMARC 레코드를 게시합니다.
- 비전송 도메인을 스푸핑하는 이메일을 자동으로 거부하도록 조직 도메인 정책 레코드에 하위 도메인 "reject" 정책을 게시합니다.
이러한 종류의 이메일 인증 구조는 인프라와 브랜드를 최대한 보호합니다.
DMARC 관련 문제
DMARC에는 몇 가지 잠재적인 문제가 있으며, 모두 DMARC가 사용하는 다른 인증 기술의 특성과 단점에서 비롯됩니다. 문제는 DMARC가 이메일을 거부하는 정책을 적극적으로 푸시하고 메시지에 있는 모든 여러 발신자 식별자의 상호 연관성을 파악하여 이러한 문제점이 표면에 드러난다는 것입니다.
대부분의 문제는 이메일 목록 및 이메일 목록 관리 소프트웨어에서 발생합니다. 이메일이 이메일 목록으로 전송되면 모든 수신자에게 재배포됩니다. 그러나 원래 발신자의 발신자 주소가 포함된 결과 이메일은 이메일 목록 관리자의 호스팅 인프라를 통해 전달되므로 Header From에 대한 SPF 검사에 실패합니다(대부분의 이메일 목록 관리자는 목록 주소를 Envelope From(MAIL FROM) 및 원래 발신자의 주소를 Header From으로 사용).
DMARC가 SPF에 실패하므로 DKIM을 사용할 수 있지만 대부분의 이메일 목록 관리자는 메시지에 바닥글을 추가하거나 제목에 목록 이름으로 태그를 지정하여 DKIM 서명 확인을 중단합니다.
DKIM의 작성자는 이 문제에 대한 몇 가지 해결책을 제안합니다. 모든 해결책에서는 이메일 목록 관리자가 모든 From 주소의 목록 주소를 사용해야 하며 또 다른 수단으로 원래 발신자 주소를 표시해야 합니다.
SMTP를 통해 원본 메시지를 새로운 수신자에게 복사하는 방법으로 전달되는 메시지에서도 유사한 문제가 발생합니다. 그러나 현재 사용 중인 대부분의 메일 사용자 에이전트는 새 메시지를 올바르게 구성하며 전달된 메시지를 인라인으로 또는 새로운 메시지의 첨부 파일로 포함합니다. 이러한 방식으로 전달된 메시지는 전달 사용자가 통과할 경우 DMARC를 전달합니다(물론 원본 메시지의 신뢰성을 보장할 수 없음).
이메일 인증을 구현하기 위한 샘플 실행 계획
기술 자체는 단순하지만 완전한 이메일 인증 인프라를 구현하는 길은 멀고도 험할 수 있습니다. 소규모 조직 및 메일 플로우가 제어되는 조직의 경우에는 매우 간단하지만 대규모 환경에서는 매우 어려울 수 있습니다. 대기업이 구현 프로젝트를 관리하기 위해 컨설팅 지원을 받는 것은 드문 일이 아닙니다.
1단계: DKIM
서명되지 않은 메시지로 인해 거부가 발생하지 않으므로 DKIM은 비교적 방해가 되지 않습니다. 실제 구현 전에 앞서 언급한 모든 사항을 고려하십시오. 서명을 위임할 수있는 서드파티에 문의하고, 서드파티가 DKIM 서명을 지원하는지 확인하며, 선택기 관리 전략을 고려하십시오. 일부 조직에서는 조직 단위별로 별도의 키(선택기)를 사용하기도 합니다. 보안을 강화하기 위해 키를 주기적으로 교체하는 것을 고려할 수 있습니다. 그러나 전송 중인 모든 메시지가 전달될 때까지 이전 키를 삭제하지 마십시오.
키 크기에 특히 유의해야 합니다. 일반적으로 "클수록 좋습니다". 하지만 메시지당 두 개의 디지털 서명(예: 정규화 포함)을 생성하면 CPU가 많이 사용되며 발신 메일 게이트웨이의 성능이 저하될 수 있다는 점을 고려해야 합니다. 계산 오버헤드로 인해 2048비트가 실제로 사용 가능한 최대 키 크기이지만, 대부분의 구축에서 1024비트 키는 성능과 보안을 적절히 충족합니다.
DMARC의 후속 구현을 성공적으로 수행하려면 다음을 수행해야 합니다.
- 하위 도메인을 포함하여 전송하는 모든 도메인 식별
- DKIM 키 생성 및 각 도메인에 대한 서명 프로파일 생성
- 서드파티에 관련 개인 키 제공
- 모든 공개 키를 관련 DNS 영역에 게시
- 서드파티가 서명을 시작할 준비가 되었는지 확인
- 모든 ESA의 RELAYED 메일 플로우 정책에서 DKIM 서명 사용 설정
- 서드파티에 서명을 시작하도록 알림
2단계: SPF
SPF를 올바르게 구현하는 일은 이메일 인증 인프라 구현에서 시간이 가장 많이 걸리고 번거로운 작업일 것입니다. 이메일은 사용 및 관리가 매우 간단하고 보안 및 액세스 관점에서 완전히 개방적이기 때문에 조직에서는 과거에는 이메일을 사용할 수 있는 주체와 방식에 대해 엄격한 정책을 시행하지 않았습니다. 이로 인해 오늘날 대부분의 조직은 내부 및 외부에서 모든 이메일 소스를 확인할 수 없습니다. SPF를 구현하는 데 있어 가장 큰 문제는 현재 합법적으로 귀하를 대신하여 이메일을 보내는 주체를 찾는 것입니다.
확인해야 하는 사항:
- 명백한 대상 - Exchange 또는 기타 그룹웨어 서버 또는 발신 메일 게이트웨이
- 외부 알림을 생성할 수 있는 DLP 솔루션 또는 기타 이메일 처리 시스템
- 고객과 상호 작용하는 정보를 전송하는 CRM 시스템
- 이메일을 전송할 수 있는 다양한 서드파티 애플리케이션
- 랩, 테스트 또는 이메일을 보낼 수 있는 기타 서버
- 외부 이메일을 직접 전송하도록 구성된 개인용 컴퓨터 및 디바이스
조직마다 환경이 다르므로 위 목록은 완전하지 않지만, 무엇을 확인해야 할지에 대한 일반적인 지침으로 고려해야 합니다. 대부분의 이메일 소스가 식별되면 기존의 모든 소스를 인증하는 대신 목록을 정리할 수 있습니다. 이상적으로는 몇 가지 정당한 예외를 제외하고 모든 발신 이메일이 발신 메일 게이트웨이를 통해 전달되어야 합니다. 자체적인 마케팅 메일 솔루션을 보유하고 있거나 서드파티 마케팅 메일 솔루션을 사용하는 경우 프로덕션 이메일 게이트웨이와는 별도의 인프라를 사용해야 합니다. 메일 전달 네트워크가 매우 복잡한 경우에는 SPF에서 현재 상태를 문서화하는 작업을 진행할 수 있지만, 나중에는 상황을 정리하는 데 시간이 걸릴 수 있습니다.
동일한 인프라에서 여러 도메인을 제공하는 경우 단일 범용 도메인 SPF 레코드를 생성하고 "include" 메커니즘을 사용하여 개별 도메인에서 이를 참조할 수 있습니다. SPF 레코드가 너무 넓지 않은지 확인하십시오. 예를 들어 /24 네트워크의 5개 시스템만 SMTP를 전송하는 경우 해당 5개의 개별 IP 주소를 전체 네트워크가 아닌 SPF에 추가하십시오. ID 보안을 침해하는 악의적인 이메일의 가능성을 최소화하기 위해 레코드를 최대한 구체적으로 구성합니다.
일치하지 않는 발신자("~ all")에 대한 소프트 실패 옵션으로 시작합니다. 이메일의 모든 소스를 식별했음을 100% 확신하는 경우에만 하드 실패(-all)로 변경하십시오. 그렇지 않으면 프로덕션 이메일이 손실될 위험이 있습니다. 나중에 DMARC를 구현하고 모니터 모드에서 얼마간 실행한 후에는 놓친 시스템을 식별하고 SPF 레코드를 업데이트하여 완성할 수 있습니다. 그래야 SPF를 하드 실패로 설정할 수 있습니다.
3단계: DMARC
DKIM 및 SPF가 최대한 완전하게 설정되었으면, 이제 DMARC 정책을 생성해야 합니다. 이전 장에서 언급한 모든 상황을 고려하고 복잡한 이메일 인프라가 있는 경우 둘 이상의 DMARC 레코드를 구축할 준비를 하십시오.
보고서를 수신할 이메일 별칭을 생성하거나 보고서를 수집할 수 있는 웹 애플리케이션을 생성합니다. 여기에 사용하도록 엄격하게 정의된 이메일 주소는 없지만, 구체적인 주소를 사용하는 것이 좋습니다(예: rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com). 운영자가 이러한 주소를 모니터링하고 SPF, DKIM, DMARC 구성을 적절하게 수정하거나, 스푸핑 캠페인이 발생하는 경우 보안 팀에 알림을 제공하는 프로세스가 실행되는지 확인합니다. 처음에는 SPF 및 DKIM 구성 중에 놓쳤을 수 있는 모든 항목을 처리하도록 레코드를 조정할 때 상당한 워크로드가 발생합니다. 잠시 후 보고서에는 스푸핑 시도만 표시될 수 있습니다.
처음에는 DMARC 정책을 "none"으로 설정하고 실패한 검사("fo=1") 보고서를 전송하도록 포렌식 옵션을 설정합니다. 이렇게 하면 트래픽에 영향을 주지 않으면서 SPF 및 DKIM의 오류를 빠르게 파악할 수 있습니다. 제출된 보고서의 내용에 만족하는 경우 보안 정책과 환경설정에 따라 정책을 "quarantine" 또는 "reject"로 변경합니다. 앞서 언급한 대로, 운영자가 수신된 DMARC 보고서에 오탐이 있는지 지속적으로 분석하도록 하십시오.
DMARC를 완전하고 올바르게 구현하는 것은 쉽지 않습니다. 불완전한 레코드 집합과 "none" 정책을 게시하여 일부 결과(및 DMARC의 공식 "구현")를 얻을 수는 있지만, 모든 당사자가 최대한의 역량으로 구현하는 것이 발신자 조직과 인터넷 전체에 가장 바람직합니다.
타임라인과 관련하여 일반적인 프로젝트의 개별 단계에 관한 대략적인 내용은 다음과 같습니다. 앞서 언급한 대로, 조직마다 다르기 때문에 정확한 내용은 아닙니다.
| 1. DKIM 계획 및 준비 |
2-4주 |
| 2. DKIM 테스트 실행 |
2주 |
| 3. SPF – 합법적인 발신자 식별 |
2-4주 |
| 4. DMARC 정책 준비 |
2주 |
| 5. SPF 및 DMARC 레코드 테스트 실행 |
4~8주 |
| 6. 하드 실패로 SPF 테스트 실행 |
2주 |
| 7. 격리/거부로 DMARC 테스트 실행 |
4주 |
| 8. DMARC 보고서 모니터링 및 이에 따른 SPF/DKIM 조정 |
연속 |
규모가 작은 조직일수록 대부분의 단계, 특히 3단계와 4단계를 더 짧게 진행할 수 있습니다. 이메일 인프라가 아무리 간단하다고 생각하더라도 항상 테스트 실행 중에 충분한 시간을 할당하고, 놓친 부분에 대해 피드백 보고서를 면밀히 모니터링하십시오.
대규모 조직일수록 테스트 요건이 엄격하기 때문에 동일한 단계에 더 긴 시간이 소요될 수 있습니다. 복잡한 이메일 인프라를 보유한 기업이 이메일 인증 구현의 기술적인 측면뿐 아니라 전체적인 프로젝트 관리 및 여러 팀과 부서에 걸친 조율에 외부 지원을 활용하는 것은 드문 일이 아닙니다.
추가 참조 자료
- SPF에 대한 참조 사이트: http://www.openspf.org
- DKIM 위원회: http://www.dkim.org
- DMARC 메인 웹 사이트, The Trusted Domain Project 실행: http://www.dmarc.org
- dmarcian – DMARC의 저자 중 한 명인 Tim Draegen이 운영하는 도움말 및 리소스 사이트입니다. "툴" 섹션(http://www.dmarcian.com)을 방문하십시오.
- Online Trust Alliance의 Record Validator 툴: https://otalliance.org/resources/spf-dmarc-record-validator
- DMARC Record Assistant - DMARC 레코드를 만드는 데 유용한 또 다른 도구: http://www.kitterman.com/dmarc/assistant.html
- SPF 레코드 테스트 도구: http://www.kitterman.com/spf/validate.html
- "Don't Be A Phish: Deep Dive Into Email Authentication Technologies", Cisco Live 2014 프레젠테이션 BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627
[1] 본 문서에서는 정규화에 관한 내용을 다루지 않습니다. DKIM 정규화에 대한 자세한 내용은 "추가 참조" 섹션의 자료를 참조하십시오.
[2] 본 문서에서는 DKIM DNS 레코드 매개변수에 관한 내용도 다루지 않습니다.
[3] 메시지 필터 생성에 관한 내용도 본 문서에서 다루지 않습니다. 도움말은 AsyncOS for Email 사용 설명서를 참조하십시오.
[4] M3AAWG는 업계에서 일반적으로 적용하고 준수하는 우수한 모범 사례를 정의했습니다. 일반적인 발신자 모범 사례는 https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf를 참조하십시오.
[5] 이 동작은 원래 DKIM이 MAIL FROM 또는 Header From에 명시된 메시지 소스를 전혀 확인하지 않는다는 사실을 활용한 것입니다. DKIM은 서명 도메인 ID(DKIM 서명의 "d" 매개변수 및 서명 프로파일의 "Domain Name" 매개변수가 메시지 서명에 사용된 공개 키 쌍을 실제로 호스팅하는지만 확인합니다. "From" 헤더에 서명이 되어 있으면 발신자가 실명임을 나타냅니다. "Profile Users" 섹션에 서명하는 모든 도메인(및 하위 도메인)이 나열되어 있어야 합니다.
[6] 일반적으로 TLD 또는 관련 ccTLD 접두사(예: .ac.uk, .com.sg)보다 한 단계 하위의 도메인
피드백