Gmail·Outlook을 쓰는데도 회사 메일 주소가 도용되는 이유

“Gmail을 쓴다”는 말부터 조금 더 살펴보겠습니다

가온상사 직원은 평소 “우리는 Gmail을 쓴다”고 말합니다. 재무팀 직원은 같은 회사 메일을 Outlook 앱으로 읽고 있습니다. 그렇다면 이 회사는 Google 메일을 쓰는 걸까요, Microsoft 메일을 쓰는 걸까요?

여기서는 메일을 보는 앱, 실제 메일을 보내는 서비스, 주소에 사용하는 도메인을 구분하면 됩니다. 앱은 메일을 읽고 작성하는 화면입니다. Outlook 앱에 Google 계정을 연결할 수도 있습니다. 앱 이름만으로 발송 서버를 알 수 없는 이유입니다. Outlook에 연결할 수 있는 계정 ↗

가온상사가 점검할 대상은 gmail.com이 아니라 회사가 소유한 gaon.example입니다. Google의 도메인이 잘 보호되어 있다는 사실과 가온상사 도메인에 인증이 올바르게 설정되어 있다는 사실은 따로 확인해야 합니다.

회사 주소를 쓰고 있다면 관리 담당자에게 세 가지를 확인해 보세요. 직원 메일은 어느 서비스에서 보내는지, DNS는 어디에서 수정하는지, 직원 메일 외에 회사 주소로 보내는 서비스가 있는지입니다. 도메인 구매 업체와 DNS 운영 업체가 다른 경우도 있어, 메일 서비스 관리 화면만 들여다봐서는 전체 구성이 보이지 않을 수 있습니다.

회사 서버를 거치는 메일과 밖에서 시작하는 메일

직원이 정상적으로 메일을 보낼 때는 회사가 사용하는 서비스에 로그인합니다. 서비스는 계정의 권한을 확인하고 메일을 발송합니다. 이 경로에서 강한 비밀번호, 2단계 인증, 로그인 이상 탐지는 회사 계정을 지키는 데 필요합니다.

반면 외부인이 회사 주소를 도용하는 시도는 두 번째 그림처럼 진행될 수 있습니다. 인터넷 메일에서는 발신 서버가 메일의 보낸 사람 칸인 From을 작성합니다. 여기에 가온상사 주소를 적었다고 해서 인터넷 전체가 먼저 가온상사 계정의 비밀번호를 물어보는 구조는 아닙니다.

메일 서비스가 자기 서버에서의 무단 발송을 제한해도 다른 서버의 발송 시도까지 모두 통제할 수는 없습니다. 따라서 가온상사 계정의 비밀번호를 바꾸는 작업과 이 경로를 막는 작업은 목적이 다릅니다. 외부 발송 시도라면 회사 서비스의 보낸편지함이나 발송 로그에 기록이 없을 수도 있습니다. 다만 보낸편지함에 없다는 사실만으로 계정 침해를 배제할 수는 없습니다. 기록이 지워졌거나 다른 권한·도구를 이용했을 가능성도 조사해야 합니다.

받는 곳에서는 무엇을 근거로 구별할까요?

SPF는 접속한 발신 서버의 IP가 허용 목록에 있는지 검사합니다. 다만 검사 기준은 보통 화면의 From이 아니라, 서버가 배달 실패 안내에 사용하는 MAIL FROM 도메인입니다. 받은 메일에서는 이 주소를 대체로 Return-Path에서 확인합니다. 외부인이 자기 도메인으로 SPF를 통과했다고 해서 From에 적힌 가온상사까지 인증된 것은 아닙니다. SPF가 검사하는 주소 ↗

DKIM은 메일의 전자서명을 확인합니다. 서명에 적힌 d=가 어느 도메인의 서명인지 알려줍니다. 유효한 서명이라도 그 도메인이 회사와 무관할 수 있으므로, DKIM의 PASS만 보고 회사 메일이라고 판단하면 안 됩니다. DKIM의 서명 도메인 ↗

DMARC는 그 빈틈을 확인합니다. SPF가 통과한 MAIL FROM 도메인이나, DKIM이 통과한 서명 도메인이 화면에 보이는 From 도메인과 맞는지 살펴봅니다. 이를 정렬이라고 합니다. 두 인증 중 하나가 통과하면서 정렬되어야 DMARC도 통과합니다. 실패 메일은 회사가 공개한 정책과 수신 서버의 자체 판단에 따라 처리됩니다. “다른 서버에서 보낼 수 있다”는 말이 “반드시 거래처 받은편지함에 도착한다”는 뜻은 아닙니다. DMARC의 검사와 처리 원칙 ↗

직원 메일 하나만 검사하면 놓치는 발신처가 있습니다

가온상사 관리자가 자기 계정에서 테스트 메일을 보내 봅니다. SPF·DKIM·DMARC가 모두 통과합니다. 이 결과는 그 직원 메일 경로가 잘 설정되어 있다는 증거입니다. 회사가 보내는 모든 메일의 인증이 끝났다는 뜻은 아닙니다.

가온상사는 매달 외부 청구서 서비스에서 billing@gaon.example 명의로 안내를 보냅니다. 고객지원 도구도 support@gaon.example을 씁니다. 이런 SaaS, 즉 인터넷으로 이용하는 업무용 서비스는 직원의 Google Workspace 계정을 거치지 않고 자체 서버에서 발송할 수 있습니다.

정상 청구서도 주소 도용 시도와 비슷한 인증 결과가 나올 수 있습니다

청구서 서비스가 기본 설정으로 자기 도메인 mailer.example.net을 사용한다고 가정해 보겠습니다. 가온상사는 보낸 사람 주소만 회사 주소로 바꾸고, 서비스의 “발신 도메인 인증” 절차는 아직 진행하지 않았습니다.

From: billing@gaon.example
Return-Path: bounce@mailer.example.net
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=gaon.example

SPF와 DKIM은 청구서 서비스의 도메인을 제대로 인증했습니다. 하지만 두 도메인 모두 gaon.example과 연결되지 않습니다. 받는 곳은 가온상사와 이 서비스 사이의 계약 관계를 모르므로, 그 관계를 인증 설정으로 보여줘야 합니다.

해결 방법의 하나는 청구서 서비스에서 회사 도메인으로 DKIM 서명을 켜는 것입니다. 해당 서비스가 발급한 DNS 레코드를 등록하고 활성화한 뒤 새 메일을 보냅니다. MAIL FROM이 서비스 도메인 그대로여도 dkim=pass header.d=gaon.example이 되면 DKIM을 통한 정렬을 만족할 수 있습니다. 실제 지원 방식은 서비스마다 다르므로 회사 도메인 서명 또는 사용자 지정 MAIL FROM 기능을 확인합니다. Microsoft의 외부 발신 서비스 설명 ↗

이 때문에 DMARC 실패를 발견하자마자 모두 공격으로 분류하거나, 모든 외부 IP를 SPF에 허용하는 방식은 적절하지 않습니다. 먼저 정상 계약·업무 기록과 대조하고, 정상 발신처라면 그 서비스가 공식적으로 안내하는 인증을 설정해야 합니다.

클라우드 서비스의 기본값도 실제 메일로 확인하세요

Google Workspace의 DKIM은 DNS에 키를 넣는 절차와 관리 콘솔에서 인증을 시작하는 절차를 함께 확인합니다. 이미 자동 설정된 환경도 있으므로 새 레코드를 무조건 만드는 대신 현재 상태부터 봅니다. RSA 키 길이를 선택한다면 Google은 지원 환경에서 2,048비트를 안내합니다. Google DKIM 설정과 검증 ↗

Microsoft 365에서는 사용자 지정 회사 도메인의 DKIM 설정을 확인하고, 관리 화면이나 PowerShell에 표시된 해당 도메인의 CNAME 값을 사용합니다. 다른 회사의 예시 값을 복사해서는 안 됩니다. Google이든 Microsoft든 최종 확인 기준은 외부에서 받은 메일에 회사 도메인의 서명이 실제로 붙고, 검증도 통과하는지입니다. Microsoft 사용자 지정 도메인의 DKIM ↗

의심 메일과 정상 메일의 원본을 나란히 읽어 보세요

가온상사 관리자는 거래처에 화면 캡처와 함께 받은 메일의 원본 또는 전체 헤더를 요청합니다. 헤더는 발신 주소, 전송 과정, 인증 결과 등이 들어 있는 메일의 기술 정보입니다. 본문만 복사하거나 일반 전달 버튼으로 새 메일을 만들면 원래 메일의 정보가 빠질 수 있어, 원본 다운로드나 첨부 형태로 보관하는 편이 좋습니다.

Gmail 웹에서는 메일을 열고 답장 옆 더보기에서 원본 보기를 선택합니다. 새 Outlook은 메일의 추가 작업 메뉴에서 보기 → 메시지 세부 정보 보기, 기존 Windows Outlook은 별도 창으로 메일을 연 뒤 파일 → 속성 → 인터넷 머리글에서 확인합니다. 메뉴 이름은 언어와 버전에 따라 조금 다릅니다. Gmail 원본 보기 ↗ Outlook 헤더 보기 ↗

아래는 두 메일에서 판단에 필요한 필드만 추린 가상 예시입니다. 긴 원본을 처음부터 끝까지 읽으려 하기보다 From → SPF·DKIM의 도메인 → DMARC 결과 순서로 살펴보세요. 예시의 mx.partner.example은 거래처가 사용하는 신뢰할 수 있는 수신 시스템이라고 가정합니다.

From: "가온상사 재무팀" <finance@gaon.example>
Return-Path: finance@gaon.example
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=gaon.example;
  dkim=pass header.d=gaon.example;
  dmarc=pass header.from=gaon.example

From: "가온상사 재무팀" <finance@gaon.example>
Return-Path: bounce@outside.example.net
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=outside.example.net;
  dkim=pass header.d=outside.example.net;
  dmarc=fail header.from=gaon.example

첫째, From의 실제 주소를 봅니다. A와 B는 모두 finance@gaon.example입니다. 화면에 표시되는 이름과 주소만으로는 두 메일을 구별할 수 없습니다. 주소를 펼쳐 보는 것은 필요하지만 이 경우에는 충분하지 않습니다.

둘째, PASS 옆의 도메인을 읽습니다. A의 smtp.mailfrom과 header.d는 모두 회사 도메인입니다. B에서는 모두 회사와 무관한 outside.example.net입니다. B의 PASS는 그 외부 도메인에 대한 검사 결과일 뿐, 가온상사가 보냈다는 뜻이 아닙니다.

셋째, DMARC 결과를 확인합니다. 이 예시에서는 회사에 유효한 DMARC 정책이 게시되어 있어 A는 PASS, B는 FAIL로 평가됩니다. 정책이 없는 환경에서는 dmarc=none처럼 표시될 수 있습니다. DNS의 p=none은 “실패를 이유로 격리·거부를 요청하지 않는 정책”이고, 메일 헤더의 dmarc=none은 인증 결과입니다. 같은 none이라는 단어가 보여도 서로 다른 항목입니다.

넷째, 실제 발송 기록과 대조합니다. B와 같은 결과가 나오면 발신 IP, 발송 시간, 수신자와 서비스의 발송 기록을 확인합니다. 앞에서 본 청구서 설정 오류도 비슷한 결과가 나올 수 있습니다. 발신처 목록에 없다는 이유만으로 끝내지 말고 담당 부서에 드물게 사용하는 서비스가 있는지도 물어봅니다.

이후에는 회사 DNS의 DMARC 정책과 RUA 집계 리포트를 함께 확인합니다. p=none으로 관찰 중이라면 정상 청구서의 실패부터 고치고, 누락된 발신처가 없는지 확인한 뒤 격리·거부 정책을 검토합니다. RUA는 보고하는 수신 서버가 관찰한 발신 IP·건수·인증 결과를 모은 자료입니다. 개별 메일 원문이나 직원의 로그인 기록은 아니므로 이번 사고의 전체 경로를 혼자 증명해 주지는 않습니다. DMARC 집계 리포트 표준 ↗

같은 “사칭메일”이라도 다음 조치는 달라집니다

거래처가 “회사에서 온 것처럼 보였다”고 말할 때는 몇 가지 상황이 섞여 있습니다. 이번 메일이 어느 경우에 해당하는지 먼저 나눠야 실제로 필요한 대응을 할 수 있습니다.

회사 도메인을 그대로 썼다면, 허용한 경로인지 확인합니다

가온상사가 보내지 않았고 정상 외부 서비스에서도 보낸 기록이 없다면, 정확한 도메인의 무단 사용 가능성을 조사합니다. SPF·DKIM의 누락을 고치고, DMARC 실패 메일을 격리하거나 거부하도록 요청하는 정책을 준비합니다. 정책을 강화하기 전에는 월말 청구서처럼 드문 정상 발송까지 확인해야 합니다. 거래처에는 확인되지 않은 메일이라는 사실과 실제 업무 연락처를 알려 혼선을 줄입니다.

주소가 닮았거나 이름만 같다면, 회사 DMARC의 대상이 다릅니다

gaon.example과 ga0n.example은 서로 다른 도메인입니다. 외부인은 자신이 관리하는 다른 도메인에 SPF·DKIM·DMARC를 올바르게 설정할 수 있습니다. 그 메일의 DMARC가 통과해도 가온상사와의 관계를 입증하지는 않습니다. 회사 도메인에 p=reject를 적용하는 것만으로 이런 메일을 모두 차단할 수는 없습니다. 수신 측의 사칭 탐지와 신고, 실제 주소 확인이 함께 필요합니다. DMARC가 확인하지 않는 범위 ↗

회사 도메인으로 통과했는데 담당자가 부인하면, 계정과 권한을 조사합니다

공격자가 정상 계정이나 발송 서비스의 권한을 얻으면 회사가 허용한 서버와 서명을 이용할 수 있습니다. 이 경우 인증은 정상적으로 통과할 수 있습니다. 인증 통과는 “담당 직원이 이 송금을 승인했다”는 의미가 아닙니다.

관리자는 해당 시간의 로그인과 발송 기록을 보존하고, 낯선 세션·앱 접근 권한·자동 전달 규칙·메일 삭제 규칙 등을 확인합니다. 침해가 의심되면 사용하는 서비스의 사고 대응 절차에 따라 접근을 차단하고 세션을 회수하며 자격 증명을 재설정합니다. 비밀번호만 바꾼 뒤 조사를 끝내면 다른 접근 권한이나 규칙을 놓칠 수 있습니다. Microsoft의 계정 침해 대응 안내 ↗

가온상사가 처음 받은 문의는 계좌 변경 안내였습니다. 이런 요청은 어떤 인증 결과가 나오더라도 기존에 알고 있던 전화번호로 담당자에게 별도 확인하는 업무 절차가 필요합니다. 의심 메일에 적힌 새 연락처로 확인하면 같은 사람에게 다시 묻게 될 수 있습니다. 이미 송금했다면 금융기관에 즉시 연락하고 관련 원본과 거래 기록을 보존해야 합니다. FBI의 업무메일 사기 대응 안내 ↗

이제 직원 메일과 외부 서비스에서 각각 보낸 메일의 원본을 모아, 회사 주소와 통과한 인증 도메인이 연결되는지 확인해 보세요. 그 결과와 의심 메일을 나란히 놓으면, 도메인 인증을 고칠 일인지, 다른 주소를 이용한 사칭인지, 계정 접근을 조사할 일인지 판단할 근거가 생깁니다.