이메일 보안 실전 가이드: SPF·DKIM·DMARC 설정과 BEC 거래 가로채기 방어 완벽 정리

"결제 계좌가 변경되었습니다. 새 계좌로 송금 부탁드립니다." 진행 중이던 거래의 한복판에서 이 한 줄을 받았을 때, 당신은 그것을 의심할 수 있을까요? 이메일은 인터넷에서 가장 오래된 통로이면서, 동시에 한 번의 사고로 가장 비싼 청구서가 날아오는 통로입니다.

이메일은 1970년대 설계 사상을 아직도 등에 업고 돌아갑니다. 처음 만들어질 때 보안은 우선순위가 아니었습니다. 그래서 발신자를 위조하기 쉽고, 평문으로 오가던 시절의 흔적이 구조 곳곳에 남아 있습니다. 이후 수십 년 동안 보안 장치들이 덧대어졌지만, 문제는 그 장치들이 "기본값으로 켜져 있지 않다"는 데 있습니다. 설정하지 않으면 이메일은 30년 전과 똑같이 취약합니다.

이 글은 이메일 보안을 세 덩어리로 나눠 다룹니다. 첫째는 발신자 인증 — 누군가 당신의 도메인을 사칭해 메일을 보내는 것을 막는 SPF·DKIM·DMARC. 둘째는 거래 가로채기(BEC) — 이메일을 엿보던 공격자가 송금 직전에 끼어들어 돈을 채가는, 통계적으로 가장 비싼 공격. 셋째는 계정 자체의 보호 — 이메일은 다른 수많은 계정의 마스터 열쇠이기 때문입니다.

먼저 큰 그림을 머리에 넣고 가겠습니다. 이메일 사고의 피해는 두 가지 얼굴로 옵니다. 하나는 거래 탈취처럼 한 번에 크게 터지는 피해이고, 다른 하나는 증상 없이 조용히 새어 나가는 정보 유출입니다. 앞의 것은 즉시 아프고, 뒤의 것은 아픈 줄도 모릅니다. 그래서 더 위험합니다.

발신자 인증: 위조를 막는 세 글자 약어 세 개

이메일의 가장 본질적인 약점은 "보낸 사람"란을 누구나 위조할 수 있다는 것입니다. 종이 편지의 봉투 발신인을 아무렇게나 적을 수 있는 것과 같습니다. 공격자는 billing@당신회사.com에서 보낸 것처럼 보이는 메일을, 당신의 서버를 거치지 않고도 발송할 수 있습니다. 이를 막기 위해 세 가지 표준이 함께 작동합니다.

세 장치가 각각 맡는 일

세 약어가 헷갈리기 쉬운데, 역할로 외우면 단순합니다.

정리하면, SPF와 DKIM은 검증 수단이고 DMARC는 그 결과에 따른 정책 + 감시 카메라입니다. SPF가 "이 서버에서 보낸 게 맞나"를 보고, DKIM이 "내용이 변조 없이 서명 그대로인가"를 보고, DMARC가 "둘 중 하나라도 실패하면 거부할지 격리할지"를 정하고 그 통계를 매일 리포트로 보내줍니다. DMARC 정책 태그(p=none/quarantine/reject)의 정확한 동작은 표준을 제정한 dmarc.org에 정리되어 있습니다.

세 가지를 다 켜면, 공격자가 당신의 도메인을 사칭해 메일을 보내기가 극적으로 어려워집니다.

실제로는 DNS TXT 레코드 세 줄이다

거창해 보이지만, 세 장치 모두 DNS의 TXT 레코드 한 줄씩으로 설정됩니다. 도메인 등록 기관이나 메일 서비스(Google Workspace, 네이버웍스 등)의 관리 화면에서 추가하면 됩니다. 형태를 감 잡을 수 있게 예시를 보겠습니다(값은 환경마다 다릅니다).

; SPF — Google Workspace를 메일 발송에 쓰는 경우
example.com.            IN TXT "v=spf1 include:_spf.google.com ~all"

; DMARC — 우선 관찰 모드(p=none)로 시작, 리포트는 dmarc 주소로 수집
_dmarc.example.com.     IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

; DKIM — 메일 서비스가 발급한 공개키를 셀렉터 이름으로 게시
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...(공개키 본문)...IDAQAB"

운영 팁 한 가지. DMARC는 처음부터 p=reject로 켜지 마세요. 정당한 메일까지 차단해버릴 수 있습니다. p=none(관찰만) → 리포트로 통과율 확인 → p=quarantine(스팸함) → p=reject(완전 거부) 순서로 몇 주에 걸쳐 단계를 올리는 것이 정석입니다. rua 주소로 들어오는 집계 리포트를 보면 누가 내 도메인을 사칭하려 했는지, 어떤 정당한 발송 경로가 인증에서 빠졌는지가 그대로 드러납니다.

설정했다면 — 또는 "옛날에 넣어 뒀다"고 믿는다면 — 반드시 검증하세요. MXToolbox에 도메인을 넣으면 회원가입 없이 즉시 SPF·DKIM·DMARC 게시 상태를 보여줍니다. 현장에서 고객사 도메인을 넘겨받으면 가장 먼저 돌려보는 점검이 바로 이것인데, "분명히 설정했다"는 도메인의 절반쯤은 다음 셋 중 하나였습니다.

• 오타가 나서 레코드가 무효
• SPF만 있고 DKIM·DMARC는 비어 있음
• 메일 서비스를 옮기면서 레코드가 깨짐

왜 DKIM을 특별히 강조하는가

세 장치 중에서도 DKIM은 별도로 무게를 둘 가치가 있습니다. 이유는 단 하나, DKIM만이 무결성까지 책임지기 때문입니다.

SPF는 "허가된 서버에서 왔는가"라는 출처만 봅니다. 내용은 보지 않습니다. 반면 DKIM은 메일 본문과 주요 헤더에 전자 서명을 붙여서, 그 내용이 발송 시점 그대로인지를 받는 쪽이 검증할 수 있게 합니다. 이게 결정적인 이유는 곧 다룰 거래 가로채기 때문입니다. 공격자가 중간에서 메일을 낚아채 계좌번호만 슬쩍 바꿔도, DKIM 서명이 깨지면서 변조가 검증 단계에서 들통납니다.

게다가 발신자 인증은 공격 방어와 별개로 현실적인 도달률 문제이기도 합니다. 2026년 현재 Gmail·Yahoo 같은 대형 수신 서비스는 발송 도메인에 SPF·DKIM·DMARC를 사실상 의무화하는 방향으로 정책을 강화해 왔습니다. 인증이 비어 있으면 당신이 보낸 청구서·예약 확인·뉴스레터가 소리 없이 스팸함으로 밀립니다. Gmail로 가는 메일이 잘 들어가는지, 어디서 막히는지는 Google Postmaster Tools에 도메인을 등록하면 인증 통과율과 도메인 평판으로 직접 확인됩니다. 마케팅 메일을 보내는 소규모 사업자라면 "왜 우리 메일이 안 들어가지?"의 절반은 이 한 가지로 풀립니다.

발신자 인증이 못 막는 것

다만 한계를 분명히 알아야 합니다. SPF·DKIM·DMARC는 당신의 도메인이 사칭당하는 것을 막습니다. 그게 전부입니다. 공격자가 다음과 같이 우회하면 이 세 장치는 무력합니다.

• 유사 도메인 사용: example.com 대신 examp1e.com(소문자 L을 숫자 1로)이나 example-billing.com처럼 헷갈리는 별도 도메인. 그 도메인은 공격자 소유라 인증을 멀쩡히 통과합니다.
• 정당한 계정 탈취: 당신의 실제 계정을 장악하면 사칭이 아니라 진짜 발송이므로 인증을 통과합니다.

그래서 발신자 인증은 필수이되 출발선입니다. 아래 두 방어와 한 세트로 작동해야 합니다.

거래 가로채기(BEC): 한 줄에 사라지는 거래 대금

이제 이 주제에서 가장 비싸고 가장 흔한 위협으로 들어갑니다. 이메일 가로채기를 통한 거래 탈취입니다. 업계에서는 이를 비즈니스 이메일 침해(BEC, Business Email Compromise) — 거래 관계자를 사칭해 송금을 가로채는 공격 — 라고 부릅니다.

여기서 한 가지 통념을 깨야 합니다. 가장 비싼 공격은 화면을 부수는 화려한 해킹이 아닙니다. Verizon의 연례 침해 분석 보고서(DBIR)는 해마다 이 BEC/사칭 부류를 금전 피해 규모에서 단골 상위 항목으로 꼽습니다. 코드가 아니라 사람을 속이는 공격이 가장 큰 돈을 가져갑니다.

공격은 이렇게 전개된다

BEC는 즉흥적인 한 방이 아니라, 인내심 있는 4단계 작전입니다.

1. 침투 — 이메일에 접근한다. 거래 당사자 중 한쪽의 계정을 탈취하거나(약한 비밀번호, 피싱, 외부 유출 자격증명 재사용 등), 메일 통신을 엿볼 수 있는 중간 위치를 확보합니다.
2. 잠복 — 조용히 지켜본다. 당장 아무것도 하지 않습니다. 거래 대화가 오가는 것을 관찰하며 거래 금액, 상대, 일정, 그리고 무엇보다 돈이 움직이는 시점을 파악합니다.
3. 개입 — 결정적 순간에 끼어든다. 송금이 임박한 시점에 거래 상대인 척 "결제 계좌가 변경되었습니다. 새 계좌로 보내주십시오"라는 메일을 보내거나, 이미 오간 정당한 메일에서 계좌 정보만 자기 것으로 바꿔치기합니다.
4. 수금 — 돈이 공격자에게 간다. 피해자는 진행 중인 거래의 맥락 안에 있어 의심하기 어렵습니다. 변경된 계좌로 대금을 보내고, 그 돈은 곧장 빠져나갑니다.

왜 이토록 잘 통하는가

세 가지가 맞물립니다.

• 맥락이 신뢰를 만든다. 소셜 엔지니어링은 맥락을 악용합니다. 이 공격은 "실제로 진행 중인 거래"라는 완벽한 맥락 안에서 벌어집니다. 생뚱맞은 요청이 아니라, 기다리고 있던 바로 그 거래의 일부처럼 보입니다.
• 표적이 고액이다. 일상의 소액이 아니라 큰 금액이 오가는 거래를 노립니다. 한 번 성공하면 수익이 큽니다.
• 발견이 늦다. 피해자는 정상적으로 송금했다고 믿습니다. 무언가 잘못됐다는 걸 한참 뒤, 거래 상대가 "돈을 못 받았다"고 연락해 올 때에야 압니다. 그때는 이미 회수 불가인 경우가 많습니다.

여기에 생성형 AI가 가세하면서 사칭 메일의 문장은 점점 자연스러워지고, 음성·영상 사칭까지 동원되어 정교함이 한층 올라가고 있습니다.

방어: 직관이 아니라 절차로 막는다

BEC 방어의 핵심 원리는 한 문장입니다. 신호가 아니라 절차로, 직관이 아니라 검증으로 막는다. 메일이 "진짜처럼 보인다"는 느낌은 방어 수단이 아닙니다. 공격의 목표가 바로 그 느낌을 만드는 것이니까요.

1) 대역 외(out-of-band) 확인 — 가장 중요한 단 하나. 계좌·송금 정보가 변경됐다는 연락을 받으면, 아무리 정당해 보여도 이메일로 답하지 말고 다른 경로로 확인하세요. 이미 알고 있던 전화번호로 직접 거래 상대에게 전화해 "정말 계좌가 바뀌었느냐"를 묻는 것입니다. 메일이라는 같은 경로로 되묻는 것은, 그 경로를 장악한 공격자에게 다시 물어보는 꼴입니다. 반드시 이메일과 독립된 채널이어야 합니다.

주의: 변경 통지 메일에 적힌 전화번호로 걸지 마세요. 그 번호도 공격자가 바꿔 넣었을 수 있습니다. 반드시 계약서·기존 명함·과거 통화 기록 등 메일 바깥에서 확보한 번호를 쓰세요.

2) 계좌 변경 = 위험 신호로 규정. "결제 계좌가 변경되었다"는 연락 자체를, 조직 차원에서 기본적으로 의심해야 할 신호로 못 박으세요. 긴급함을 강조하는 요청일수록 더 의심하는 것이 원칙입니다("급하게", "오늘 안에", "비밀로" 같은 표현은 모두 압박 장치입니다). 정당한 계좌 변경도 물론 존재합니다. 그렇기에 더더욱 대역 외 확인이 필요합니다.

3) 거래 검증 절차를 문서로 정해 둔다. 사람의 판단에 맡기지 말고 규칙으로 만드세요. 예를 들어 "일정 금액 이상 송금 전에는 반드시 등록된 전화번호로 대역 외 확인을 거친다", "계좌 변경은 2인 승인을 받는다" 같은 절차가 있으면 공격자가 이를 우회하기 어렵습니다.

4) 기술 방어를 깔아 둔다. 발신자 인증(특히 DKIM)은 도메인 사칭과 메일 변조를 어렵게 만들고, 뒤에서 다룰 계정 보호(2채널 인증)는 애초에 공격자가 이메일에 발을 들이지 못하게 합니다. 절차적 방어와 기술적 방어가 함께 가야 합니다.

아래는 송금 실무자가 책상에 붙여둘 만한 체크리스트입니다.

[ ] 계좌/송금 정보 변경 통지를 받았다  →  즉시 "위험 신호"로 분류
[ ] 메일에 답장하지 않았다
[ ] 메일 밖에서 확보한 번호로 직접 전화해 확인했다
[ ] 통지 메일에 적힌 번호로는 걸지 않았다
[ ] 고액 송금이면 2인 승인 절차를 거쳤다
[ ] 조금이라도 이상하면 송금을 보류하고 보안 담당에게 알렸다

조용한 누적: 증상 없이 새어 나가는 정보

거래 탈취가 한 번에 크게 터지는 폭발이라면, 이메일 침해의 또 다른 얼굴은 정반대입니다. 증상 없이 조용히 쌓이는 피해입니다.

눈에 띄지 않게 빠져나가는 것들

공격자가 당신의 메일함에 들어오면, 송금의 결정적 순간을 기다리는 동안(그리고 그와 무관하게도) 메일함에 쌓인 방대한 정보를 조용히 긁어 갑니다. 메일함에는 생각보다 많은 것이 들어 있습니다.

• 개인정보와 신원 정보
• 거래 내역과 금융 정보
• 인간관계 지도와 일정
• 다른 서비스의 가입 정보와 영수증
• 그리고 종종, 다른 계정의 비밀번호 재설정 링크

이 정보 수집의 진짜 무서운 점은 증상이 없다는 것입니다. 거래 탈취는 돈이 사라지므로 언젠가 발각됩니다. 그러나 정보 수집은 아무것도 눈에 띄게 없어지지 않습니다. 공격자는 그저 읽고, 복사하고, 축적합니다. 당신은 "뭔가 이상하다"는 신호조차 받지 못한 채 정보가 계속 새어 나갑니다.

그리고 수집된 정보는 다음 공격의 재료가 됩니다. 메일에서 얻은 디테일로 한층 정교한 소셜 엔지니어링을 설계하고(상대 이름, 진행 중인 프로젝트, 말투까지 흉내 낼 수 있습니다), 비밀번호 재설정을 통해 다른 계정으로 갈아타고, 당신의 인간관계를 발판으로 삼습니다. 한 번의 이메일 접근이 보이지 않게 번지는 피해의 진원지가 됩니다.

이메일은 다른 모든 계정의 마스터 열쇠다

여기서 반드시 짚어야 할 사실이 있습니다. 이메일 계정은 단순한 하나의 계정이 아니라, 다른 수많은 계정의 마스터 열쇠입니다. 대부분의 서비스가 "비밀번호를 잊으셨나요?"를 누르면 이메일로 재설정 링크를 보내기 때문입니다.

즉 당신의 메일함을 장악한 공격자는, 거기에 연결된 다른 계정들의 비밀번호를 차례로 재설정해 도미노처럼 무너뜨릴 수 있습니다. 쇼핑몰, SNS, 클라우드 저장소, 심지어 금융 서비스까지. 그래서 이메일 보호는 다른 어떤 계정 보호보다 우선순위가 높습니다. 이메일이 뚫리면 그 하나로 끝나지 않습니다.

방어: 들어오지 못하게 막고, 흔적을 살핀다

증상이 없는 만큼, 방어는 두 방향에서 동시에 가야 합니다.

1) 접근 자체를 차단한다. 사후 탐지가 어려우니 애초에 못 들어오게 하는 것이 최선입니다. 강력한 계정 보호 — 특히 2채널 인증 — 이 핵심입니다(바로 다음 섹션).

2) 비정상 신호를 정기적으로 살핀다. "증상이 없다"고 했지만 미묘한 단서는 남습니다.

마지막 항목, 자동 전달 규칙은 특히 자주 놓칩니다. 공격자는 들키기 전에 "특정 키워드가 든 메일을 외부 주소로 자동 전달"하는 규칙을 심어두고 조용히 빠져나가는 경우가 많습니다. 비밀번호를 바꿔도 이 규칙은 남아 계속 정보를 흘립니다.

의심스러운 신호를 발견하면 순서대로: 비밀번호 변경 → 모든 세션 강제 로그아웃 → 2채널 인증 점검 → 메일 전달/필터 규칙 전수 검사 → 연결된 앱 권한 회수.

이메일 계정 보호: 관문을 지킨다

앞에서 보았듯 이메일 계정은 디지털 생활 전체로 가는 관문입니다. 그래서 이메일 계정의 보호는 특별 취급해야 합니다.

2채널 인증은 선택이 아니라 필수다

이메일 계정에 대한 가장 중요한 보호는 다단계 인증(2채널 인증, MFA)입니다. 핵심 논리는 단순합니다. 비밀번호만으로는 부족합니다. 비밀번호는 유출되고(앞서 본 조용한 정보 수집을 포함해), 피싱으로 넘어갑니다. 2채널 인증이 있으면 비밀번호가 새어 나가도, 두 번째 인증 요소가 없는 공격자는 문 앞에서 막힙니다.

이메일처럼 다른 계정의 열쇠가 되고 그토록 많은 정보를 품은 계정에 2채널 인증을 끄고 사는 것은, 금고 열쇠를 현관 매트 밑에 두는 것과 같습니다. 인증 방식에도 강도 차이가 있습니다.

가능하면 피싱에 강한 하드웨어 보안키를 쓰는 것이 가장 안전합니다. 최소한 SMS는 벗어나 인증 앱 이상을 쓰세요.

2채널 인증 말고도 챙길 것들

관문을 지키는 일은 자물쇠 하나로 끝나지 않습니다.

비밀번호 재설정 경로를 함께 잠그세요. 이메일이 다른 계정의 열쇠이듯, 이메일 자체의 복구 경로(복구용 이메일, 복구 전화번호)도 공격자의 표적입니다. 복구 전화번호가 더 이상 쓰지 않는 번호는 아닌지, 복구 이메일 계정 역시 2채널이 걸려 있는지 점검하세요. 본 계정을 아무리 단단히 잠가도 복구 경로가 허술하면 그쪽으로 우회당합니다.

연결된 앱 권한을 주기적으로 회수하세요. 이메일 계정에 OAuth로 연결한 외부 앱·서비스 목록을 정기적으로 검토하고, 더는 쓰지 않거나 신뢰하지 않는 것의 접근을 끊으세요. 몇 년 전 한 번 "이 앱이 내 메일에 접근하도록 허용" 버튼을 눌렀던 것이 통로가 될 수 있습니다.

업무용과 개인용을 분리하세요. 가능하면 업무 메일과 개인 메일을 분리해, 한쪽의 침해가 다른 쪽으로 번지지 않게 하세요. 격리는 피해를 가두는 가장 기본적인 원칙입니다.

30초 요약

• 이메일은 가장 오래된 통로이자 가장 비싼 사고의 원천이다. 보안을 우선으로 설계되지 않아 위조와 가로채기에 약하다.
• 발신자 인증(SPF·DKIM·DMARC)을 켜라. 특히 DKIM은 무결성까지 보장한다. DMARC는 p=none에서 시작해 단계적으로 reject까지 올린다. MXToolbox로 게시 여부를 검증하라.
• BEC(거래 가로채기)는 한 줄에 대금을 앗아간다. 공격자가 메일을 엿보다 송금 직전 "계좌가 변경됐다"고 끼어든다. 진행 중인 거래라는 맥락이 신뢰를 만들어 막기 어렵다.
• BEC의 결정적 방어는 대역 외 확인이다. 계좌·송금 변경 통지는 아무리 정당해 보여도 메일 밖 경로(기존 전화번호)로 확인하라. 통지 메일에 적힌 번호는 쓰지 마라.
• 또 다른 피해는 증상 없이 누적된다. 조용한 정보 수집은 다른 공격의 재료가 된다. 로그인 기록과 자동 전달 규칙을 살펴라.
• 이메일 계정엔 2채널 인증이 필수. 이메일은 다른 모든 계정의 마스터 열쇠다. 복구 경로를 잠그고, 연결 앱 권한을 회수하고, 업무·개인을 분리하라.

자주 묻는 질문 (FAQ)

Q. SPF만 설정해도 충분한가요? DKIM·DMARC까지 꼭 필요할까요? 부족합니다. SPF는 "허가된 서버에서 보냈는가"라는 출처만 보고 내용은 검증하지 않습니다. 공격자가 메일을 가로채 계좌번호만 바꾸는 변조는 SPF로 못 잡습니다. 무결성까지 보장하는 DKIM, 그리고 둘의 결과를 종합해 처리 정책을 정하고 사칭 시도를 리포트로 보여주는 DMARC가 함께 있어야 비로소 실효성이 생깁니다. 셋은 한 세트입니다.

Q. DMARC를 바로 p=reject로 켜도 되나요? 권하지 않습니다. 정당한 발송 경로(예: 외부 뉴스레터 서비스, ERP 자동 메일) 중 인증에서 빠진 것이 있으면 그 메일까지 한꺼번에 거부되어 사고가 납니다. p=none(관찰만)으로 시작해 rua 리포트로 통과율과 누락된 발송 경로를 며칠~몇 주간 확인한 뒤, p=quarantine을 거쳐 p=reject로 단계적으로 올리는 것이 정석입니다.

Q. "결제 계좌가 변경되었다"는 메일을 받았는데, 거래 상대 도메인도 정확하고 말투도 평소와 같습니다. 어떻게 확인하나요? 도메인이 정확하고 말투가 자연스러운 것은 안심의 근거가 아니라 오히려 공격이 정교하다는 신호일 수 있습니다(계정이 탈취됐다면 진짜 도메인에서 진짜 말투로 옵니다). 유일하게 믿을 방법은 대역 외 확인입니다. 메일에 답장하거나 메일에 적힌 번호로 걸지 말고, 계약서·기존 명함 등 메일 바깥에서 확보한 번호로 직접 전화해 계좌 변경 사실을 확인하세요.

Q. 비밀번호를 강력하게 만들면 2채널 인증은 생략해도 되지 않나요? 아닙니다. 아무리 강력한 비밀번호도 피싱으로 통째로 넘어가거나, 다른 사이트 유출로 새어 나갈 수 있습니다. 2채널 인증은 비밀번호가 이미 털린 상황을 가정한 두 번째 방어선입니다. 특히 이메일은 다른 계정들의 비밀번호 재설정 관문이라, 여기가 뚫리면 연쇄적으로 무너집니다. 가능하면 SMS보다 인증 앱이나 하드웨어 보안키를 쓰세요.

Q. 메일함이 이미 침해된 것 같습니다. 무엇부터 해야 하나요? 순서가 중요합니다. (1) 비밀번호를 즉시 변경하고 (2) 모든 세션을 강제 로그아웃하세요. 그다음이 자주 놓치는 단계인데, (3) 공격자가 몰래 심어둔 자동 전달·필터 규칙을 전수 검사해 제거하세요. 이 규칙은 비밀번호를 바꿔도 남아 계속 정보를 흘립니다. 이어서 (4) 2채널 인증을 켜거나 점검하고 (5) 복구 이메일·복구 전화번호를 확인하고 (6) 연결된 외부 앱 권한을 회수하세요.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.