네이버웍스 메일 수신 안됨: MX·SPF·DKIM

Problem

커스텀 도메인을 네이버웍스에 연결했는데 메일이 불안정합니다: 수신 메일 일부가 끝내 도착하지 않고, 발신 메일 일부는 수신자 스팸함으로 가며, 실패가 전부가 아니라 무작위처럼 보입니다. 이건 거의 항상 반쯤 끝난 마이그레이션입니다 — 메일이 어디로 가고 어떻게 인증되는지를 정하는 DNS 레코드가 어중간한 상태로, 옛 시스템과 새 시스템이 둘 다 부분적으로 권한을 쥐고 있는 것이죠.

Symptoms

• 어떤 발신자는 네이버웍스 사서함에 닿고 어떤 발신자는 못 닿는데 반송이 없다 — 수신 메일이 두 메일 시스템으로 갈리고 있다는 신호.
• 네이버웍스 발신 메일이 지메일·아웃룩 스팸함으로 가거나, DMARC 레코드를 추가한 뒤 깐깐한 수신자에게서 반송된다.
• SPF 레코드를 게시했더니 모든 인증이 실패한다 — 전형적인 SPF 두 개 permerror.
• 테스트 때는 잘 되다가 DNS 전파가 끝나자(변경 후 24~48시간) 실제 발신자에게서 깨졌다.
• 이전 메일 호스트에서 네이버웍스로 도메인을 옮긴 직후 시작됐다.

실제로 뭐가 잘못됐나

네이버웍스의 커스텀 도메인 메일은 각각 다른 질문에 답하는 세 DNS 레코드에 기댑니다. 마이그레이션은 이걸 하나씩 깨뜨립니다.

MX는 “수신 메일이 어디로 가는가”에 답한다. 도메인은 네이버웍스의 수신 메일 호스트 — 도메인을 인증할 때 관리 콘솔에 표시되는 바로 그 값 — 를 MX로 게시해야 합니다. 이 레코드가 해석되기 전까지 메일 수신은 아예 불가능합니다. 사람들을 잡는 실패 형태는 MX 누락이 아니라 잔존 MX입니다. 이전 제공업체의 MX 호스트가 네이버웍스 것과 나란히 남아 있으면 split MX가 되고, 수신 메일이 두 시스템으로 흩어집니다.

SPF는 “어떤 서버가 이 도메인으로 발신해도 되는가”에 답한다. 네이버웍스는 발신 인프라를 spf.worksmobile.com 아래에 게시하고, 당신 SPF 레코드는 이걸 include:해야 합니다. 함정은 도메인이 SPF 레코드를 하나만 게시할 수 있다는 것 — 두 번째는 RFC 7208 §3.2의 permerror이고, 수신자는 추측하지 않고 거부합니다.

DKIM은 “이 도메인이 정말 이 메시지를 서명했는가”에 답한다. 네이버웍스는 발신 메일을 기본적으로 자체 worksmobile.com 키로 서명하는데, 이건 통과하지만 당신 From 도메인과 정렬되지 않습니다 — p=none보다 엄격한 DMARC 정책을 켜기 전까지는 충분하지만, 그 순간부터 도메인 정렬 서명의 부재가 비용이 되기 시작합니다. 정렬하려면 관리 콘솔에서 당신 도메인용 DKIM 셀렉터를 만드세요. 일부 DNS 제공업체는 2048비트 키를 단일 TXT 값에 담지 못하니, 그런 경우 네이버웍스에서 1024비트 키를 생성하면 됩니다.

Top 3 원인

1. 반쯤 끝난 마이그레이션의 split MX. 옛 제공업체의 MX 호스트가 네이버웍스 것과 함께 남아 있어, 수신 메일이 두 시스템으로 나뉘고 일부가 아무도 안 보는 사서함으로 사라집니다. 신호: 수신이 간헐적이고 발신자에 따라 갈리며 반송이 없고, 네이버웍스로 전환한 시점에 시작됨. 네이버웍스 수신 버그 중 압도적 1위입니다.
2. SPF 고장 — 네이버웍스 미포함이거나, SPF 레코드 두 개. SPF 줄에 include:spf.worksmobile.com을 넣지 않았거나(네이버웍스 발신 경로 미인가), 기존 것 옆에 두 번째 v=spf1 레코드를 게시해 permerror를 냈거나 둘 중 하나입니다. 신호: 발신 메일이 수신자에게서 SPF 실패, 혹은 뚜렷한 단일 결함 없이 인증 전체 실패.
3. DKIM이 worksmobile.com으로만 서명되는데 DMARC가 엄격. 도메인에 p=quarantine·p=reject를 켰지만 도메인 정렬 DKIM 셀렉터를 만들지 않아, 메일의 유일한 서명이 worksmobile.com입니다 — 유효하지만 미정렬이라 자기 DMARC를 통과 못 함. 신호: 발신 메일이 깐깐한 수신자에게서 격리되고, DMARC 리포트에 worksmobile.com은 DKIM 통과·당신 도메인은 미통과로 나옴.

DechoNet으로 진단

• 이메일 진단은 도메인의 MX·SPF·DKIM·DMARC 레코드를 한 번에 가져옵니다 — MX가 정확히 한 메일 호스트로 해석되는지, SPF가 네이버웍스를 include:하고 10-lookup 한도(RFC 7208 §4.6.4) 안에 드는 단일 레코드인지, 정책을 조이기 전에 DMARC 레코드가 존재하는지 확인하세요.
• DNS 조회는 도메인이 현재 게시 중인 모든 MX 호스트와 우선순위를 보여줍니다 — 옛 제공업체의 잔존 MX가 네이버웍스 것 옆에 앉아 있는지 잡는 가장 빠른 방법입니다.

해결 체크리스트

• 이메일 진단을 도메인에 돌리고 MX 목록을 읽으세요: 오직 네이버웍스 수신 호스트(관리 콘솔의 값)만 있어야 합니다. 이전 제공업체에서 남은 MX는 지우세요.
• SPF 레코드가 정확히 하나이고 include:spf.worksmobile.com을 담고 있는지 확인하세요. v=spf1 레코드가 둘이면 하나로 합치세요 — 두 개는 permerror입니다.
• SPF 총 DNS 조회 수를 10 미만으로 유지해 lookup 수로 permerror가 나지 않게 하세요(RFC 7208 §4.6.4).
• DMARC를 p=quarantine·p=reject로 운영한다면, 관리 콘솔에서 당신 도메인용 DKIM 셀렉터를 만들고 표시된 호스트/TXT 값을 게시하세요(DNS 제공업체가 2048비트를 거부하면 1024비트 옵션 사용).
• DNS 변경 후엔 전파를 기다리세요 — 최대 24~48시간 — 고친 게 안 먹혔다고 결론짓기 전에, 내부 계정이 아니라 실제 외부 발신자로 재테스트하세요.
• 테스트 메일을 밖으로 보내 헤더에서 spf=pass를, DMARC 정렬이 필요하면 worksmobile.com이 아닌 당신 도메인이 서명한 dkim=pass를 확인하세요.

에스컬레이션 시점

• MX가 깨끗하고(네이버웍스만), SPF가 spf.worksmobile.com을 포함한 단일 레코드인데도 특정 발신자의 수신 메일이 계속 사라진다면, 실패한 발신자의 반송·지연 리포트를 확보해 네이버웍스 지원에 티켓을 여세요 — 그 시점의 라우팅 결정은 그들 쪽에 있습니다.
• 도메인 정렬 DKIM을 게시했는데도 리포트에서 DMARC 정렬이 계속 실패한다면, 관리 콘솔이 생성한 셀렉터가 배포한 TXT 레코드와 실제로 일치하는지 확인하세요 — 긴 키의 복붙 잘림이, 네이버웍스 버그이기 이전에 흔한 범인입니다.