머리말

지난 글 '이메일 보안 강화 기능 소개 - SPF'에 이어 이번 글은 자기가 소유한 메일 도메인을 보호하는 메일 도메인 보호 기능과 이메일 인증 방법인 DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting and Conformance)에 대해 설명합니다.

이메일 보안 강화 기능

메일 도메인 보호 기능

메일 도메인 보호 기능은 TOAST Email에서 제공하는 보안 기능입니다. TOAST Email 내에서 내가 소유한 도메인을 제3자가 사용하는 것을 방지합니다. TOAST Email 콘솔에서 메일 도메인을 등록하고 소유 여부가 확인되면 승인되지 않은 다른 프로젝트에선 해당 도메인을 사용해 이메일을 보낼 수 없게 됩니다. 현재 선택 기능이지만 추후 보안 강화를 위해 필수 기능으로 변경될 수 있습니다.

1. 메일 도메인 등록 및 소유권 확인하기

먼저 TOAST Email 콘솔에서 메일 도메인을 등록하고 도메인 소유권을 확인해야 합니다. 메일 도메인 소유자는 TOAST Email에서 제공한 TXT 레코드를 메일 도메인 DNS에 등록합니다. TOAST Email은 메일 도메인 DNS의 TXT 레코드 일치 여부로 소유권을 확인합니다.

메일 도메인 등록

1. Email 콘솔로 이동합니다.
2. 메일 도메인 관리 탭으로 이동합니다.
3. 메일 도메인 등록 버튼을 클릭하고 메일 발송 시 사용할 도메인을 등록합니다. (최상위 도메인만 등록 가능)

메일 도메인 소유권 확인

1. 인증 버튼을 클릭합니다. 메일 도메인 인증에 생성된 토큰이 표시됩니다.
2. 등록한 도메인 DNS에 TXT 레코드를 추가합니다.
3. 추가한 TXT 레코드가 반영되었다면 인증 버튼을 클릭해 도메인 소유권을 인증합니다.

SPF와 마찬가지로 'nslookup', 'dig' 명령어를 이용해 소유 확인을 위한 TXT 레코드가 메일 도메인 DNS에 반영되었는지 확인할 수 있습니다.

2. 메일 도메인 공유하기

메일 도메인을 보호하기 앞서 등록한 도메인을 다른 프로젝트에서 사용하고 있다면 도메인 공유가 필요합니다. 공유하지 않고 도메인 보호 기능을 활성화하면 공유 받지 않은 프로젝트에서 메일 발송은 실패합니다. 따라서 메일 도메인을 여러 프로젝트에서 사용한다면 반드시 공유해야 합니다.

메일 도메인 공유

1. 등록한 메일 도메인에 공유 > 설정 버튼을 클릭합니다.
2. 공유할 프로젝트로 이동 후 TOAST Email 앱키를 확인합니다. 확인된 앱키를 등록합니다. 공유가 완료되면 목록에 프로젝트 정보가 표시됩니다. (앱키는 우측 상단 'URL & Appkey'에서 확인할 수 있습니다.)

3. 발송 도메인 보호하기

발송 도메인 등록, 소유권 확인, 공유 설정이 완료되었다면 보호 기능을 활성화할 수 있습니다.

1. 보호 기능을 활성화할 메일 도메인에 보호 여부 > 보호 버튼을 클릭합니다.
2. 보호 기능 적용 안내 를 확인 후 보호 버튼을 클릭해 기능을 활성화시킵니다.

여기까지 진행했다면 발송 메일 도메인 보호는 완료되었습니다.

DKIM(DomainKeys Identified Mail)

TOAST Email에 메일 도메인 동록을 완료했다면 DKIM 기능을 사용할 수 있습니다. DKIM은 이메일 인증 방법 중 하나로 수신 서버에서 수신된 이메일이 위변조 되지 않았는지 디지털 서명을 이용해 검증하는 기술입니다. 발송 서버는 이메일 발송 시 이메일 발송자, 수신자, 제목, 내용 등을 비밀 키로 서명합니다. 이 서명 값을 DKIM-Signature 헤더(Header)에 추가합니다. 수신 서버는 DKIM-Signature 헤더 내 도메인(d=) DNS에 공개된 공개 키와 서명 알고리즘 정보 등이 담긴 DKIM 레코드를 조회하고 이 값들을 이용해 수신된 이메일 DKIM-Signature 헤더의 디지털 서명을 검증합니다.

다음은 DKIM 레코드 등록과 DKIM 검증 흐름입니다.

DKIM 레코드 구조

다음은 발송 도메인 DNS에 등록하는 DKIM 레코드 예입니다. DKIM 레코드는 수신 서버에서 수신된 이메일의 DKIM-Signature 헤더 검증을 위해 사용됩니다. DKIM 레코드는 SPF 레코드와 다르게 발송 도메인 DNS에 등록되는 것이 아니라 '${지정자}._domainkey.${도메인}' 도메인 DNS에 TXT 레코드로 등록합니다. 지정자는 아래 'DKIM-Signature 구조'에서 자세히 설명합니다.

다음은 DKIM 레코드 예시입니다.

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB

위에서 사용된 값에 대해서 설명합니다. 이 밖에도 선택적인 값들이 더 있습니다. DKIM 레코드 구조에 대한 자세한 설명은 아래 '참고'부분 DKIM RFC 항목을 확인 부탁드립니다.

| 구분 | 필수 여부 | 값 | 설명 | | - | - | - | - | | v | 선택 | DKIM1 | DKIM 레코드 버전입니다. | | k | 선택 | rsa | DKIM 인증 시 사용하는 알고리즘입니다. | | p | 필수 | Base64 문자열 | 디지털 서명을 검증 시 사용하는 공개 키입니다. Base64로 인코딩된 값입니다. 메일 발송 시 메일에 DKIM 서명을 하는 곳(예, TOAST Email)에서 발급합니다. |

DKIM-Signature 구조

다음은 이메일 발송 시 이메일 헤더에 추가되는 DKIM 서명(DKIM-Signature 헤더) 예입니다.

 DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=toast;
      t=1117574938; x=1118006938;
      h=from:to:subject:date;
      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

DKIM-Signature에 사용되는 값에 대해 설명합니다. DKIM-Signature 구조에 대한 자세한 설명은 아래 '참고'부분 DKIM RFC 항목을 확인 부탁드립니다.

| 구분 | 필수 여부 | 값 | 설명 | | - | - | - | - | | v | 필수 | 1 | 버전입니다. | | a | 필수 | sha-256 | DKIM 서명에 사용되는 알고리즘입니다. | | s | 필수 | - | 지정자(Selector)입니다. 발송 도메인은 여러 개의 DKIM을 사용할 수 있습니다. 따라서, DKIM-Signature 헤더에서는 이 서명이 어떤 공개 키를 이용해 인증해야 되는지 수신 서버에게 알려주어야 합니다. 예를 들어 지정자가 'toast'면 수신 서버는 'toast._domainkey.example.com'의 DNS에서 DKIM 레코드를 확인합니다. | | h | 필수 |- | 서명할 헤더(Header)입니다. 헤더들은 콜론(:)으로 구분합니다.| | b | 필수 | - | 서명할 헤더(h)에 정의된 헤더들을 서명한 값입니다. Base64로 인코딩됩니다. | | bh | 필수 | - | 이메일 본문을 서명한 값입니다. | | l | 선택 | - | 본문 서명(b)에 사용된 본문의 길이입니다. 따로 정의되어 있지 않다면 본문 전체를 사용합니다. | | d | 필수 |- | 도메인입니다. 지정자(s)와 함께 DKIM 서명을 검증하기 위해 DNS에 DKIM 레코드를 조회할 때 사용됩니다. MAIL FROM(5321.From)과 From(5322.From)과 다를 수 있습니다. 하지만, 다를 경우 의심스러운 메일로 분류될 수 있습니다. | | t | 선택 | - | DKIM 서명 생성 일시입니다. 형식은 유닉스 시간(Unix Time)입니다. 1970년 1월 1일 0시 0분 0초 UTC(협정 세계시)부터의 경과 시간을 초로 환산한 값입니다. 예, 2020년 6월 8일 오후 3시 47분 17초의 유닉스 시간: 1591631237초 | | x | 선택 | - | DKIM 서명 만료 일시입니다. 형식은 서명 생성 일시(t)와 같습니다. |

지정자(s)와 도메인(d)에 대해 예를 들면 다음과 같습니다. 한 고객사에서 이메일 발송 서비스의 고가용성(High Availability)을 위해 TOAST Email과 Google을 사용한다고 하면, 고객사에서 사용하는 발송 도메인은 TOAST Email과 Google에서 발급한 2개의 DKIM 레코드를 등록해야 합니다.

고객사에서 사용하는 지정자와 도메인은 다음과 같습니다.

지정자: toast, google
도메인: example.com

다음은 TOAST Email의 DKIM 레코드 입니다.

nslookup -q=TXT toast._domainkey.example.com

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB

조회한 도메인에서 'toast'는 지정자(s)이고 '_domainkey'는 고정된 문자열입니다. 그리고 'example .com'는 도메인(d)입니다.

다음은 Google의 DKIM 레코드입니다.

nslookup -q=TXT google._domainkey.example.com

v=DKIM1;k=rsa;p=1IafMAFEOF93azFjQDQEBAQUAA4GNADCBiQKBgQDDmFOEJFEvjoF3FP3aafg4suA2SyMwR5MGHpP9diNT1hRiwUd/AFAEFLjeofp2390fjaljfnveAEFLE/EW72O1839ThkyCgpSYS8nmEQIDAaMd

TOAST Email에서 발송한 이메일의 DKIM-Signature의 지정자는 'toast'로 설정되어 수신 서버는 'toast._domainkey.example.com'의 DKIM 레코드를 조회해 DKIM 인증을 진행합니다. Google에서 발송한 이메일의 DKIM-Signature의 지정자는 'google'로 설정되어 수신 서버는 'google._domainkey.example.com'의 DKIM 레코드를 조회해 DKIM 인증을 진행합니다.

DKIM 레코드 등록하기

TOAST Email에서 DKIM 레코드를 제공받아 발송 도메인 DNS에 등록하는 방법을 설명합니다.

1. 메일 도메인 관리 탭으로 이동합니다.
2. 등록된 발송 도메인에 DKIM 설정 버튼을 클릭합니다.
3. 표시된 DKIM 레코드를 복사해 발송 지정된 도메인 DNS에 등록합니다.
4. DKIM 레코드가 등록되었다면, 인증 버튼을 클릭해 인증을 완료합니다.
5. 인증이 성공했다면 팝업 내 DKIM 기능 으로 이동 후 활성화 버튼을 클릭해 DKIM을 활성화합니다.

DKIM 인증 테스트하기

DKIM 기능이 활성화되었다면 이메일을 발송해 DKIM이 정상적으로 인증되는지 확인할 수 있습니다. TOAST Email 콘솔에서 GMail로 이메일을 발송했을 때를 예로 들어보겠습니다.

1. 콘솔에서 내가 소유한 GMail로 이메일을 발송합니다.
2. GMail로 이동합니다. 수신된 이메일을 확인합니다.
3. 이메일의 우측 상단 더보기 에서 원본 보기 를 클릭합니다.
4. 표시된 페이지에서 DKIM 인증 결과를 확인할 수 있습니다.

DMARC(Domain-based Message Authentication, Reporting and Conformance)

이메일 보안 강화 가능의 마지막 단계인 DMARC는 이메일 스푸핑을 이용한 피싱, 사기 등을 막기 위한 이메일 인증 수단입니다. 수신 서버는 발송자 주소(From) 도메인의 DNS에서 DMARC 레코드를 조회합니다. DMARC 레코드에 정의된 정책에 따라 수신 서버는 수신된 메일을 인증합니다. DMARC 정책은 SPF와 DKIM을 사용하는지, 각각의 인증 수단이 실패했을 때 메일 처리 방법은 어떻게 되는지로 구성되어 있습니다. 필수적으로 사용해야되는 기능은 아니지만 대부분 메일 서비스들은 DMARC를 사용합니다. 안전한 메일 발송과 수신을 위해서는 사용하는 것이 좋습니다. SPF와 DKIM을 사용하지 않더라도 DMARC 정책을 설정해 수신이 실패되는 메일을 모니터링할 수 있습니다. 그리고 이메일 스푸핑, 피싱 등에 자기가 소유한 메일 도메인이 사용되지 않도록 보호할 수 있습니다.

다음은 TOAST Email을 통해 GMail로 이메일을 발송했을 때 DMARC 인증 흐름을 나타낸 시퀀스 다이어그램입니다.

DMARC DNS 레코드 구조

DMARC DNS 레코드는 '_dmarc.example.com'처럼 DMARC를 적용할 발송 도메인에 '_dmarc'를 붙인 서브 도메인 DNS에 레코드를 등록합니다. 다음은 위키피디아에 설명된 DMARC DNS 레코드 예시입니다.

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

DMARC 레코드에 사용되는 값에 대해 설명합니다. 더 자세한 내용은 아래 '참고'부분 DMARC RFC를 참고 부탁드립니다.

| 구분 | 필수 여부 | 값 | 설명 | | - | - | - | - | | v | 필수 | DMARC1 (고정) | 버전입니다. | | p | 필수 | none, quarantine, reject | 실패 시 처리에 대한 정책입니다. | | sp | 선택 | none, quarantine, reject | 서브 도메인에 대한 실패 처리 정책입니다. | | pct | 선택 | 0 ~ 100 (기본값 100)| 정책을 적용할 이메일 비중입니다. 예를 들어 50인 경우 수신된 이메일 중 절반이 DMARC 정책에 의해 인증됩니다. | | adkim | 선택 | s, r(기본값) | DKIM 얼라인먼트(Alignment). DKIM-Signature의 도메인(d)와 From(5322.From)의 일치 수준에 대한 설정입니다. | | aspf | 선택 | s, r(기본값) | SPF 얼라인먼트(Alignment). SPF 인증 시 MAIL FROM(5321.From)과 From(5322.From)의 일치 수준에 대한 설정입니다. | | rua | 선택 | |주기적으로 집계한 실패 보고서를 수신할 주소입니다. 예, mailto:demarc-report@toast.com | | ruf | 선택 | | 실패 보고서를 수신할 주소입니다. 예, mailto:demarc-report@toast.com | | fo | 선택 | 0(기본값), 1, d, s | 실패 보고서(ruf)를 생성할 기준입니다. | | rf | 선택 | afrf (고정) | 실패 보고서(ruf) 형식에 대한 설정입니다. | | ri | 선택 | 86400(단위 초, 기본 값) | 실패를 집계할 기간입니다. 설정된 주기마다 실패 보고서(rua)가 발송됩니다. |

'adkim'과 'aspf' 설명을 보면 알 수 있듯이 DMARC 정책을 적용하면 MAIL FROM(5321.From), DKIM-Signature의 도메인(d), 발신자 주소 From(5322.From)를 비교해 이메일 스푸핑을 막을 수 있습니다. 하지만, 너무 엄격하게 설정할 경우 정상적인 메일도 실패로 처리될 수 있기 때문에 주의가 필요합니다.

실패 정책(p)에 대해 조금 더 자세하게 설명하면 다음과 같습니다.

| 실패 정책 | 설명 | | - | - | | none | 수신 서버에서 실패에 대해 아무 처리도 하지 않을 것을 바랍니다. SPF, DKIM을 사용하지 않는 상황에서 설정할 수 있습니다. | | quarantine | 수신 서버는 실패한 메일을 스팸으로 처리할 것을 바랍니다. | | reject | 수신 서버에서 DMARC 실패가 발생한 메일을 반송합니다. 일반적으로 발송 서버와 수신 서버가 SMTP 통신 시 DSN(Delivery Status Notification) 응답으로 이루어지는 것을 선호하는 정책입니다. |

DMARC에서 주의할 점은 수신 서버가 DMARC 정책에 맞게 처리하는 것을 완전히 보장하지 않는다는 것입니다. DMARC는 발송 서버가 수신 서버에게 정책을 제안하는 수준으로 이해해야 합니다. 예를 들어 실패 정책을 'none'으로 설정해도 수신 서버는 인증이 실패된 이메일을 스팸으로 처리할 수 있습니다.

다음은 SPF와 DKIM 얼라인먼트(aspf, adkim) 값에 대한 설명입니다.

| 정책 | 설명 | | - | - | | s | 엄격함(Strict)입니다. 도메인 부분이 완전히 일치해야 합니다. | | r | 유연함(Relexed)입니다. 서브 도메인도 가능합니다. 예, 'd=example.com'일 때 'From: news.example.com' 통과 |

다음은 실패 보고서 종류에 대한 설명입니다.

| 실패 보고서 | 설명 | | - | - | | rua | 주기적으로 집계한 실패한 이메일에 대한 보고서를 수신할 주소입니다. | | ruf | 실패에 대한 더 자세한 보고서를 수신할 주소입니다. 'fo' 설정에 따라 보고서 형식이 결정됩니다. |

다음은 실패 보고서 생성 기준(fo)에 대한 설명입니다. 실패 보고서(ruf)를 설정하면 사용됩니다.

| 기준 | 설명 | | - | - | | 0 | SPF, DKIM 모두 실패했을 때 보고합니다. | | 1 | SPF, DKIM 하나라도 실패했을 때 보고합니다. | d | DKIM 인증 실패 시 보고합니다. | | s | SPF 인증 실패 시 보고합니다. |

DMARC 레코드 등록하기

DMARC 레코드를 등록하는 방법을 설명합니다.

DMARC 레코드는 '_dmarc.example.com'처럼 DMARC를 적용할 발송 도메인에 '_dmarc'를 붙인 도메인 DNS에 TXT 레코드로 등록합니다. TOAST Email 콘솔에서 추가적으로 작업할 내용은 없으며, 적절한 DMARC 정책을 수립해 등록하면 됩니다.

예를 들면 등록할 내용은 다음과 같습니다. DMARC 실패 시 보고서를 수신할 주소를 설정해야 합니다.

"v=DMARC1; p=none; fo=1; rua=mailto:${보고서를_수신할_주소}"

등록이 완료되었다면 'nslookup', 'dig' 명령어를 이용하여 DMARC DNS 레코드가 DNS에 반영되었는지 확인할 수 있습니다.

DMARC 레코드 예시

1. SPF, DKIM을 사용하지 않는 곳이나 DMARC를 처음 사용하는 곳

"v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@example.com"

정책은 'none'으로 설정하고 정책 적용 비중(pct)은 100으로 가장 약한 정책으로 실패 보고서를 받아봅니다.

2. SPF, DKIM 적용 후 DMARC 정책을 서서히 강화하기

"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

정책은 'quarantine'으로 설정하고 처음 정책 적용 비중(pct)은 10이나 충분히 낮은 값으로 설정합니다. 수신되는 실패 보고서를 분석해 실패 비율을 낮추고 정책 적용 비중을 늘려나가는 게 좋습니다.

DKIM 인증의 한계와 DMARC

DKIM 인증 시 DKIM-Signature의 도메인(d=)을 사용하기 때문에 여전히 From(5322.From)를 위조한 이메일 스푸핑 공격을 막기에는 부족합니다. DKIM은 이메일 내용의 위변조 여부를 인증할 뿐 DKIM-Signature 도메인(d=)와 MAIL FROM(5321.From), From(5322.From)의 관계를 검증하지 않기 때문입니다.

다음은 공격자(spoofing.com)가 직접 발송한 이메일 예입니다. From(5322.From)은 수신자가 신뢰하는 주소로 설정하고 SPF에서 사용하는 MAIL FROM(5321.From)과 DKIM에서 사용하는 DKIM-Signature 도메인(d=)은 공격자 도메인으로 설정했지만 SPF 레코드와 DKIM 레코드가 정상이라면 인증이 통과됩니다.

C: telnet www.example.com 25
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<bob@spoofing.com>    <-- SPF 레코드가 등록된 From과 다른 공격자 도메인을 사용
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: DKIM-Signature: v=1; a=rsa-sha256; d=spoofing.com; s=brisbane; <-- 공격자 도메인과 지정자
      c=simple; q=dns/txt; i=@eng.example.net;
      t=1117574938; x=1118006938;
      h=from:to:subject:date;
      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
C: From: "Bob Example" <bob@trust.com>  <-- 수신자는 MAIL FROM이 아닌 From을 보기때문에 속을 수 있음
C: To: Alice Example <alice@example.com>
...

DMARC는 이런 공격을 막기 위해 SPF, DKIM 얼라인먼트(Alignment)라는 기능을 사용합니다. 위 DMARC 레코드 구조 설명 시 말씀드린 것 처럼 DKIM-Signature 도메인(d=)와 MAIL FROM(5321.From), From(5322.From)의 관계를 검증하기 때문에 예시의 경우 SPF, DKIM 얼라인먼트(Alignment) 인증이 실패합니다. 이러한 실패에 대해 DMARC 정책을 'quarantine'이나 'reject'로 설정한다면 공격자가 발송한 이메일이 수신되지 않도록 막을 수 있습니다.

DMARC 적용 시 주의 사항

일부 발송 SMTP 서버의 IP가 SPF 레코드에 포함되지 않았거나 발송하는 이메일에 DKIM이 제대로 적용되어 있지 않은 상태에서 DMARC를 처음부터 'p=quarantine'이나 'p=reject'로 적용한다면 정상적인 이메일도 수신되지 않을 수 있습니다. 따라서, 처음 DMARC를 적용하신다면 'p=none'로 설정해 DMARC 실패 보고서를 분석해 잘못된 부분을 수정하는 것이 좋습니다. 수정 후 잘못된 부분이 없다는 게 충분히 검증되었다면, 'DMARC 레코드 예시'처럼 DMARC 정책 수준을 단계적으로 높이는 것을 권장합니다.

결론

지난 글에서는 이메일 보안 강화 기능에 대한 이해를 위한 사전 지식과 SPF(Sender Policy Framework)에 대해 알아봤습니다. 이번 글에서는 발송 메일 도메인 보호 기능과 DKIM(DKIM-Signature), DMARC(Domain-based Message Authentication, Reporting and Conformance)에 대해 알아봤습니다. 현재 국내 발송 도메인들을 살펴보면 SPF와 DKIM을 적용한 곳은 많이 있지만, DMARC를 적용한 곳은 적은 것으로 확인이 됩니다. 자기가 소유한 이메일 도메인이 이메일 스푸핑 공격에 사용되는 것을 완전히 방지하고 수신자에게 더 신뢰받을 수 있도록 하기 위해서는 DMARC 적용과 지속적인 실패 보고서 분석, 정책 관리가 필요합니다.

이메일 보안 강화 기능 SPF, DKIM, DMARC에 대한 이해가 필요하거나 적용을 검토 중인 곳에 도움이 되길 바랍니다.

참고

• 위키피디아, DKIM
  • https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
• DKIM RFC
  • https://tools.ietf.org/html/rfc4871
  • https://tools.ietf.org/html/rfc6376
• GMail, 발신자 이름 옆의 추가 정보
  • https://support.google.com/mail/answer/1311182
• 위키피디아, DMARC
  • https://ko.wikipedia.org/wiki/DMARC
• DMARC RFC
  • https://tools.ietf.org/html/rfc7489
• Valimail, Shortcomings of DKIM
  • https://www.valimail.com/blog/dkim/