DKIM 키가 조회 도구에서 여러 따옴표 문자열로 보인다고 해서 키가 손상된 것은 아닙니다. 한 TXT 레코드 안의 문자열 분할과 같은 이름에 존재하는 여러 TXT 레코드를 먼저 구분하세요. 레코드의 경계를 없애고 조회 결과 전체를 붙이면 다른 키까지 섞을 수 있습니다.
이어 붙이는 범위는 한 레코드 안이다
RFC 6376의 TXT 처리는 한 레코드 내부 문자열을 순서대로 붙이는 규칙을 다룹니다. Cloudflare TXT 문서의 긴 값 처리도 이 경계에서 읽어야 합니다. 두 resolver의 따옴표 분할 표시가 똑같아야 하는 것은 아니며, 복원한 논리 값과 응답 레코드 수를 비교해야 합니다.
길이 바이트와 문자열을 읽는 작은 파서에서 04 part 03 2nd라는 테스트 입력은 part2nd가 되었고, 길이가 실제 남은 바이트보다 큰 입력은 거부했습니다. 이것은 TXT 포맷의 경계 검사입니다. part2nd는 DKIM 공개 키가 아니며, 이 결과는 메일 서명이 유효하다는 증거가 아닙니다.
실제 메일의 selector에서 이름을 만든다
dig TXT selector1._domainkey.example.com +noall +comments +answer +authority
dig NS example.com +shortexample.com과 selector1은 예시입니다. 자신의 서명 헤더 d= 도메인과 s= selector, 메일 서비스가 안내한 레코드 종류를 먼저 확인하세요. 공급자가 CNAME을 요구하면 임의로 TXT로 대체하지 않습니다. zone 이름이 두 번 붙은 이름과 실제 위임된 권한 네임서버가 맞는지도 확인합니다.
NXDOMAIN은 이름 부재, NOERROR이지만 TXT 답이 없는 경우는 해당 형식의 답 부재, SERVFAIL은 조회 실패로 나눠 봅니다. 모두 “키를 잘못 입력했다”로 처리하지 않습니다. TTL과 조회 시각을 보관하고 권한 서버의 현재 값과 재귀 resolver 캐시를 비교하세요. TXT에는 일반 A·AAAA·CNAME 웹 트래픽처럼 프록시 토글을 적용하는 방식으로 접근하지 않습니다.
DNS가 맞으면 새 테스트 메일의 수신 측 Authentication-Results와 실제 selector를 확인합니다. DNS 조회 성공, DKIM 서명 검증, DMARC 정렬은 각각 다른 결과입니다. 공개 키 교체 때는 기존 발송 흐름과 캐시 유효기간을 고려하며, 이 글에서 실제 발송 성공을 확인한 것으로 해석하지 마세요.