DMARC 적용 전 점검표 뉴스레터·CRM·자동 발송 메일까지

IT 부서 밖에도 발신처가 있습니다

처음부터 “SPF와 DKIM이 설정된 서비스를 알려 주세요”라고 물으면 답을 받기 어렵습니다. 업무 담당자는 자신이 쓰는 도구는 알지만 메일을 보내는 서버까지 알지는 못합니다. 고객이 어떤 순간에 회사 이름으로 된 메일을 받는지부터 물어보세요.

가온상사에서는 뉴스레터 담당 서연이 “CRM에서도 상담 예약 안내가 나간다”고 알려 줬습니다. 재무팀 민수는 청구서 서비스를 회사 메일과 별개라고 생각해 처음 조사에서 빠뜨렸습니다. 서비스 이름만 묻는 것보다, 최근 고객에게 보낸 메일을 함께 보는 편이 이런 빈틈을 찾기 쉽습니다.

그다음에는 답변을 구독료 지출, 서비스 계정 목록, 발송 로그와 대조합니다. 구독 중인 도구라도 회사 도메인으로 발송하지 않을 수 있고, 무료 도구나 예전 외주 서버는 결제 목록에 없을 수 있습니다. DNS에 남은 SPF 허용 항목과 DKIM 레코드도 조사할 단서지만, 레코드가 있다는 이유만으로 현재 사용 중이라고 확정하지는 않습니다.

목록의 한 행은 “서비스”보다 “발신 경로”에 가깝습니다

같은 쇼핑몰에서도 주문 안내는 외부 메일 서비스로, 비밀번호 재설정은 오래된 웹서버로 보낼 수 있습니다. 같은 서비스라도 From 주소나 발송 방식이 다르면 행을 나눠 적으세요. 담당자에게는 설정을 바꿀 수 있는 사람과 업무 영향을 판단할 사람을 함께 연결해 둡니다. 외주 서비스라면 사내 담당자가 연락 창구를 맡으면 됩니다.

부서가 모르는 값을 억지로 채우게 할 필요는 없습니다. 우선 “비밀번호 재설정 / 개발팀 / 발신 도메인 미확인”으로 등록하고, IT 담당자가 다음 단계에서 시험 메일로 확인합니다. Google도 DMARC를 준비할 때 회사 대신 발송하는 외부 서비스의 인증을 확인하도록 안내합니다. Google의 외부 발송 서비스 점검 안내 ↗

점검표 한 행을 실제 메일로 완성합니다

서연이 보낸 뉴스레터에는 SPF와 DKIM 모두 pass라고 적혀 있었습니다. 하지만 자세히 보니 두 인증은 뉴스레터 업체의 mailer.example.net에 관한 것이었습니다. 고객에게 보이는 From은 news@example.com이어서, 회사 도메인과 연결되는 인증은 없었습니다.

인증 통과와 도메인 정렬을 함께 확인해야 하는 이유입니다. MAIL FROM은 배달 실패 안내에 쓰는 전송용 주소이고, DKIM의 d=는 서명한 도메인입니다. DMARC는 둘 중 하나가 인증을 통과하면서 From 도메인과도 맞는지 확인합니다. DMARC의 도메인 정렬 ↗

지윤은 뉴스레터 서비스의 회사 도메인 인증 기능에서 발급한 DNS 값을 등록하고, 서명 사용을 활성화했습니다. DNS 화면에 “확인 완료”가 뜬 뒤 새 캠페인을 시험 발송했습니다. 예전에 받은 메일을 다시 열어도 당시의 인증 결과는 바뀌지 않습니다.

From: 가온상사 <news@example.com>
Return-Path: <bounce@mailer.example.net>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=bounce@mailer.example.net;
  dkim=pass header.d=example.com header.s=news2026;
  dmarc=pass header.from=example.com

SPF는 여전히 뉴스레터 업체 도메인으로 통과합니다. 대신 회사 도메인인 example.com으로 DKIM이 통과해 DMARC도 통과했습니다. news2026은 서명 키를 찾는 이름인 selector입니다. 실제 값은 서비스가 발급하며, 이 이름이나 다른 회사의 DNS 값을 그대로 복사해서 쓰면 안 됩니다.

헤더를 볼 때는 수신 서비스가 기록한 인증 결과를 확인합니다. 원문에 Authentication-Results가 여러 개 있다면 맨 처음 보이는 줄을 임의로 고르지 말고, 수신 서비스의 원본 보기나 관리 도구에서 신뢰하는 결과를 확인하세요. 전달된 메일은 중간 서버가 남긴 결과도 함께 들어 있을 수 있습니다. 인증 결과 헤더의 신뢰 범위 ↗

발신처 점검표 CSV 내려받기 ↓

이제 다음 담당자는 “뉴스레터 정상”이라는 말보다 훨씬 많은 것을 알 수 있습니다. 어떤 인증에 의존하는지, 누가 확인했는지, 무엇을 다시 봐야 하는지가 남기 때문입니다. 같은 서비스에서 From이나 발송 경로가 달라진다면 이 행을 그대로 재사용하지 않고 추가로 검증합니다.

CSV에는 고객 주소나 메일 원문을 모두 넣지 않아도 됩니다. 접근을 제한한 내부 점검 기록에 시험 수신처, 메시지 식별값, 헤더, 관련 설정 변경을 보관하고, “다음 조치” 칸에는 그 기록 번호를 적으세요. 확인하지 못한 칸은 미확인으로 둡니다. 빈칸을 pass로 해석할 여지를 남기지 않는 것이 좋습니다.

테스트 버튼보다 실제 업무를 확인합니다

가온상사의 쇼핑몰 관리 화면에서 보낸 시험 메일은 정상이었습니다. 하지만 비밀번호 재설정 기능은 다른 서버를 쓰고 있었습니다. 관리 화면의 “테스트 발송”이 모든 업무 경로를 대표한다고 생각하면 이런 차이를 놓칩니다.

고객에게 시험 청구서를 보내거나 실제 결제를 발생시키지 않도록 업무 담당자와 시험 범위를 정합니다. 운영 환경과 다른 시험 환경에서 확인했다면 차이도 적어 두세요. 테스트 서버가 통과했다는 사실만으로 운영 서버를 완료 처리할 수는 없습니다.

“DNS 등록”, “메일을 보냄”, “인증 통과”를 구분하세요

DNS 등록을 확인했지만 메일을 보내지 않았다면 아직 발송 미검증입니다. 발송 버튼은 눌렀지만 서비스 로그에 대기 상태라면 미발송일 수 있습니다. 발송은 됐지만 수신되지 않았다면 발송 로그와 반송 사유를 먼저 확인합니다. 이를 모두 “DMARC 실패”라고 적으면 원인을 잘못 찾게 됩니다.

메일이 도착해 dmarc=fail을 확인했다면 그때 인증과 정렬을 조사합니다. 반대로 dmarc=pass인데 스팸함에 들어갔다면 인증 결과와 받은편지함 도착 결과를 나눠 기록합니다. 실제로 고객이 많이 사용하는 수신 서비스를 골라 확인하되, 그 결과를 모든 수신처에 대한 보장으로 확대하지는 않습니다.

전달된 메일은 도착 지점에서 다시 봅니다

자동 전달을 거치면 최종 수신 서버가 보는 발신 IP가 달라집니다. SPF가 실패하거나 전달자 도메인으로 통과해 회사 From과 맞지 않을 수 있습니다. 메일링리스트가 제목이나 본문을 바꾸면 DKIM도 영향을 받을 수 있습니다. 직접 보낸 메일이 통과해도 전달된 메일은 별도 검증해야 합니다. 전달·메일링리스트에서 생기는 인증 문제 ↗

전달 후 도착했다는 사실만으로 DMARC 통과로 기록하지 마세요. 수신 측 예외 처리로 받아졌을 수도 있습니다. 문제를 발견하면 중간 서비스 운영자와 확인하고, 정상 업무가 계속되는 방식을 정한 뒤 다시 시험합니다. 전달 서버를 모두 SPF에 추가하는 식의 일괄 수정은 피합니다.

메일을 보내지 않는 도메인은 따로 판단합니다

가온상사는 새 브랜드를 위해 example.org도 보유하고 있습니다. 홈페이지는 있지만 직원 메일에는 쓰지 않는다고 합니다. 그렇다면 바로 “미사용 도메인”이라고 적어도 될까요? 홈페이지 문의 답장, 관리자 알림, 웹메일의 다른 주소로 보내기 기능이 이 도메인을 사용하는지 먼저 확인해야 합니다.

해당 도메인이 보낸 사람 주소인 From에 쓰이는지뿐 아니라 MAIL FROM이나 DKIM 서명에 쓰이는지도 살펴보세요. 도메인 관리자, 메일 계정 관리자, 웹사이트와 외주 운영자가 각각 확인해야 할 부분이 다릅니다. “직원 계정이 없다”는 사실과 “메일을 전혀 보내지 않는다”는 결론 사이에는 이런 확인이 필요합니다.

example.org          TXT  v=spf1 -all
_dmarc.example.org   TXT  v=DMARC1; p=reject

v=spf1 -all은 이 도메인에 대해 SPF로 허용하는 발신 서버가 없음을 나타냅니다. p=reject는 이 도메인을 From으로 쓰면서 DMARC를 통과하지 못한 메일의 거부를 요청합니다. DNS 관리 화면에서는 도메인이 자동으로 붙는지 확인해 호스트 이름을 입력합니다. Microsoft도 발송하지 않는 도메인에 거부 정책을 안내합니다. Microsoft의 미사용 도메인 설정 안내 ↗

DMARC의 np=는 DNS에 존재하지 않는 하위 도메인에 대한 정책입니다. “메일을 보내지 않는 도메인”을 뜻하는 값이 아니므로, 홈페이지가 있는 브랜드 도메인의 미발송 설정을 대신하지 않습니다. DMARC의 하위 도메인 정책 항목 ↗

수신만 하는 도메인이라면 수신용 MX는 필요할 수 있습니다. 위 작업에 MX 삭제를 포함하지 마세요. 또한 유효한 회사 도메인 DKIM 서명이 붙으면 SPF가 실패해도 DMARC는 통과할 수 있습니다. 발송을 종료한 서비스의 계정과 서명 권한이 남아 있는지도 확인해야 하는 이유입니다.

체크 표시 옆에 판단 근거가 있어야 합니다

가온상사는 뉴스레터 문제를 해결했지만, 민수가 쓰는 월말 청구서 서비스는 아직 시험하지 못했습니다. 다른 메일이 모두 통과해 전체 통과율이 높더라도, 청구서가 고객에게 가지 않으면 업무가 멈춥니다. 지윤은 청구서 확인 일정을 정하고 정책 전환을 보류했습니다.

다음 여덟 항목은 이런 누락을 다시 살피기 위한 것입니다. 먼저 읽고, 점검표나 내부 기록에서 근거를 찾을 수 있는 항목에 체크하세요.

1~4번: 목록과 시험 결과가 연결되어 있나요?

서비스 이름만 모았다고 첫 번째 항목을 완료하지는 않습니다. 업무 담당자가 목록을 확인했고, 누가 설정을 관리하는지까지 있어야 합니다. 두 번째 항목에는 실제 메일에서 읽은 도메인 값이 필요합니다. 세 번째에는 시험한 업무·수신처·시각과 정렬을 포함한 인증 결과가 있어야 합니다.

네 번째는 최근 며칠의 결과로 대신하기 쉽습니다. 하지만 아직 분기 공지를 보내지 않았다면 리포트에 보이지 않는 것이 자연스럽습니다. 같은 운영 경로로 시험하거나 실제 발송을 확인할 일정을 정합니다. 중요한 정상 경로가 미확인인 상태를 “실패 없음”으로 처리하지 않습니다.

5~6번: 실패의 정체와 정책의 범위를 확인했나요?

RUA는 수신 서버가 관찰한 발신 IP와 인증 결과 등을 모은 집계 리포트입니다. DMARC의 rua=에 실제 수신 가능한 주소를 지정하고, 누가 리포트를 검토할지도 정해 둡니다. 정상 발신처의 실패가 보이면 업무 로그와 대조해 원인을 찾습니다. 지윤은 뉴스레터 수정 뒤 새로 발송한 기간의 리포트에서 회사 도메인 서명이 확인되는지도 봤습니다. 집계 자료이므로 시험 메일 한 통과 일대일로 연결되는 기록은 아닙니다. DMARC 집계 리포트의 범위 ↗

모르는 IP를 발견했다고 모두 주소 도용으로 분류하거나, RUA에 없다고 사용하지 않는 서비스로 확정하지는 않습니다. 발송 목록과 담당자에게 다시 확인합니다. 여섯 번째 항목은 하위 도메인별 정책, 위탁 운영 여부, 미사용 판단의 근거까지 검토했을 때 체크합니다.

7~8번: 변경 뒤 문제가 생기면 누가 움직이나요?

변경 전 DNS 값과 TTL, 변경할 도메인·정책, 실행 시각을 남깁니다. 복구 조건도 “문제가 생기면”보다 “정상 청구서의 인증 실패가 재현되면”처럼 구체적으로 정하세요. 설정을 되돌릴 IT 담당자와 고객 업무를 확인할 담당자가 모두 연락 가능해야 합니다. DNS 캐시 때문에 되돌린 값이 즉시 모든 곳에 반영되는 것은 아닙니다.

가온상사는 청구서 시험과 남은 전달 경로를 확인한 뒤 정책 변경 일정을 잡습니다. 변경 직후에는 주요 업무를 다시 시험하고, 이후에는 리포트와 반송·문의 기록을 함께 봅니다. 관찰 기간은 “며칠이 지났나”보다 월말·분기 같은 실제 발송 주기를 얼마나 확인했는지로 판단하세요. 정책 전환 전 발송 주기와 인증을 확인하는 이유 ↗

위 체크 상태는 새로고침하면 초기화됩니다. 완료 근거와 남은 일은 내려받은 CSV에 보관하세요. 정책 값의 선택과 전환 순서는 DMARC 정책 가이드에서 이어서 확인할 수 있습니다.

서비스를 도입하고 종료할 때 점검표를 갱신합니다

몇 달 뒤 가온상사가 CRM을 바꾸면 같은 확인이 다시 필요합니다. 새 도구의 “발송 성공” 화면을 보고 끝내지 않고, 담당자를 정해 점검표에 새 행을 추가합니다. 회사 도메인 인증, 실제 업무 시험, 수신 헤더 확인을 고객 대상 발송 전에 마칩니다. 기존 도구와 동시에 운영하는 기간에는 두 경로를 모두 목록에 남깁니다.

계약을 종료할 때는 역순으로 살펴봅니다. 예약된 캠페인, 자동화 규칙, 재발송 대기, 정기 청구가 남아 있지 않은지 먼저 확인합니다. 담당자가 “안 쓴다”고 말한 날짜와 실제 마지막 발송 기록을 대조하고, 영향을 받는 업무가 새 서비스로 옮겨졌는지 시험합니다.

그다음 사용하지 않는 SPF 허용 항목, DKIM 공개키나 CNAME 위임, 서비스 계정과 API 권한을 정리합니다. 하나의 include나 발송 계정을 다른 업무가 공유할 수 있으므로 이름만 보고 지우지는 마세요. 남겨야 할 서비스가 없는지 확인하고, 변경 뒤에도 계속 쓰는 발신 경로를 다시 시험합니다.

재점검이 필요한 계기는 새 서비스 도입뿐만이 아닙니다. From 주소 변경, 도메인 추가, DKIM 키 교체, 전달 방식 변경도 같은 점검표에 기록할 만한 변화입니다. 회사 주소로 메일을 보내는 경로를 다음 담당자도 설명할 수 있게 기록을 남겨 두세요. 그 기록이 있으면 다음 정책 변경은 훨씬 수월해집니다.