“회사 메일에 DKIM을 설정해 달라”는 요청을 받으면, DNS에 긴 문자열 하나를 넣는 일처럼 보입니다. 그런데 레코드를 저장했는데도 인증이 안 되거나, 직원이 보낸 메일은 통과하는데 뉴스레터만 실패하기도 합니다. DKIM은 DNS와 실제 발송 서비스가 짝을 맞춰야 동작하기 때문입니다.
가상의 회사 가온상사를 따라가 보겠습니다. 회사 주소는 example.com이고, 직원은 Google Workspace로 견적서를 보냅니다. 마케팅팀은 별도 뉴스레터 서비스를 씁니다. 목표는 두 서비스에서 보낸 메일 모두에 회사 도메인의 유효한 서명이 붙도록 만드는 것입니다. Microsoft 365를 쓰는 회사가 따라 할 설정도 함께 설명합니다.
DKIM은 메일마다 붙이는, 확인 가능한 전자서명입니다
종이 문서에 회사 도장을 찍는 모습을 떠올려 보세요. DKIM도 메일을 보낼 때 표시를 남깁니다. 다만 같은 도장 그림을 붙이는 것과는 다릅니다. 서명 대상의 내용이 달라지면 서명도 달라지고, 받는 곳은 그 서명이 맞는지 계산으로 확인할 수 있습니다.
발송 서버는 본문과 서명할 헤더에서 짧은 계산값인 해시를 만듭니다. 내용을 구별하는 지문에 가깝습니다. 본문 해시를 포함한 서명 정보를 개인키로 서명해 메일에 붙입니다. 수신 서버는 같은 방식으로 계산한 값과 공개키를 이용해 검증합니다. 서명 대상인 본문이나 제목이 중간에 바뀌었다면 검증에 실패할 수 있습니다.
- 01보내기
발송 서버가 메일의 계산값을 만들고 개인키로 서명합니다.
- 02공개키 찾기
받는 서버가 서명에 적힌 도메인과 selector로 DNS를 조회합니다.
- 03검증하기
공개키로 서명을 검증하고, 받은 내용의 계산값도 비교합니다.
개인키는 서명을 만드는 비밀입니다. Google Workspace나 Microsoft 365를 쓰면 서비스가 보관하므로 관리자가 DNS에 올리지 않습니다. 공개키는 누구나 서명을 확인하도록 공개하는 값입니다. 공개키를 보았다는 이유만으로 다른 사람이 같은 서명을 만들 수 있는 것은 아닙니다. DKIM의 해시와 서명 구조 ↗
전자서명이 메일을 암호화하지는 않습니다. 또 검증 성공은 서명한 도메인과 보호된 내용을 확인했다는 뜻입니다. 특정 직원이 직접 작성했는지, 계좌 변경이 정당한지, 첨부파일이 안전한지는 별개입니다. 정상 계정을 탈취해 정상 발송 경로를 이용한 메일도 DKIM을 통과할 수 있습니다.
selector는 공개키를 찾는 이름입니다
가온상사의 서명에 d=example.com; s=google이 있다면, d=는 서명 도메인이고 s=는 selector입니다. selector를 키 보관함의 이름이라고 생각하면 쉽습니다. 같은 회사에서도 직원 메일과 뉴스레터가 각기 다른 보관함을 쓸 수 있습니다.
서명 도메인 d=example.com
selector s=google
공개키 조회: google._domainkey.example.com이 위치에는 공개키 TXT가 있거나, 공개키가 있는 다른 위치를 가리키는 CNAME이 있습니다. google이라는 이름 자체가 인증을 보장하지는 않습니다. 메일의 s=, DNS 이름, 실제 서명에 쓰인 키가 서로 맞아야 합니다. 공개키 조회 이름의 규칙 ↗
DNS에 넣는 값과 메일에 붙는 값을 나눠 읽으세요
설정 중에는 서로 다른 두 화면을 보게 됩니다. DNS 관리 화면에는 공개키를 등록하고, 받은 메일의 원본에서는 서명과 검증 결과를 읽습니다. 아래 항목을 모두 직접 작성할 필요는 없습니다. 서비스가 발급한 값을 사용하되, 문제가 생겼을 때 어느 부분을 확인할지 알아두면 됩니다.
표를 좌우로 밀어 전체 내용을 확인하세요.
| 항목 | 뜻 | 설정할 때 확인할 점 |
|---|---|---|
| 이름 | selector._domainkey.서명도메인 | 발급된 selector와 도메인 위치를 확인합니다. |
| v=DKIM1 | 공개키 레코드의 버전 | 메일 서명의 v=1과 다릅니다. 발급값을 그대로 씁니다. |
| k=rsa | 공개키의 종류 | RSA 키를 발급받았다면 rsa입니다. |
| p=긴 문자열 | 서명 검증용 공개키 | 공개키 전체를 넣습니다. DMARC의 정책 p=와는 다른 항목입니다. |
표를 좌우로 밀어 전체 내용을 확인하세요.
| 항목 | 예시 | 읽는 방법 |
|---|---|---|
| d= / s= | example.com / google | 서명 도메인과 공개키 selector입니다. |
| a= | rsa-sha256 | RSA 서명과 SHA-256 해시를 사용했다는 뜻입니다. |
| h= | from:to:subject:date | 서명에 포함한 헤더 목록입니다. From은 필수입니다. |
| bh= | 본문에서 계산한 값 | 본문의 해시입니다. 그 자체가 인증 성공 표시인 것은 아닙니다. |
| b= | 해당 메일의 서명값 | 개인키로 만든 실제 전자서명입니다. |
| c= | relaxed/relaxed | 헤더와 본문을 비교하기 전 공백 등을 정리하는 규칙입니다. |
c=relaxed/relaxed는 일부 공백 차이를 허용하는 방식이지 내용 변경을 허용하는 설정이 아닙니다. 또 h=에 없는 헤더까지 모두 보호된다고 생각하면 안 됩니다. 관리형 서비스를 사용한다면 서명 항목을 임의로 바꾸기보다 해당 서비스의 설정을 따릅니다. DKIM 서명 항목의 정의 ↗
새 RSA 키는 2,048비트를 우선 선택합니다
발송 서비스와 DNS가 지원한다면 RSA 2,048비트 이상이 권장 기준입니다. 1,024비트 키가 곧바로 모든 수신처에서 실패한다는 뜻은 아니지만, 새 설정에서 일부러 짧은 키를 고를 이유는 줄었습니다. RSA의 해시 알고리즘은 rsa-sha256을 사용하며 rsa-sha1은 사용하지 않습니다. 서비스가 키를 관리한다면 현재 키 길이와 교체 기능을 확인하세요. 알고리즘과 RSA 키 길이 기준 ↗
Google Workspace: TXT를 등록한 뒤 인증을 시작합니다
가온상사의 담당자는 먼저 Google 관리 권한과 example.com의 DNS 수정 권한을 준비합니다. 도메인을 구매한 곳과 실제 DNS를 관리하는 곳이 다를 수 있으므로, 현재 도메인에 적용되는 DNS를 수정해야 합니다. 기존 DKIM 레코드가 있다면 어떤 서비스가 쓰는지 먼저 확인합니다.
- 대상 도메인과 키를 선택합니다
Google 관리 콘솔 → 앱 → Google Workspace → Gmail → 이메일 인증으로 이동합니다. example.com을 선택하고 새 레코드를 생성합니다. DNS가 지원하면 2,048비트를 선택하고, 기존 사용과 충돌하지 않는 selector를 씁니다. 기본값은 google입니다.
- 발급받은 이름과 TXT 전체를 DNS에 넣습니다
콘솔의 DNS 호스트 이름과 TXT 값을 복사합니다. DNS 업체가 도메인 이름을 자동으로 붙이는지 확인하고 저장합니다. 공개키를 직접 만들거나 다른 회사의 키를 복사하지 않습니다.
- 공개 DNS를 확인한 뒤 인증을 시작합니다
공개키가 올바른 이름에서 조회되면 Google의 이메일 인증 화면으로 돌아가 인증 시작을 누릅니다. 그다음 외부 계정에 새 메일을 보내 실제 서명을 확인합니다.
Type: TXT
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_ADMIN_CONSOLE
최종 조회 이름: google._domainkey.example.com화면에 google._domainkey.example.com.example.com이 만들어졌다면 도메인이 두 번 붙은 것입니다. DNS 업체의 입력 규칙에 맞게 이름을 수정한 뒤 최종 조회 이름을 다시 확인합니다. DNS 반영은 캐시 때문에 지연될 수 있습니다. 기다리는 동안 키를 계속 새로 생성하면 어떤 키를 게시했는지 더 헷갈릴 수 있습니다. Google Workspace DKIM 설정 ↗
긴 공개키가 두 문자열로 보이면 잘못된 것일까요?
꼭 그렇지는 않습니다. DNS 도구가 하나의 TXT 레코드를 "첫 부분" "나머지 부분"처럼 나눠 보여줄 수 있습니다. 수신 서버는 이 문자열을 이어서 읽습니다. 반면 같은 이름에 공개키를 절반씩 나눠 TXT 레코드 두 개로 만들면 다른 문제가 됩니다. 전체 키가 들어 있는 하나의 레코드인지 확인하세요. 같은 selector에 서로 다른 키를 중복 게시해서도 안 됩니다. TXT 문자열 결합과 레코드 규칙 ↗
입력창이 짧다는 이유로 공개키 뒷부분을 잘라내면 안 됩니다. DNS 업체의 긴 TXT 입력 방식을 확인하고, 필요한 경우 지원팀에 전체 키 저장 방법을 문의합니다. Google의 긴 TXT·DKIM 문제 해결 안내 ↗
Microsoft 365: 발급받은 CNAME 두 개를 연결합니다
직원 메일이 Microsoft 365라면 이 절차를 사용합니다. 회사 DNS에는 긴 공개키 대신 Microsoft가 관리하는 키 위치로 연결하는 CNAME 두 개를 등록합니다. 하나는 현재 서명에, 다른 하나는 향후 키 교체에 쓰이므로 두 개 모두 준비합니다.
Microsoft Defender의 이메일 인증 설정 → DKIM에서 회사 도메인을 선택하고 CNAME 발급값을 확인합니다. 아래 표의 대상 칸에는 해당 회사에 발급된 주소를 넣습니다.
표를 좌우로 밀어 전체 내용을 확인하세요.
| 유형 | 이름 | 대상 |
|---|---|---|
| CNAME | selector1._domainkey | 해당 도메인의 Selector1CNAME 값 |
| CNAME | selector2._domainkey | 해당 도메인의 Selector2CNAME 값 |
Microsoft는 2025년 5월부터 새 사용자 지정 도메인에 새 CNAME 형식을 도입했습니다. 도메인에 따라 기존 형식을 사용하는 경우도 있으므로 블로그 예시에 회사 이름만 끼워 넣지 마세요. 자동으로 할당되는 값도 있습니다. 지금 관리 화면에서 조회되는 전체 대상 주소가 기준입니다. DNS 등록 후 두 CNAME이 조회되면 해당 도메인의 DKIM 서명을 활성화합니다. Microsoft의 CNAME 발급·활성화 절차 ↗
Exchange Online PowerShell을 사용하는 관리자는 아래 조회 명령으로 이름·대상·활성화 상태를 함께 확인할 수 있습니다. 연결과 권한 설정은 먼저 필요합니다. 이 명령은 설정을 바꾸지 않습니다.
Get-DkimSigningConfig -Identity example.com |
Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMEEnabled: True, Status: Valid이면 설정 상태가 정상인지 확인하는 데 도움이 됩니다. CnameMissing이라면 두 CNAME의 이름·대상과 실제 수정한 DNS 영역을 대조합니다. 이 상태 조회 후에도 외부로 새 메일을 보내 아래 방식으로 검사합니다. DKIM 설정 조회 명령 ↗
새 메일 한 통으로 DNS·서명·정렬을 차례로 확인합니다
설정이 끝난 가온상사의 담당자는 직원 계정에서 외부 테스트 계정으로 견적서 메일을 보냅니다. 자기 계정으로 보내거나 회사 내부끼리만 검사하면 외부 수신자가 실제로 검사하는 경로를 놓칠 수 있습니다. 받은 메일에서 Gmail의 더보기 → 원본 보기처럼 전체 헤더를 여는 기능을 사용합니다.
1. 메일의 selector로 공개키를 찾아봅니다
dig +short TXT google._domainkey.example.com
# Microsoft 365를 쓰는 경우
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.comGoogle 예시는 콘솔의 공개키와 DNS 결과가 같은지 봅니다. Microsoft 예시는 두 CNAME 대상이 발급값과 같은지 확인하고, 필요하면 그 대상의 TXT도 조회합니다. 응답이 없거나 다른 값이라면 서명 검증보다 앞선 DNS 단계부터 해결해야 합니다. 여러 키를 차례로 추측하기보다 받은 메일에 적힌 selector 하나를 정확히 추적하는 편이 낫습니다.
2. 서명이 있다는 사실과 PASS를 구분합니다
From: sales@example.com
DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; s=google;
h=from:to:subject:date; bh=...; b=...;
Authentication-Results: mx.receiver.example;
dkim=pass header.d=example.com header.s=google;
dmarc=pass header.from=example.com첫 줄은 화면에 보이는 발신 주소입니다. DKIM-Signature는 보내는 곳이 붙인 서명이고, Authentication-Results는 받는 곳의 검사 결과입니다. 위 예시는 example.com 서명이 통과했고 From도 같은 도메인이므로 DKIM을 통한 DMARC 정렬까지 만족합니다.
헤더에 PASS라는 글자가 보인다고 아무 줄이나 믿지는 마세요. 실제 수신 서비스가 기록한 인증 결과를 봐야 합니다. 중간 서버의 오래된 결과나 발신자가 임의로 넣은 헤더가 섞일 수 있습니다. 수신 화면의 인증 요약과 원본 결과를 함께 확인하고, 판별이 어렵다면 수신 서비스 관리자에게 확인합니다. Authentication-Results의 신뢰 범위 ↗
표를 좌우로 밀어 전체 내용을 확인하세요.
| 관찰한 상태 | 의미 | 먼저 확인할 일 |
|---|---|---|
| DKIM 서명이 없음 / dkim=none | 검사할 서명이 없는 경우 | 서명 활성화와 실제 발송 경로를 확인합니다. |
| 서명은 있지만 검증 실패 | 서명과 받은 메일·키가 맞지 않음 | selector, 공개키, 중간 서버의 내용 변경을 확인합니다. |
| dkim=temperror | 검증 중 일시적 문제 | DNS 조회 오류 등 상세 원인을 확인하고 재시도합니다. |
| dkim=permerror | 검증을 진행하기 어려운 형식·설정 문제 | 상세 오류에 따라 서명·DNS 레코드를 수정합니다. |
| dkim=pass, dmarc=fail | 통과한 서명이 From과 정렬되지 않을 수 있음 | header.d와 From, 다른 서명·SPF 결과를 함께 봅니다. |
예를 들어 처음 보낸 메일에 회사 도메인 서명이 없다면 DNS 키를 다시 만드는 대신 발송 서비스에서 서명이 켜졌는지 확인합니다. 반대로 서명이 있는데 본문 해시 불일치가 나온다면, 뒤에서 안내 문구를 덧붙이는 발신 게이트웨이를 조사합니다. 문구를 넣은 뒤 서명하도록 처리 순서를 조정하고 새 메일로 다시 검사해야 수정 효과를 볼 수 있습니다. 발신 경로·메일 변경에 따른 DKIM 문제 ↗
3. 뉴스레터도 따로 보내서 확인합니다
이제 마케팅팀 메일을 받아 보니 아래와 같다고 가정해 보겠습니다. 발송 서비스의 서명은 통과했지만, 가온상사의 서명은 아닙니다.
설정 전
From: news@example.com
spf=pass smtp.mailfrom=bounce.mailer.example.net
dkim=pass header.d=mailer.example.net
dmarc=fail header.from=example.com
회사 도메인 DKIM 설정 후 새로 발송
From: news@example.com
spf=pass smtp.mailfrom=bounce.mailer.example.net
dkim=pass header.d=example.com header.s=news
dmarc=pass header.from=example.com수정할 곳은 뉴스레터 서비스의 발신 도메인 인증 메뉴입니다. 여기서 발급받은 별도의 DKIM DNS 값을 등록하고 회사 도메인 서명을 켭니다. Google의 공개키를 뉴스레터에 복사하는 방식으로 해결되지 않습니다. 각 서비스는 자기 개인키로 서명하므로 그 서비스에 맞는 공개키가 필요합니다.
설정 후 예시에서는 SPF 도메인이 여전히 다르지만 DKIM이 회사 도메인으로 통과해 DMARC도 통과합니다. 만약 서비스가 d=news.example.com으로 서명한다면 From이 example.com일 때 완화 정렬에서는 맞고, 엄격 정렬에서는 맞지 않습니다. d=를 바꿨다는 확인에 더해 실제 DMARC 결과까지 보세요. DMARC의 DKIM 도메인 정렬 ↗
정기 키 교체는 준비·전환·정리 순서로 합니다
키 교체는 현재 쓰는 개인키와 공개키 한 쌍을 새 쌍으로 바꾸는 일입니다. 직접 키를 관리한다면 새 selector를 먼저 준비하는 방식이 이해하기 쉽습니다. 아래는 현재 s=mail2026a를 쓰는 발송 시스템의 가상 교체 과정입니다.
- 01새 키 준비
mail2026b의 공개키를 먼저 DNS에 게시하고 조회를 확인합니다.
- 02서명 전환
새 개인키와 selector로 발송한 뒤 외부 수신 메일의 PASS를 확인합니다.
- 03이전 키 정리
지연 전송과 캐시를 고려한 유지 기간이 지난 뒤 이전 공개키를 폐기합니다.
새 키로 바꾸는 순간 이전 공개키를 지우면, 교체 전에 보냈지만 아직 전달 중인 정상 메일을 검증하지 못할 수 있습니다. DNS의 TTL은 캐시 유지 시간일 뿐 메일의 최대 지연 시간을 뜻하지 않습니다. 이전 키 유지 기간은 발송 큐, 재시도 정책, 서비스의 교체 절차를 함께 보고 정합니다. 모든 서비스에 동일한 시간을 적용하지 마세요. 키·selector 수명 주기 운영 ↗
관리형 서비스는 자체 교체 기능을 사용합니다. Microsoft 365는 두 selector를 번갈아 쓰며, 공식 문서의 교체 절차에는 96시간이 걸린다고 안내합니다. 이 시간을 Google이나 직접 운영하는 모든 DKIM의 규칙으로 해석하면 안 됩니다. RSA 2,048비트로 전환한다면 현재와 다음 selector의 키 길이까지 확인합니다. Microsoft 365의 키 교체 절차 ↗
개인키가 유출됐다면 정기 교체와 다릅니다
노출된 개인키를 누군가 계속 사용할 수 있으므로, 이전 키를 정상적으로 유지하는 계획부터 다시 판단해야 합니다. 발송 서비스의 침해 대응 절차에 따라 해당 키의 사용을 중단·폐기하고 새 키로 전환합니다. 동시에 서버·관리자 계정·발송 권한을 조사해야 새 키도 다시 노출되는 일을 막을 수 있습니다. 캐시된 공개키 때문에 폐기 효과가 즉시 모든 곳에 반영되지는 않을 수 있습니다. 개인키 보호와 운영 ↗
가온상사의 담당자는 직원 메일과 뉴스레터 각각에서 회사 도메인의 DKIM이 통과하고 From과 정렬되는지 확인했습니다. 어느 서비스가 어떤 키를 쓰는지도 기록해 두었습니다. 다음으로 DMARC를 설정해 리포트로 다른 발신처까지 확인하면 누락된 자동 알림이나 회사가 모르는 발송 경로도 조사할 수 있습니다.
Genharden DMARC · 2026.09.21 기준. SPF·DKIM·DMARC 표준과 본문에 연결한 공식 문서를 참고했습니다. 회사·도메인·IP·집계 수치는 별도 표시가 없는 한 설명을 위한 가상 예시입니다.