DKIM 키 교체는 이메일 서명에 쓰는 키 쌍을 정해진 일정에 따라 새 키 쌍으로 바꾸는 작업입니다. 새 공개 키를 새 셀렉터로 DNS에 게시하고, 서명에 쓰는 키를 새 개인 키로 전환한 다음, 이전 키 쌍의 사용을 중단합니다.
이메일 운영자를 위한 모범 사례를 발표하는 업계 단체인 M3AAWG(Messaging, Malware and Mobile Anti-Abuse Working Group)는 키가 유출될 경우에 대비해 DKIM 키를 최소 6개월마다 교체할 것을 권장합니다.
이 가이드는 메일이 이미 DKIM 검사를 통과하고 있고, 자사 도메인이나 고객사 도메인을 직접 관리하는 팀을 대상으로 합니다. DKIM 키를 교체하는 방법부터 교체하지 않으면 생길 수 있는 문제까지, 알아야 할 내용을 모두 설명합니다.
아직 내 도메인의 메일이 어떤 키로 서명되는지 파악하는 중이라면, DKIM 셀렉터를 찾는 방법을 다룬 가이드부터 읽어 보세요. 이 글은 그 가이드의 다음 단계를 다룹니다.
키가 유출되면 공격자가 내 도메인 명의로 인증을 통과하는 메시지를 보낼 수 있습니다. 개인 키는 DNS에 게시되지 않고 내 도메인의 메일에 서명하는 메일 서버와 발송 플랫폼에 저장되어 있으며, 공격자가 이 중 한 곳에 침입하면 개인 키를 복사할 수 있습니다.
그다음 공격자는 자신이 만든 메시지에 내 개인 키로 서명합니다. 수신 메일 서버는 DNS에서 내 공개 키를 가져와 이 서명을 검증합니다.
서명 도메인이 From 주소의 도메인과 일치하므로, 이 메시지는 인증된 도메인과 From 주소를 비교하는 검사인 DMARC도 통과합니다. 수신 서버는 DMARC를 통과하지 못한 메일에만 DMARC 정책을 적용하므로, p=reject에서도 내 키로 서명된 이 메시지를 전달합니다.
M3AAWG는 이 위험을 정기적인 키 교체가 필요한 이유로 제시합니다. 키 쌍을 사용하는 기간이 짧을수록 유출된 키를 쓸 수 있는 기간도 짧아지기 때문입니다.
DKIM 키 교체를 누가 담당하는지는 각 셀렉터에 게시된 DNS 레코드의 유형, 그리고 각 셀렉터로 서명하는 플랫폼이 자체 일정에 따라 키를 교체하는지 여부, 이 두 가지로 알 수 있습니다. 레코드 유형을 확인하려면 내 도메인의 DNS 설정(Cloudflare, GoDaddy, 도메인 등록업체 등 DNS를 관리하는 곳)을 열고, 이름이 셀렉터 이름과 그 뒤에 붙은 ._domainkey로 시작하는 레코드를 찾으세요. 각 레코드 옆의 유형(Type) 열에 TXT 또는 CNAME이 표시됩니다.
DNS를 다른 사람이 관리한다면 대신 각 발송 플랫폼의 DKIM 설정 페이지를 확인하세요. 이 페이지에는 추가하도록 요청받은 레코드가 나와 있으며, 이 레코드는 CNAME 레코드이거나 긴 키 값이 들어 있는 TXT 레코드 하나입니다.
TXT 레코드에는 공개 키 자체가 들어 있으므로, 키를 새로 만들 때마다 DNS에 새 TXT 레코드를 게시해야 합니다. 따라서 Google Workspace처럼 플랫폼이 키 쌍을 생성해 주는 경우에도 키 교체는 직접 해야 하는 작업입니다.
셀렉터 이름에 게시된 CNAME 레코드는 플랫폼이 관리하는 레코드를 가리키는 별칭입니다. 개인 키는 플랫폼이 보관하며, 플랫폼은 내 DNS를 전혀 바꾸지 않고도 CNAME이 가리키는 레코드에 새 공개 키를 게시할 수 있습니다.
레코드 유형을 보면 누가 키를 교체할 수 있는지는 알 수 있지만, 교체가 언제 이루어지는지는 알 수 없습니다. 어떤 플랫폼은 자체 일정에 따라 키를 교체하고, 어떤 플랫폼은 교체 시작을 사용자에게 맡깁니다. 다음은 네 가지 발송 플랫폼이 키 교체를 처리하는 방식입니다.
| 발송 플랫폼 | 개인 키를 보관하는 주체 | 키 교체 방식 |
|---|---|---|
| Microsoft 365 | Microsoft가 보관합니다. 도메인에 한 번 게시해 두는 CNAME 레코드 2개(selector1, selector2)가 Microsoft가 관리하는 키 레코드를 가리킵니다. | Defender portal의 "Rotate DKIM keys" 또는 Exchange Online PowerShell의 Rotate-DkimSigningConfig cmdlet으로 직접 시작합니다. Microsoft 문서에 따르면, Microsoft는 교체를 시작한 지 4일(96시간) 후에 새 키로 서명을 전환합니다. |
| Google Workspace | Google이 보관합니다. 공개 키는 직접 TXT 레코드로 게시합니다. | 수동입니다. Admin console(관리 콘솔)에서 새 셀렉터 접두사로 새 레코드를 생성하고, 도메인 호스트에 새 TXT 레코드로 추가한 다음 인증을 시작합니다. |
| Salesforce(Sales Cloud) | Salesforce가 보관합니다. 도메인에 게시한 CNAME 레코드가 Salesforce가 관리하는 키 레코드를 가리킵니다. | 자동입니다. Salesforce가 30일마다 키를 교체합니다. |
| Amazon SES(Easy DKIM) | AWS가 보관합니다. AWS가 Easy DKIM으로 키 쌍을 생성하고 이 키로 메일에 서명합니다(기본값 2048비트). | 따로 일정을 잡을 필요가 없습니다. 키는 AWS가 보관하며, Easy DKIM 문서에는 도메인 소유자가 수행할 키 교체 단계가 나와 있지 않습니다. |
TXT 레코드로 게시된 키와 Microsoft 365처럼 교체 시작을 사용자에게 맡기는 플랫폼의 키는 모두 직접 교체하는 키입니다. 이 표에 없는 발송 플랫폼이라면 해당 플랫폼의 셀렉터에 게시된 레코드 유형과, 누가 교체를 시작하는지에 대한 제공업체의 문서, 이 두 가지를 똑같이 확인하세요. Salesforce의 경우는 제품별 설정 방법까지 Salesforce에서 보내는 이메일과 DMARC를 다룬 가이드에서 설명합니다.
고객사 도메인의 DKIM을 관리한다면, M3AAWG 가이드라인에 따라 키 교체 요청은 도메인 소유자가 해야 합니다. 교체 날짜는 매번 고객사와 합의하고, 그 날짜에 DNS와 서명 설정을 변경하세요.
직접 교체하는 키의 경우, M3AAWG는 최소 6개월마다 교체할 것을 권장합니다. M3AAWG 회원들은 DKIM Key Rotation Best Common Practices 문서에서 여러 교체 주기를 비교한 뒤, 키 유출 위험과 키를 교체하는 작업량 사이의 균형점으로 이 주기를 정했습니다. 이 문서는 온라인 쇼핑몰의 4월과 10월처럼, 가장 바쁜 판매 기간을 피한 고정 날짜를 제안합니다.
다음 두 가지 상황에서는 예정된 날짜보다 먼저 키를 교체하세요.
키를 교체할 때마다 키 길이를 확인하세요. RFC 8301은 서명자가 최소 1024비트의 RSA 키를 사용하도록 요구하고 2048비트를 권장하므로, 셀렉터의 DNS 레코드에 아직 1024비트 키가 들어 있다면 교체할 키는 2048비트로 생성하세요.
두 셀렉터 병행 방식을 사용하면 모든 메시지의 셀렉터가 DNS에 아직 게시되어 있는 공개 키를 가리키므로, 서명 실패가 한 건도 없이 키를 교체할 수 있습니다. 병행 기간에는 두 공개 키가 각자의 셀렉터로 게시된 상태로 남아 있으며, 그동안 서명에 쓰는 키를 이전 개인 키에서 새 개인 키로 전환합니다.
아래 단계는 직접 운영하는 메일 서버가 메일에 서명하는 경우를 기준으로 합니다. Google Workspace처럼 플랫폼이 키 쌍을 생성해 주는 경우에는 새 키 생성과 서명 전환을 플랫폼의 관리 콘솔에서 하지만, DNS 레코드를 게시하고 나중에 폐기하는 작업은 여전히 직접 해야 합니다.
mail-202604처럼 날짜를 넣은 이름을 쓰면 각 키를 사용하기 시작한 시점 순으로 셀렉터를 정렬할 수 있습니다.mail-202604._domainkey.yourdomain.com)을 DNS에서 조회했을 때 새 공개 키가 반환될 때까지 기다립니다. 메일 서버는 아직 새 키로 서명하지 않으므로, 기다리는 동안 실패하는 서명은 없습니다.s= 태그에는 새 셀렉터가 들어가고, 수신 서버는 새 공개 키로 이 메일의 서명을 검증합니다.v=DKIM1; p=(비어 있는 p= 값)로 바꿔 이전 키를 폐기합니다. RFC 6376은 빈 값을 폐기된 키로 정의합니다. M3AAWG는 레코드를 삭제하지 말고 DNS에 남겨 둘 것을 권장하는데, 그래야 이전 셀렉터를 조회한 수신 서버가 레코드가 없는 상태가 아니라 의도적으로 사용을 중단한 키를 확인하게 됩니다.Microsoft 365도 자체적으로 같은 병행 방식을 사용합니다. 두 셀렉터가 모두 게시된 상태로 남아 있고, Microsoft는 교체를 시작한 지 4일(96시간) 후에 새 키로 서명을 전환합니다.
내 도메인의 DMARC 레코드에 rua= 태그(보고서를 받는 주소)가 있으면, 수신 서버는 이 주소로 DMARC 집계 보고서를 보냅니다. 이 보고서에서 키 교체 과정을 확인할 수 있는데, 새 셀렉터로 서명된 메시지가 통과하기 시작하고 이전 셀렉터로 서명된 메시지는 더 이상 나타나지 않습니다. M3AAWG는 교체할 때마다 약 1주일 뒤에 점검할 것을 권장하며, 점검에서는 수신 서버가 확인한 셀렉터를 일정상 활성 상태여야 하는 셀렉터와 비교합니다.
사용을 중단한 셀렉터가 보고서에 계속 나타난다면 문제가 있다는 뜻입니다. 먼저 확인할 원인은 두 가지로, 아무도 키를 교체하지 않아 아직 이전 키로 서명하는 서비스가 있거나, 키를 메일 서버와 DNS 중 한쪽에서만 교체한 경우입니다. 두 번째 경우에는 메일 서버는 한 키로 서명하는데 DNS 레코드에는 다른 키가 들어 있어서, 수신 서버가 이 메시지들을 DKIM 실패로 판정합니다.
DMARCeye는 DMARC 집계 보고서를 대신 읽고 도메인별로 메일 서명에 쓰인 셀렉터를 목록으로 보여 주므로, 더 이상 나타나지 않아야 할 셀렉터가 남아 있는지 확인할 수 있습니다. 무료 플랜은 도메인 1개를 지원합니다.
Microsoft 365의 selector1, selector2처럼 흔히 쓰이는 셀렉터 이름을 사용하는 플랫폼이라면, 아래의 무료 DKIM 검사 도구로 각 셀렉터에 게시된 키와 그 키의 강도를 확인할 수 있습니다. 이 도구로 2048비트 키로 교체할 때가 된 1024비트 키를 찾아보세요. 단, 이 도구는 mail-202604 같은 사용자 지정 이름은 조회하지 않습니다.
네, M3AAWG는 셀렉터 이름을 재사용하지 말 것을 강력히 권고합니다. 재사용한 이름의 레코드에 새 키가 들어가면, 수신 서버는 아직 전송 중인 메일을 포함해 이전 키로 서명된 모든 메시지를 DKIM 실패로 판정하기 때문입니다. billing-202604처럼 교체 날짜를 넣은 이름을 쓰면 각 키를 언제부터 사용했는지도 알 수 있습니다.
아니요, 병행 기간 동안 이전 키를 계속 게시해 두면 실패하지 않습니다. 수신 서버는 메시지가 도착할 때 서명을 검증하며, 이전 키를 7~30일 동안 게시해 두는 것은 이 키로 서명되어 전달이 지연된 메일도 키를 폐기하기 전에 도착해 검증을 통과하게 하기 위해서입니다. 키를 폐기한 뒤에도 이미 전달된 메일에는 영향이 없으며, 나중에 오래된 메시지를 다시 검사하는 경우에만 검증에 실패합니다.
현재 DKIM2 초안 기준으로는 기존 DKIM과 같은 방식으로 키를 교체합니다. IETF는 DKIM을 개편할 후속 규격인 DKIM2를 작업하고 있으며, DKIM2의 DNS 초안에 명시된 키 모델도 같습니다. 즉, 발신자는 셀렉터로 공개 키를 DNS에 게시하고, 빈 p= 값으로 키를 폐기합니다.
DKIM 키 교체는 일정에 따라 하는 작업이며, 이 일정에는 직접 교체하는 키만 넣으면 됩니다. 그러면 유출된 키를 쓸 수 있는 기간이 누군가 보안 사고를 알아차릴 때까지가 아니라 다음 예정된 교체 때까지로 제한됩니다.
각 셀렉터의 레코드 유형과 각 플랫폼이 자체 일정에 따라 키를 교체하는지 여부를 기준으로 발송 플랫폼을 분류하세요. 직접 교체하는 키는 모두 1년에 두 번 교체하는 일정에 넣고, 키 유출이 의심되거나 서명 키에 접근할 수 있던 사람이 떠나면 일정보다 먼저 교체하세요. 모든 교체는 두 셀렉터 병행 방식으로 진행해, 어떤 메시지도 DNS에 없는 키를 가리키지 않게 하세요.
DMARC 집계 보고서를 받고 있다면, 교체할 때마다 이 보고서로 결과를 확인할 수 있습니다. 계획한 날짜에 새 셀렉터로 서명된 메시지가 통과하고 이전 셀렉터가 더 이상 나타나지 않으면 교체가 끝난 것입니다. DMARCeye는 각 도메인에서 메일 서명에 쓰인 셀렉터를 보여 주므로, 매일 보고서가 도착할 때마다 모든 교체를 확인할 수 있습니다.