dnsrobot.net
본문 해시가 일치하지 않음
메일링 리스트가 153바이트의 푸터를 추가했습니다. 헤더는 project.example의 키로 여전히 검증되므로 위조가 아닙니다.
해결 본문을 그대로 두는 리스트, 또는 ARC(RFC 8617)를 사용해 이후 수신 서버가 원래 결과를 볼 수 있게 합니다.
body-hash-mismatchDKIM 확인
수신 메일 서버가 찾는 방식 그대로 도메인의 DKIM 레코드를 조회하거나, 메일을 붙여넣어 서명을 검증합니다: 어떤 셀렉터가 응답하는지, 누가 서명하는지, 각 키가 얼마나 강한지, DMARC와 정렬되는지 확인할 수 있습니다.
출처: 메일 제공업체 67곳의 일반 셀렉터 140개를 Google Public DNS(뒤에 Cloudflare)로 조회 · RFC 6376과 RFC 8301에 따른 키 점검 · 메일은 내 브라우저에서 검증 · 사용자에 대한 정보는 저장하지 않습니다
DNS는 셀렉터 목록을 보여 줄 수 없으므로, 메일 제공업체가 쓰는 셀렉터 140개를 selector._domainkey.에 도메인을 붙인 이름으로 조회합니다
예시
DKIM 레코드 확인하는 방법
위 칸에 도메인을 입력하세요: 확인 도구가 메일 제공업체가 쓰는 셀렉터 140개를 조회하고, 발견한 모든 키를 길이와 제공업체와 함께 보여 주며, 아무것도 찾지 못하면 그대로 알려 줍니다. 셀렉터를 알고 있다면 도메인 + 셀렉터를 선택하세요. 그것이 가장 먼저 확인됩니다.
직접 조회하려면 셀렉터가 필요합니다. DNS는 셀렉터 목록을 보여 줄 수 없기 때문입니다: dig +short TXT selector._domainkey.example.com, Windows에서는 같은 이름으로 nslookup -type=TXT를 사용합니다. 셀렉터는 모든 메일의 DKIM-Signature에 있는 s= 값입니다(RFC 6376 §3.6.2.1).
dig는 텍스트만 보여 줄 뿐 그 의미는 알려 주지 않습니다: 키 길이를 해독하지 않고, 제공업체의 CNAME을 따라가지 않으며, 대기용 자리와 고장 난 설정을 구분하지 못합니다. 이 DKIM 레코드 확인 도구가 그 부분을 채워 줍니다.
dig +short TXT selector._domainkey.example.com이 이름의 모든 TXT 문자열을 보여 줍니다: 이어 붙이면 키를 읽을 수 있습니다.
dig가 보여 주는 것과 보여 주지 않는 것
$ dig +short TXT 20251104._domainkey.google.com 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2
$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3
Public-Key: (2048 bit)
$ dig +short TXT selector1._domainkey.microsoft.com 4
selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.
- 1이름은 selector._domainkey.domain셀렉터가 없으면 응답도 없습니다: DNS에는 “모든 키 나열”이 없습니다.
- 2문자열 둘, 레코드 하나TXT 문자열은 255바이트까지라서 2048비트 키는 나뉩니다. 수신 서버는 사이에 아무것도 넣지 않고 이어 붙입니다.
- 3키의 실제 길이openssl이 p=를 해독합니다: RFC 8301이 요구하는 것은 2048비트입니다.
- 4제공업체로 가는 CNAME그 뒤에 TXT가 없습니다: Microsoft 365의 대기용 자리이며 오류가 아닙니다.
결과 읽는 법: 셀렉터 탐색
먼저 한 문장으로 답이 나옵니다. 그 아래에는 누가 서명하는지와 키 자체가 나옵니다: 각 태그를 실제 문자 위치에 색으로 표시하고, 키 길이를 RFC 8301 기준으로 보여 줍니다. 남색 배경에는 조회한 모든 셀렉터가 표시되어 무엇을 시도했는지 볼 수 있습니다.
점수는 없습니다: 폐기된 키나 제공업체의 빈 대기용 셀렉터는 정상이며, “일반 셀렉터에서 찾지 못함”은 “DKIM 없음”을 뜻하지 않습니다.
판정한 문장으로 키가 몇 개인지, 무엇을 해야 하는지 알려 줍니다.서명자제공업체마다 카드 하나. CNAME 또는 문서화된 셀렉터로 판별합니다. 각 셀렉터 칩을 누르면 해당 키가 열립니다.키각 태그를 문자 위치에 색으로 표시하고, 키 길이를 RFC 8301 기준으로 보여 줍니다.셀렉터 탐색조회한 이름이 응답할 때마다 불이 켜집니다: 초록은 키, 노랑은 1024비트, 점선은 대기용 자리입니다.DMARC 정렬이 도메인의 d=를 가진 키가 DMARC 정책과 정렬되는지 보여 줍니다.DKIM이란?
DKIM(DomainKeys Identified Mail)은 발신 서버가 각 메시지에 붙이는 서명이며, 수신 서버는 도메인이 DNS에 게시한 공개 키로 이를 확인합니다(RFC 6376). 유효한 서명은 두 가지를 증명합니다: d=의 도메인이 서명했다는 것, 그리고 서명된 부분이 그 뒤로 바뀌지 않았다는 것입니다.
발신자는 본문을 해시해 bh=에 넣고, 선택한 헤더와 그 해시를 개인 키로 서명해 b=에 넣습니다. 수신자는 d=와 s=를 읽고 s._domainkey.d에서 키를 가져와 두 과정을 다시 수행합니다. 본문이나 서명된 헤더가 한 바이트라도 바뀌면 실패합니다.
DKIM은 실패했을 때 어떻게 할지는 말하지 않으며, 어떤 도메인이든 서명할 수 있습니다. 그것은 DMARC의 역할입니다: d=가 From: 도메인과 일치하는 유효한 서명을 요구합니다.
메시지 하나, 발신 측에서 서명하고 수신 측에서 확인
example.com의 서버개인 키로 서명
DKIM-Signature가 붙은 메시지수신 서버Gmail, Outlook.com, Yahoo…
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…
dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048
전송된 그대로의 메시지
- 본문 해시가 bh=와 일치
- 헤더 서명 검증됨
dkim=pass header.d=example.com
전달 중에 Subject가 수정된 같은 메시지
- 본문 해시가 bh=와 일치
- 헤더 서명이 검증되지 않음
dkim=fail (signature-mismatch)
DKIM 셀렉터란 무엇이고, 내 셀렉터는 어떻게 찾나요?
셀렉터는 DKIM 키 하나의 이름입니다: 서명의 s=이자, 키가 있는 DNS 이름의 첫 번째 레이블입니다(s1._domainkey.github.com). 도메인은 원하는 만큼 둘 수 있습니다: 제공업체마다, 서버마다, 해마다 하나씩(RFC 6376 §3.1).
내 셀렉터를 찾으려면 도메인이 보낸 메일을 열어 원본을 보세요: Gmail의 더보기(⋮) › 원본 보기에 DKIM-Signature가 나오며, 그 s=가 셀렉터입니다. 또는 위의 메일 검증에 메일을 붙여넣으세요.
대부분의 제공업체는 고정된 이름을 쓰므로 탐색으로 찾을 수 있습니다. Amazon SES, Postmark, SparkPost, HubSpot은 계정마다 이름을 만들기 때문에 메일이나 제공업체의 대시보드에서만 알 수 있습니다.
서명에서 키까지, 그리고 제공업체가 쓰는 이름
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …
s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048
| Google Workspace | 관리자가 접두사를 바꿀 수 있음 | |
|---|---|---|
| Microsoft 365 | selector1 · selector2 | 테넌트로 연결되는 CNAME. 하나는 사용 중, 하나는 대기 |
| Twilio SendGrid | s1 · s2 | u<id>.wl<n>.sendgrid.net으로 가는 CNAME |
| Mailchimp | k2 · k3 | dkim2/dkim3.mcsv.net으로 가는 CNAME |
| Fastmail | fm1 · fm2 · fm3 | CNAME 세 개, 한 번에 하나만 채움 |
| Proton Mail | protonmail · 2 · 3 | domains.proton.ch로 가는 CNAME |
| Amazon SES | 무작위 토큰 3개 | 각각 무작위 32자: 추측할 수 없음 |
| Postmark | 20240101000000pm | 날짜와 “pm”: 추측할 수 없음 |
| SparkPost | scph + MMYY | scph와 키를 만든 달 |
| HubSpot | hs1-<HubID> | 내 계정 번호 |
DKIM 레코드 형식: 모든 태그 설명
DKIM 레코드는 세미콜론으로 구분한 태그=값 쌍으로 이루어진 TXT 레코드이며, 필수인 것은 공개 키인 p=뿐입니다. v=DKIM1은 생략할 수 있지만, 있으면 맨 앞에 와야 합니다(RFC 6376 §3.6.1).
k=는 키 종류(ed25519라고 쓰지 않으면 rsa), t=는 플래그(y는 테스트, s는 엄격), h=는 해시 제한, s=는 서비스 제한입니다. 빈 p=는 키를 의도적으로 폐기합니다.
태그 이름은 대소문자를 구분하며, 같은 태그를 반복하면 레코드가 무효가 됩니다. 알 수 없는 태그는 무시됩니다.
태그별로 본 레코드
v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB
| 태그 | 설정 내용 | 값 | 기본값 | 참고 |
|---|---|---|---|---|
| v= | 버전 | DKIM1 | DKIM1 | 권장, 있으면 맨 앞 |
| k= | 키 종류 | rsa · ed25519 | rsa | 알 수 없는 종류: 키 무시 |
| p= | 공개 키(base64) | 키 또는 비어 있음 | 필수 | 비어 있음 = 폐기 |
| t= | 플래그 | y 테스트 · s 엄격 | 없음 | y: 서명 없는 것으로 취급 |
| h= | 허용하는 해시 | sha256(sha1은 금지) | 전체 | sha1만 있으면 실패(RFC 8301) |
| s= | 서비스 종류 | * | 다른 서비스 전용: 무시됨 | |
| n= | 사람을 위한 메모 | 아무 텍스트 | – | 소프트웨어는 읽지 않음 |
p=의 길이와 필요한 TXT 문자열 수
RSA 1024216자 · TXT 문자열 1개
RSA 2048392자 · TXT 문자열 2개
RSA 3072564자 · TXT 문자열 3개
RSA 4096736자 · TXT 문자열 3개
Ed2551944자 · TXT 문자열 1개
255바이트 단위의 TXT 문자열 경계(“v=DKIM1; k=rsa; p=”를 포함해 계산)
1024비트와 2048비트 DKIM 키, 그리고 교체하는 방법
2048비트 RSA를 사용하세요. RFC 8301은 검증 측이 1024비트 키를 여전히 받아들이도록 요구하지만, 서명자에게는 2048비트 이상을 요구하고 검증 측은 1024비트 미만의 키를 거부하도록 정합니다. M3AAWG는 1024비트를 “공격당할 수 있는 한계”라고 부르며, 512비트 키가 약 72시간, 약 75달러로 해독되었다고 보고합니다.
Ed25519 키는 작고(p=는 44자), 하위 호환을 위해 RFC 8463은 서명자가 그 옆에 RSA 서명을 추가하도록 허용합니다: 셀렉터 둘, 서명 둘입니다(RFC 8463).
교체는 새 셀렉터에 새 키를 게시하고, 서명을 전환하고, 전송 중인 메일을 위해 이전 키를 7~30일 두었다가 그 p=를 비우는 순서로 합니다. M3AAWG는 6개월마다를 권합니다. Fastmail이나 Microsoft 365 같은 제공업체는 대기용 셀렉터로 이를 대신해 줍니다.
실제 키가 RFC 8301 기준의 어디에 있는지
실패유효, 2048비트로 교체양호일부 수신 서버에서 실패할 수 있음
- microsoft.com · selector2
- github.com · k1
- google.com · 20251104
- fastmail.com · fm2
- archlinux.org · dkim-rsa
- archlinux.org · dkim-ed25519 (Ed25519)
끊김 없는 교체(M3AAWG)
- 0일차새 셀렉터에 새 키 게시
- 1일차 이후서명을 새 키로 전환
- +7~30일전송 중인 메일을 위해 이전 키 유지
- 그다음이전 p=를 비우고, 이름은 재사용하지 않음
fastmail.comfm1빈 p=fm22,048fm3빈 p=CNAME 세 개 중 하나만 채움: 교체는 Fastmail 쪽의 DNS 변경으로 이루어집니다
DKIM은 왜 실패하나요? 본문 해시, 전달, 메일링 리스트
DKIM은 서명된 바이트가 바뀌었을 때, 키를 찾을 수 없을 때, 키가 서명과 맞지 않을 때 실패합니다. 메시지를 바꾸지 않는 전달은 DKIM을 그대로 유지합니다(SPF와 다릅니다). 메일링 리스트는 푸터를 붙이거나 제목에 태그를 달기 때문에 대개 DKIM을 깹니다.
이 페이지의 검증기는 본문 해시와 헤더 서명을 따로 확인하므로, 전달 중에 붙은 푸터와 위조를 구분할 수 있습니다.
서명이 검증되지 않음
서명한 뒤 서명된 헤더가 바뀌었거나(리스트가 Subject에 자기 이름을 붙임), 셀렉터에 지금 다른 키가 들어 있습니다.
해결 서명된 헤더를 고쳐 쓰지 마세요. 키를 교체하지 말고 새 셀렉터에 새 키를 게시하세요.
signature-mismatch서명에 맞는 키 없음
s=2023old._domainkey.shop.example이 NXDOMAIN입니다: 그 셀렉터로 서명한 메일이 아직 전송 중인데 셀렉터가 삭제되었습니다.
해결 전환한 뒤에도 이전 키를 7~30일 게시해 두고, 삭제하지 말고 p=를 비우세요.
key-not-found전달: 메시지를 바꾸지 않고 넘겨주는 전달 서비스는 DKIM을 유효하게 유지하므로, SPF가 실패해도 DMARC는 대개 DKIM 덕분에 전달을 견딥니다.
DKIM, SPF, DMARC의 차이
SPF는 어떤 서버가 도메인을 대신해 보낼 수 있는지 알려 주고, DKIM은 도메인이 서명했으며 바뀌지 않았음을 증명하고, DMARC는 둘을 From: 주소에 묶어 실패했을 때 어떻게 할지 알려 줍니다.
각각 다른 질문에 답하므로 셋 다 필요합니다: Gmail과 Yahoo는 대량 발신자에게 SPF와 DKIM, 그리고 DMARC 레코드를 요구하며, RFC 9989는 p=reject인 도메인에 SPF에 기대지 말고 DKIM으로 서명하도록 요구합니다.
레코드 셋, 질문 셋
| 레코드 셋, 질문 셋 | SPF | DKIM | DMARC |
|---|---|---|---|
| 무엇을 증명하나 | 이 서버가 MAIL FROM 도메인을 대신해 보낼 수 있음 | d= 도메인이 서명했고, 서명된 부분은 바뀌지 않음 | From:이 SPF 또는 DKIM을 통과한 도메인과 일치함 |
| 어디에 있나 | github.com의 TXT | s1._domainkey.github.com의 TXT | _dmarc.github.com의 TXT |
| 오늘의 github.com | v=spf1 … ~all | 키 12개, 제공업체 6곳 | p=quarantine; sp=reject |
| 전달을 견디나 | 아니요: 전달 서버의 IP가 등록되어 있지 않음 | 예, 메시지가 바뀌지 않고 도착하면 | 예, 정렬된 DKIM 통과를 통해 |
| 깨지는 때 | 새 발신 서비스가 레코드에 없을 때 | 본문이나 서명된 헤더가 바뀔 때 | From: 도메인에 대해 둘 다 통과하지 못할 때 |
메일의 DKIM-Signature 헤더 읽는 방법
원본 메시지를 열어 DKIM-Signature 헤더를 찾으세요: d=는 서명자, s=는 어떤 키인지, h=는 서명된 헤더 목록이고, bh=와 b=는 수신자가 확인하는 두 해시입니다.
수신자의 판정은 도착할 때 추가되는 별도의 헤더에 있습니다: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. 영어로 표시되는 Gmail의 Show original 페이지는 이를 “DKIM: 'PASS' with domain example.com”으로 요약합니다.
메시지 하나에 서명자마다 하나씩 여러 서명이 붙을 수 있습니다(내 도메인과 메일 서비스, 또는 메일링 리스트). DMARC에는 d=가 정렬된 유효한 서명이 하나만 있으면 충분합니다.
샘플 메일의 서명을 태그별로
v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9
- 1버전 v=항상 1
- 2알고리즘 a=rsa-sha256(또는 ed25519-sha256)
- 3정규화 c=relaxed는 줄 바꿈 변경을 허용
- 4서명 도메인 d=DMARC를 위해 From:과 비교됨
- 5셀렉터 s=s._domainkey.d에 있는 키
- 6서명 시각 t=Unix 시간: 2026. 10. 24. 오전 9:12
- 7서명된 헤더 h=from 두 번 = 중복 서명
- 8본문 해시 bh=정규화한 본문의 SHA-256
- 9서명 b=h=의 헤더와 이 필드에 대한 서명
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample
DKIM 확인: 자주 묻는 질문
DKIM 레코드란 무엇인가요?
DKIM 레코드는 도메인의 공개 키를 selector._domainkey.domain(예: google._domainkey.example.com)에 게시하는 TXT 레코드입니다. 태그=값 쌍이 들어 있으며, p=는 base64 키로 필수, k=는 키 종류, t=는 플래그입니다. 수신 서버는 이를 가져와 들어오는 메일의 DKIM-Signature를 확인합니다. 도메인은 셀렉터마다 여러 개를 게시할 수 있고, 보통 발신 서비스마다 하나입니다.
내 DKIM 셀렉터는 어떻게 찾나요?
도메인이 보낸 메일을 열어 원본 메시지를 보고 DKIM-Signature 헤더를 찾으세요: s= 뒤의 값이 셀렉터이고 d=가 도메인입니다. Gmail에서는 더보기(⋮) › 원본 보기, 웹용 Outlook에서는 View › View message source를 사용합니다. 또는 위의 “메일 검증”에 메일을 붙여넣으면 s=와 d=를 대신 읽어 줍니다.
메일은 서명되어 있는데 확인 도구가 키를 찾지 못하는 이유는 무엇인가요?
DNS는 셀렉터 목록을 보여 줄 수 없고, 키는 정확한 이름을 물어야만 찾을 수 있기 때문입니다. 확인 도구는 제공업체가 쓰는 이름 140개를 조회합니다. 다른 이름으로 서명한다면(Amazon SES와 Postmark는 계정마다 하나씩 만듭니다) 탐색에는 보이지 않습니다. 메일의 s=에 있는 셀렉터를 추가하면 가장 먼저 확인되며, 아니면 메일을 직접 검증하세요.
1024비트 DKIM 키는 아직 괜찮나요?
아직 작동합니다: RFC 8301은 검증 측이 1024~4096비트 RSA 키를 받아들이도록 요구하며, Gmail과 Yahoo는 1024비트를 최소로 정해 두었습니다. 하지만 RFC 8301은 서명자에게 2048비트 이상을 요구하고, M3AAWG는 1024비트를 “공격당할 수 있는 한계”라고 부릅니다. 교체를 계획하세요: Microsoft 365와 Google Workspace는 둘 다 2048비트 키를 제공합니다. RFC 8301은 검증 측이 1024비트 미만의 키를 거부하도록 정합니다.
빈 p=는 무슨 뜻인가요?
빈 p=는 키가 폐기되었다는 뜻입니다: 그 셀렉터의 서명은 키가 없을 때와 똑같이 실패합니다. 대개 의도된 것입니다. Google은 날짜가 붙은 이전 셀렉터를 이렇게 두며, Fastmail과 Microsoft 365는 교체해 들어갈 빈 대기용 셀렉터를 유지합니다. 지금 메일 서명에 쓰는 셀렉터일 때만 문제가 됩니다.
DKIM 레코드의 t=y는 무슨 뜻인가요?
t=y는 키를 테스트 중으로 표시합니다: 서명이 검증되더라도 수신 서버는 그 키로 서명한 메일을 서명 없는 메일처럼 취급해야 합니다. 처음 설정할 때를 위한 것이며 자주 잊힙니다. t=s는 다릅니다: 엄격하다는 뜻으로, 서명의 i=는 하위 도메인이 아니라 서명 도메인과 정확히 같아야 합니다. 일부 메일 서비스가 자사 키에 t=s를 게시합니다. github.com의 SendGrid 키가 그 예입니다.
DKIM이 “body hash did not verify”로 실패하는 이유는 무엇인가요?
수신자가 해시한 본문이 서명의 bh= 값과 일치하지 않으므로, 서명한 뒤 본문이 바뀌었다는 뜻입니다. 푸터를 붙이는 메일링 리스트, 링크를 다시 쓰는 보안 게이트웨이, 서버가 붙이는 면책 문구가 원인이 됩니다. 헤더 서명이 여전히 검증된다면 메시지는 진짜이지만 수정된 것입니다. 이 페이지의 검증기는 둘을 따로 확인합니다.
DKIM은 메일 전달을 견디나요?
대개 그렇습니다. 메시지를 바꾸지 않고 넘겨주는 전달 서비스는 서명을 유효하게 유지합니다. DKIM은 경로가 아니라 내용에 서명하기 때문입니다. 전달 서비스의 IP 주소에서 실패하는 SPF와 다른 점이 이것입니다. 푸터나 제목 태그를 붙이는 메일링 리스트처럼 메시지를 바꾸는 전달은 DKIM을 깹니다. ARC를 쓰면 원래 결과를 보증할 수 있습니다.
SPF가 있으면 DKIM은 필요 없나요?
필요합니다. SPF는 메일이 전달되면 깨지고 보이지 않는 MAIL FROM 주소만 다루지만, DKIM은 전달을 견디고 DMARC가 확인하는 From: 도메인과 정렬될 수 있습니다. Gmail과 Yahoo는 대량 발신자에게 둘 다 요구하고, Outlook.com은 2025년 5월부터 요구하며, RFC 9989는 p=reject인 도메인에 메일을 DKIM으로 서명하도록 요구합니다.
DKIM 키는 얼마나 자주 교체해야 하나요?
M3AAWG는 최소 6개월마다를 권합니다. 새 셀렉터에 새 키를 게시하고, 서명을 그 키로 전환하고, 전송 중인 메일이 계속 검증되도록 이전 키를 7~30일 게시해 둔 뒤, 삭제하지 말고 p=를 비우세요. 셀렉터 이름은 절대 재사용하지 마세요. CNAME 셀렉터를 쓰는 호스팅 제공업체는 키를 대신 교체해 줍니다.
여기서 검증하면 메일이 업로드되나요?
아니요. 이 DKIM 검증기는 메일을 내 브라우저에서 확인합니다: 공개 DNS에는 키 이름(s._domainkey.d)만 묻고, dnsrobot.net에는 From 도메인과 서명 도메인의 DMARC 정책만 묻습니다. 유일한 예외는 브라우저가 확인할 수 없는 Ed25519 서명입니다: 이 경우 페이지가 먼저 동의를 구한 뒤 메일을 한 번만 저희 서버로 보내며, 서버는 메모리에서 확인하고 아무것도 저장하지 않습니다.
Ed25519 DKIM 키를 사용할 수 있나요?
네. RFC 8463이 정의하며 검증 측은 지원해야 합니다. 하위 호환을 위해 RSA 키 옆의 별도 셀렉터에 게시하고, archlinux.org가 dkim-ed25519와 dkim-rsa로 하듯 모든 메시지에 두 번 서명하세요: Ed25519를 검증하지 못하는 수신 서버도 RSA 서명은 갖게 됩니다. Microsoft 365와 Google Workspace가 제공하는 것은 RSA 키뿐입니다.