이메일 받은편지함은 단순히 업무가 이루어지는 곳이 아니라 다른 모든 시스템으로 이어지는 마스터키입니다. 은행 비밀번호 재설정도 이메일, CRM 재설정도 이메일, 클라우드 인프라 계정 복구도 이메일을 사용합니다. 공격자가 받은편지함 하나를 장악하면 회사 전체로 피해를 확대할 수 있습니다.
안타깝게도 비즈니스 이메일을 운영하는 기업 대부분은 아래 설정 중 적어도 절반이 잘못 구성되어 있거나 아예 빠져 있습니다. 다행히 이를 바로잡는 데 보안팀이나 $50,000 규모의 엔터프라이즈 계약이 필요한 것은 아닙니다. 약 두 시간과 실제로 실행하겠다는 의지가 필요합니다.
이것은 기본선입니다. 미래의 이상적인 목표가 아니라 최소한의 조치입니다. 목록의 모든 항목을 확인할 수 없다면 아직 해결해야 할 위험이 남아 있습니다.
기업이 실제로 침해되는 방식
국가의 지원을 받는 공격자와 제로데이 익스플로잇만 걱정할 필요는 없습니다. 기밀 시스템을 구축하는 경우가 아니라면 누군가가 고도의 비용이 많이 드는 공격을 투입할 가능성은 높지 않습니다. 중소기업 이메일 사고의 90%와 관련된 것으로 알려진 세 가지 위험은 훨씬 일상적입니다.
크리덴셜 스터핑: 공격자는 LinkedIn 2012, Adobe 2013을 비롯한 수많은 침해 사고에서 유출된 비밀번호 데이터베이스를 구해 메일 서버를 대상으로 스크립트를 실행합니다. 현재도 사용하는 비밀번호가 유출 데이터에 포함되어 있다면 시스템 자체를 기술적으로 해킹하지 않고도 침입할 수 있습니다.
눈에 띄지 않는 전달 규칙: 영리한 공격자는 침입하자마자 계정을 난장판으로 만들지 않습니다. 대신 "제목에 '청구서' 또는 '송금'이 포함되면 attacker@gmail.com에 사본을 보내고 읽음으로 표시"하는 조용한 규칙을 만든 뒤 몇 달 동안 지켜봅니다. 알아챘을 때는 이미 결제를 가로챘을 수 있습니다.
스푸핑: 누군가 ceo@yourcompany.com에서 보낸 것처럼 꾸민 메일로 회계 담당자에게 긴급 송금을 요청합니다. 정상적인 메시지처럼 보입니다. DNS가 올바르게 구성되지 않았다면 수신 메일 서버에 위조를 판별할 정보가 부족해 경고를 표시하지 않을 수 있습니다.
적절한 대책을 적용하면 이 세 가지 공격의 발생 위험을 크게 낮출 수 있습니다. 방법은 다음과 같습니다.
기업용 보안 이메일: 계정 보안의 최소 기준
이 계층이 보안 경계입니다. 여기서 방어가 무너지면 DNS 설정만으로는 보호할 수 없습니다.
1. MFA를 예외 없이 적용하고 피싱 저항성을 강화
비밀번호만으로는 충분한 보안이 되지 않습니다. 누군가 문자열을 알고 있다는 사실만 확인할 뿐, 실제 직원인지는 증명하지 못합니다. 다단계 인증이 추가 검증 수단을 제공합니다.
Google Authenticator, Microsoft Authenticator, Authy 같은 인증 앱을 최소 기준으로 사용하고, 피싱 저항성이 필요한 계정에는 YubiKey 같은 하드웨어 키를 사용하세요. 다만 SMS 기반 2FA를 기본 수단으로 사용해서는 안 됩니다. 작동은 하지만 공격자가 이동통신사를 속여 전화번호를 자신의 기기로 옮기는 SIM 스와핑 공격에 취약합니다. 필요한 경우에만 예비 수단으로 사용하세요.
관리자 수준에서 MFA를 강제하세요. 선택 사항으로 두지 마세요. 사용자 한 명만 생략해도 가장 약한 고리가 될 수 있습니다.
TrekMail은 모든 관리자 계정에서 2FA를 지원합니다. 계정 보안 설정에서 활성화하세요. 전체 절차는 이중 인증 가이드에서 확인할 수 있습니다.
2. 레거시 인증을 즉시 차단
이는 2026년에도 가장 자주 간과되는 취약점 중 하나입니다. "레거시 인증"은 최신 MFA 흐름을 지원하지 않고 사용자 이름과 비밀번호만 요구하는 기본 SMTP AUTH 같은 방식을 말합니다.
문제는 모든 계정에서 2FA를 활성화했더라도 허용된 레거시 프로토콜로 접속하면 공격자가 이를 우회할 수 있다는 점입니다. 두 번째 인증 요소를 요청하지 않는 클라이언트에는 새 MFA 설정이 적용되지 않습니다.
테넌트 수준에서 레거시 인증을 차단하세요. 이메일을 보내야 하는 프린터, 스캐너 또는 구형 기기가 있다면 예외가 필요할 수 있습니다. 해당 기기를 격리하고 길고 복잡하며 정기적으로 교체하는 비밀번호를 가진 전용 서비스 계정을 부여하세요. 복합기에서 스캔 결과를 이메일로 보내야 한다는 이유로 일반 사용자 계정을 레거시 프로토콜에 노출하면 안 됩니다.
참고: TrekMail은 의도적으로 POP3를 지원하지 않습니다. 기기를 분실했을 때 복구할 수 없을 가능성이 있는 로컬 전용 이메일 저장을 피하기 위한 설계 결정입니다. 모든 클라이언트 연결에는 지원되는 IMAP을 사용해야 합니다.
3. 자격 증명 공유 금지
세 사람이 비밀번호를 문자로 주고받으며 공유하는 info@company.com 계정은 사소한 불편이 아닙니다. 보안 사고로 이어질 수 있는 상태입니다. 누군가 퇴사할 때 비밀번호를 바꿉니까? 대개 그렇지 않습니다. 마지막으로 로그인한 사람이 누구인지 압니까? 알기 어렵습니다.
해결책은 위임 액세스 또는 공유 사서함입니다. 각 사용자가 자신의 자격 증명으로 인증하고 공유 폴더에 접근합니다. 감사 추적을 남길 수 있고 개별 사용자의 권한을 철회할 수 있으므로 비밀번호를 공유할 필요가 없습니다.
사용자당 가격 모델은 이 방식에 불리하게 작용합니다. 좌석마다 $15-$30/월이 들면 비용을 줄이려고 자격 증명을 공유하는 팀이 생깁니다. TrekMail의 정액제는 좌석 수가 아닌 공유 스토리지를 기준으로 하므로 사용자가 5명이든 50명이든 좌석 때문에 가격이 달라지지 않습니다. 모두에게 개인 계정을 제공하고 $6/월을 아끼기 위해 비밀번호를 공유하지 마세요.
관리 및 액세스 통제
비상 복구 계정
휴대전화를 바다에 빠뜨리거나 주 ID 제공업체에 장애가 발생했을 때는 방금 실패한 시스템에 의존하지 않는 복구 경로가 필요합니다. 클라우드에만 존재하는 관리자 복구 계정을 하나 만드세요. 예를 들어 admin-recovery@yourdomain.com에 30자의 무작위 비밀번호를 설정합니다. 종이에 적어 물리적인 금고에 보관하세요.
그다음 이 계정에 로그인이 발생하면 다른 모든 관리자에게 즉시 알리는 경고를 설정하세요. 거의 사용하지 않아야 하는 계정입니다. 예상치 못한 로그인이 발생하면 즉시 조사해야 합니다.
직무 분리
웹 탐색, 링크 클릭, 뉴스레터 열람에 사용하는 일상 이메일 계정에는 전역 관리자 권한을 부여하지 마세요. 최고 관리자 상태로 로그인한 채 피싱 링크를 열면 공격자에게 광범위한 권한을 넘길 수 있습니다.
관리자 계정을 별도로 만들고 설정을 변경할 때만 로그인하세요. 나머지 작업은 표준 사용자로 수행합니다. 이는 과도한 경계가 아니라 모든 시스템 관리자가 첫날부터 권할 기본적인 운영 보안 수칙입니다.
기업용 보안 이메일: 메일 진위 확인의 최소 기준 (SPF, DKIM, DMARC)
이 세 가지 DNS 레코드는 스푸핑을 막는 기술적 장치입니다. Google과 Yahoo는 2024년부터 대량 발송자에게 이를 요구하며, 모든 비즈니스 이메일에서도 중요성이 커지고 있습니다. 아직 구성하지 않았다면 적법한 발송 출처를 확인한 뒤 설정하세요.
각 계층의 자세한 구현 순서는 이메일 도메인 설정 가이드에서 확인할 수 있습니다.
SPF: 승인된 발송자 목록
Sender Policy Framework는 도메인을 대신해 이메일을 보낼 수 있는 IP 주소를 명시하는 DNS TXT 레코드입니다. 목록에 없는 서버에서 온 메일은 레코드에 지정된 한정자에 따라 판정됩니다.
v=spf1 include:_spf.trekmail.net -all여기서는 두 가지를 올바르게 설정해야 합니다.
첫째, -all인 hard fail로 끝내고 ~all인 soft fail은 사용하지 마세요. soft fail은 "누가 이메일을 보내는지 확실하지 않으니 통과도 고려해 달라"는 약한 정책입니다. 적법한 발송자를 모두 확인한 후 hard fail을 사용하세요.
둘째, SPF에는 10회의 DNS 조회 제한이 있습니다. 동일한 레코드에 Google Workspace, Mailchimp, Salesforce, Zendesk를 포함하면 한도를 넘겨 알아차리기 어려운 SPF 오류가 발생할 수 있습니다. 여러 발송 서비스를 사용한다면 SPF flattening 도구를 신중히 사용하고 결과를 검증하세요.
DKIM: 변조를 드러내는 봉인
DomainKeys Identified Mail은 모든 발신 메시지에 암호학적 서명을 추가합니다. 개인 키를 보관하는 메일 서버가 이메일에 서명하고, 수신자 서버는 DNS에 게시된 공개 키로 이를 검증합니다.
SPF가 있어도 DKIM이 필요한 이유는 전달 과정에서 SPF 도메인 정렬이 깨질 수 있기 때문입니다. 메시지가 전달되면 발신 IP가 바뀌어 SPF가 실패할 수 있습니다. DKIM 서명은 메시지 헤더와 함께 전달되며 이후에도 유효하게 유지될 수 있습니다. 둘 다 필요합니다.
TrekMail은 유료 요금제에서 DKIM 키 생성과 교체를 자동으로 관리합니다. 공개 키가 DNS에 게시되고 모든 발신 메시지가 서명되므로 수동 구성은 필요하지 않습니다. 필수 DNS 레코드 가이드에서 무엇이 어디에 추가되는지 확인할 수 있습니다.
DMARC: 정책 적용 계층
DMARC는 SPF와 DKIM 어느 쪽에서도 인증 및 도메인 정렬 요건을 충족하는 결과를 얻지 못했을 때 어떤 처리를 할지 수신 메일 서버에 알립니다. 또한 도메인을 사용해 발송하는 출처에 관한 보고서를 보내 줍니다. 이를 통해 잊고 있던 마케팅 도구가 여전히 도메인을 대신해 발송하는 경우도 발견할 수 있습니다.
먼저 모니터링 모드로 시작하세요. 이 단계를 건너뛰지 마세요.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com이 레코드는 "내 도메인으로 발송하는 출처를 알려 주되 아직 아무것도 차단하지 말라"는 뜻입니다. 보고서를 두 주에서 네 주 동안 수집하고 모든 발송 출처를 점검하세요. 적법한 발송자가 모두 인증을 통과하는지 확인한 뒤에만 적용 정책으로 이동합니다.
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com그다음 최종적으로:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com먼저 점검하지 않고 바로 p=reject로 전환하면 청구서, 마케팅 이메일 등 완벽하게 구성되지 않은 적법한 발송 출처까지 차단할 수 있습니다. 단계적으로 진행하세요. DMARC 문서에서 전체 단계별 적용 절차를 확인할 수 있습니다.
전달 및 캐치올 주소의 안전
외부 자동 전달 차단
이 규칙 하나로 앞서 설명한 은밀한 데이터 유출 공격을 방지할 수 있습니다. 외부 도메인으로 자동 전달하지 못하도록 메일 서버를 구성하세요.
직원이 회사 이메일 전체를 개인 Gmail 계정으로 자동 전달해야 할 정당한 업무상 이유는 거의 없습니다. 여러 장소에서 접근해야 한다면 여러 기기에 IMAP 액세스를 설정하세요. IMAP은 이를 위한 프로토콜입니다. 모든 메시지를 외부 주소로 조용히 복사하는 전달 규칙은 설계 자체가 데이터 유출 경로입니다.
캐치올 주소 문제
캐치올 주소는 존재하지 않는 주소를 포함해 도메인의 어떤 주소로 전송된 메일도 받습니다. 편리해 보이지만 스팸 발송자도 이를 악용합니다. 공격자는 a@yourdomain.com, aa@yourdomain.com, ab@yourdomain.com 같은 주소로 사전 대입 공격을 퍼붓습니다. 이 중 하나에 답장하거나 해당 주소가 스팸 트랩이라면 도메인 평판이 손상될 수 있습니다.
명확한 운영상 이유가 없다면 캐치올 주소를 비활성화하세요. 필요하다면 매일 모니터링하고 엄격하게 필터링해야 합니다. TrekMail Pro 요금제는 내장 스팸 필터링과 함께 외부 캐치올 주소 라우팅을 지원합니다. 다만 캐치올 주소 설정 가이드에서도 설정 후 방치하지 말고 적극적으로 관리해야 한다고 설명합니다.
12개 항목으로 구성된 보안 기본 체크리스트
아래 항목을 모두 확인했다면 전담 IT팀이 있지만 아직 이 작업을 마치지 못한 기업을 포함한 많은 조직보다 견고한 구성을 갖춘 것입니다.
| # | 통제 항목 | 예방 대상 |
|---|---|---|
| 1 | 모든 계정에서 MFA 강제 | 크리덴셜 스터핑, 비밀번호 유출 |
| 2 | 레거시 인증 차단, 사용자용 기본 SMTP AUTH 금지 | 구형 프로토콜을 통한 MFA 우회 |
| 3 | 자격 증명 공유 금지, 위임 액세스만 사용 | 추적되지 않는 접근, 퇴사자 접근 위험 |
| 4 | 일상용 계정과 분리된 전용 관리자 계정 | 피싱에서 관리자 계정 침해로 이어지는 경로 |
| 5 | 비상 복구 계정을 만들고 오프라인에 보관 | 복구 경로 없는 계정 잠김 |
| 6 | SPF 레코드를 설정하고 -all로 끝내며 조회 수를 10회 이내로 제한 |
IP 기반 스푸핑 |
| 7 | DKIM 활성화, 키를 매년 교체 | 메시지 변조, 전달 시 인증 실패 |
| 8 | RUA 주소를 지정하고 DMARC를 최소 p=none으로 설정 |
보이지 않는 스푸핑, 발송 원본 파악 불가 |
| 9 | 서버 수준에서 외부 자동 전달 차단 | 받은편지함 규칙을 통한 은밀한 데이터 유출 |
| 10 | 캐치올 주소 비활성화 또는 엄격한 필터링 | 사전 대입 공격, 스팸 트랩 노출 |
| 11 | 오프보딩 체크리스트 마련 (비밀번호 재설정 → 세션 해지 → 기기 초기화) | 퇴사 후 남아 있는 접근 권한 |
| 12 | 외부 발송자 점검 (CRM, 청구, 마케팅) | 알 수 없는 원본의 DMARC 실패, 적법한 메일 차단 |
이 목록을 인쇄해 온보딩 운영 절차서에 넣고 여섯 달마다 다시 확인하세요.
사용자당 가격이 보안 문제가 되는 이유
분명하게 말할 필요가 있습니다. 일반적인 $6-$30/계정의 사용자당 가격 모델은 보안 조치를 줄이려는 직접적인 재정 압박을 만듭니다. 사용자마다 비용이 들면 개별 계정을 만드는 대신 info@ 비밀번호를 공유하는 팀이 생깁니다. 외부 계약자에게 개인 자격 증명을 주지 않거나, 마이그레이션이 비싸 보인다는 이유로 퇴사자 계정을 활성 상태로 남겨 두기도 합니다.
안전한 비즈니스 이메일에는 격리가 필요합니다. 모든 사람에게 개인 ID를 부여하고 서비스 봇에도 별도 계정을 제공해야 합니다. 이렇게 분리하지 않으면 신뢰할 수 있는 감사 추적을 남길 수 없습니다.
TrekMail의 정액제는 인원수가 아닌 공유 스토리지에 요금을 부과합니다. 사서함이 다섯 개든 오백 개든 좌석 수 때문에 가격이 달라지지 않습니다. 따라서 새 구성원이 생길 때마다 예산을 논의하지 않고 직원, 계약자, 서비스 계정에 각각 분리된 자격 증명을 제공할 수 있습니다.
요금제는 $3.50/월부터 시작하며 최대 50개 도메인과 도메인당 사용자 100명을 지원합니다. 일반적인 규모의 팀에서는 사용자당 비용이 미화 일 달러보다 훨씬 낮아질 수 있습니다. 모든 유료 요금제에는 카드 등록이 필요한 14일 무료 체험이 제공됩니다.
다음에 할 일
위 체크리스트를 살펴보고 빠진 항목을 솔직하게 확인하세요. 많은 기업이 첫 점검에서 적어도 세 개나 네 개의 공백을 찾습니다. 이는 드문 일이 아니며 수정할 수 있습니다.
노력 대비 효과가 큰 순서대로 다음 조치를 진행하세요.
- 모든 곳에서 MFA를 활성화합니다. 오늘 실행하세요.
- DMARC 보고서가 있다면 감사하고, 없다면 수집을 시작합니다.
- SPF가
-all로 끝나고 조회 제한을 넘지 않는지 확인합니다. - 서버 수준에서 외부 자동 전달을 차단합니다.
- 필요해지기 전에 비상 복구 계정을 만듭니다.
보안은 마법 같은 제품 하나를 구매하는 일이 아닙니다. 기본 설정을 올바르게 구성하고 계속 유지하는 일입니다. DNS를 구성하고 MFA를 강제하며 비밀번호 공유를 중단하세요. 이 조치를 함께 적용하면 기업을 실제로 노리는 공격의 상당 부분을 막을 수 있습니다.
처음부터 시작한다면 TrekMail은 DNS 마법사를 통해 DKIM과 SPF 설정을 자동으로 관리하고 설계상 POP3를 차단합니다. 정액제이므로 사용자를 분리하는 비용도 낮출 수 있습니다. 14일 동안 무료로 사용해 보세요.
