Google Workspace DKIM: TXT 등록 뒤 인증 시작해야 서명

Google Workspace에서 회사 도메인의 Gmail 발신 메일에 DKIM을 새로 적용하려면 관리 콘솔에서 키를 생성하고, 공개 키를 DNS TXT 레코드로 등록한 뒤, 해당 도메인에서 Start authentication을 눌러야 한다. Google의 DKIM 설정 절차는 TXT 등록과 서명 시작을 별도 단계로 안내한다. TXT를 저장한 것만으로는 발신 메일에 서명이 붙기 시작하지 않는다.

설정이 끝나면 회사 계정에서 다른 사람의 Gmail 또는 Google Workspace 주소로 새 메일을 보내 원본 헤더의 DKIM 결과를 확인한다. 관리 콘솔의 상태는 설정 진행 여부를 보여주지만, 수신 서버가 실제 메일의 서명을 통과시켰는지는 수신한 메시지에서 확인해야 한다. 자기 자신에게 보내는 시험 메일은 이 검증에 적합하지 않다.

발신 도메인의 키와 선택자 만들기

최고 관리자 계정으로 Google 관리 콘솔에 로그인해 앱, Google Workspace, Gmail, 이메일 인증으로 이동한다. 선택된 도메인이 실제 발신 주소의 도메인인지 확인하고 새 레코드 생성을 누른다. 여러 도메인을 운영한다면 각각에 고유한 키를 만들어야 하므로, 다른 도메인에서 표시된 값을 복사하지 않는다.

조직에서 Gmail을 막 사용 설정했다면 관리 콘솔에서 DKIM 키를 가져올 수 있을 때까지 24~72시간 기다려야 한다. 그 전에 키 생성을 시도하면 레코드를 만들지 못했다는 오류가 나타날 수 있다. 이때는 DNS 값을 반복해서 바꾸기 전에 Gmail을 사용 설정한 시점부터 확인한다. 이메일 인증 메뉴가 보이지 않는 경우에는 계정의 관리자 권한도 함께 확인할 필요가 있다.

DNS 제공업체가 지원하면 2048비트 키를 선택한다. 제공업체가 이 길이를 지원하지 않을 때 선택할 수 있는 길이는 1024비트다. 선택자(selector)의 기본값은 google이며, 이미 같은 도메인에서 google 선택자를 쓰는 DKIM 키가 있다면 다른 선택자를 지정한다. 선택자는 수신 서버가 서명을 검증할 공개 키의 DNS 위치를 찾는 데 쓰인다.

기존 메일 서버가 같은 회사 도메인의 메일에 DKIM 서명을 붙이고 있더라도 Workspace 발송분에는 별도의 키가 필요하다. MXToolbox의 Workspace 설정 안내도 기존 서버의 키와 구별되는 키를 생성하고 선택자로 구분하도록 설명한다. 기존 서버가 계속 메일을 보낸다면 그 서버의 레코드를 지우지 말고, 어느 발송 경로가 어느 선택자를 쓰는지 구분해 둔다.

관리 콘솔의 이름과 값을 DNS TXT에 등록하기

키를 생성하면 이메일 인증 화면에 DNS 호스트 이름과 TXT 레코드 값이 표시된다. 도메인의 DNS를 실제로 관리하는 서비스에서 TXT 레코드를 만들고, 호스트 또는 이름 칸에는 표시된 호스트 이름을, 값 칸에는 공개 키가 포함된 문자열을 입력한다. 기본 선택자를 썼다면 호스트 이름은 보통 google._domainkey 형태다. TXT 값은 v=DKIM1으로 시작하므로 공개 키 부분을 임의로 줄이거나 다른 서비스의 키로 바꾸지 않는다.

DNS 관리 화면이 도메인 이름을 자동으로 덧붙이는지 확인한다. 예를 들어 호스트 칸에 google._domainkey만 넣는 서비스에 도메인 전체까지 입력하면, 의도한 이름과 다른 위치에 레코드가 생길 수 있다. 저장 후에는 선택자와 도메인을 합친 이름으로 외부 DNS에서 TXT를 조회해 관리 콘솔의 값과 대조한다. 관리 화면에 레코드가 보이는 것과 외부에서 올바른 값을 조회할 수 있는 것은 서로 다른 확인 사항이다.

긴 공개 키를 입력할 때는 DNS 제공업체의 문자열 길이 제한도 살핀다. Google의 DKIM 문제 해결 안내에 따르면 255자 제한이 있는 DNS에서는 2048비트 키를 한 문자열로 입력할 수 없으며, 하나의 TXT 레코드 안에서 인용부호로 감싼 여러 문자열로 나눠 넣을 수 있다. 별개의 TXT 레코드 여러 개로 쪼개는 방식과는 다르다. 외부 조회 결과에서 공개 키가 빠지거나 순서가 바뀌지 않았는지 확인한다.

DNS 반영 뒤 인증 시작하기

공개 DNS에서 키가 올바르게 조회되면 관리 콘솔의 앱, Google Workspace, Gmail, 이메일 인증 화면으로 돌아간다. 레코드를 등록한 도메인을 선택한 상태에서 Start authentication을 누른다. 설정이 정상적으로 완료되면 상단 상태가 ‘Authenticating email with DKIM’으로 바뀐다. 여러 도메인에 키를 만들었다면 각 도메인에서 이 단계를 따로 마쳐야 한다.

TXT를 저장하자마자 관리 콘솔의 DNS 업데이트 안내가 사라지지 않아도 곧바로 키를 다시 만들 필요는 없다. 레코드를 정확히 추가한 뒤에도 안내가 최대 48시간 남을 수 있고, DKIM 인증이 작동하기까지도 최대 48시간 걸릴 수 있다. 먼저 외부 DNS 조회에서 호스트 이름과 공개 키가 맞는지 확인한 뒤 반영을 기다린다. 키를 다시 생성하면 DNS에 게시한 값과 관리 콘솔의 현재 값이 달라졌는지 추가로 추적해야 한다.

Start authentication을 누르지 않은 상태에서 TXT만 조회된다면 수신 서버는 공개 키를 찾을 수 있어도 Workspace의 도메인 서명 설정은 아직 완료되지 않은 것이다. ‘Not authenticating’ 상태가 보일 때는 선택한 도메인과 TXT 값을 확인하고 인증 시작 단계까지 진행한다. 콘솔의 상태가 바뀐 뒤에는 그때 새로 발송한 메일로 결과를 확인한다.

외부 수신 메일의 원본 헤더 확인하기

회사 계정에서 다른 사람의 Gmail 또는 Google Workspace 주소로 시험 메일을 보낸다. 수신자는 Gmail에서 메일을 열고 답장 옆 더보기 메뉴의 ‘원본 보기’를 선택한다. 원본 헤더의 Authentication-Results에서 dkim=pass 또는 dkim=OK와 같은 결과를 찾는다. DKIM-Signature 헤더도 함께 살피면 서명이 붙었는지와 수신 서버의 검증 결과를 구분하기 쉽다.

시험 메일은 확인하려는 발신 주소와 발송 경로에서 보내야 한다. 일반적인 회사 Gmail 발송을 확인하면서 별도의 외부 메일 서비스에서 시험 메일을 보내면 Workspace의 설정 결과를 판단할 수 없다. 수신함에 메일이 도착했다는 사실만으로 DKIM 통과를 결론 내리지 말고, 실제로 도착한 새 메시지의 인증 결과를 기준으로 삼는다.

원본 헤더에 DKIM 관련 결과가 보이지 않으면 선택한 도메인에서 인증을 시작했는지부터 확인한다. 서명이 보이는데 검증이 실패했다면 공개 DNS의 키와 관리 콘솔의 값을 다시 비교한다. 같은 도메인에 여러 발송 시스템이 있다면 어느 시스템이 시험 메일을 보냈는지도 확인해야 엉뚱한 키를 고치는 일을 피할 수 있다.

실패 지점에 따라 원인 좁히기

외부 DNS에서 TXT를 찾지 못하면 레코드를 저장한 서비스가 해당 도메인의 실제 DNS 관리처인지, 호스트 이름에 도메인이 중복으로 붙지 않았는지, 선택자가 관리 콘솔과 같은지 확인한다. 값은 조회되지만 콘솔의 공개 키와 다르다면 입력 중 잘림이나 문자열 순서 오류를 살핀다. DNS 값이 올바른데 콘솔이 아직 업데이트를 요구한다면 반영 시간을 고려해 다시 확인한다.

DNS와 콘솔 상태가 맞는데 수신 결과가 실패라면 메일이 서명된 뒤 변경됐는지 살핀다. 발신 게이트웨이가 모든 메일에 바닥글을 덧붙이는 것처럼 본문을 수정하면 DKIM 검증이 실패할 수 있다. Authentication-Results의 DKIM 결과에 ‘body hash did not verify’가 표시된다면 전달 과정에서 본문이 바뀌었을 가능성을 우선 점검한다. 전달된 메일에서만 문제가 생긴다면 최초 수신 메일과 전달된 메일을 구별해 비교한다.

수신 서비스에 따른 결과 차이를 가려야 할 때는 다른 외부 수신자에게도 새 메일을 보내 본다. 발송 경로, 선택자, DNS 공개 키, 인증 시작 상태가 일치하는데 특정 경로에서만 실패한다면 그 경로에서 메시지를 수정하는 장치가 있는지 확인할 수 있다. 이처럼 키 게시, 서명 활성화, 수신 검증을 순서대로 나눠 보면 실패한 지점에 맞춰 설정을 바로잡을 수 있다.

함께 읽기: