왜 당신의 피싱 시뮬레이션이 스팸에 잡히는가 (그리고 실제로 작동하는 SPF / DKIM / DMARC 해결책)
Source: Dev.to
“우리는 어제 캠페인을 보냈어요. 대시보드에는 발송됐다고 나와요.
하지만 아무도 클릭하지 않았고, 슬랙에서 세 명이 왜 테스트 이메일을 못 받았는지 물어보고 있어요.”
그러다 누군가 스팸 폴더를 열어보니 시뮬레이션 피싱 메일이 나이지리아 왕자와 나란히 놓여 있네요. 캠페인이 고장 난 게 아니라 전달률이 문제예요.
나는 HailBytes SAT 고객들을 위해 이 문제를 디버깅하는 데 충분히 시간을 투자했기 때문에 기억을 토대로 사후 분석을 쓸 수 있다. 여기 있다.
핵심 문제
피싱 시뮬레이션은 본질적으로 의심스러운 이메일처럼 보이도록 설계된 것입니다. 최신 메일 제공업체(Microsoft 365, Google Workspace, Mimecast, Proofpoint)는 의심스러운 이메일을 학습하여 강력한 신호가 없으면 적극적으로 격리합니다.
규모에 따라 중요한 네 가지 신호가 정확히 있습니다:
- SPF – 발신 IP가 해당 도메인에서 메일을 보낼 권한이 있나요?
- DKIM – 메시지 본문이 도메인에 의해 암호화 서명되었나요?
- DMARC – SPF/DKIM이 일치하지 않을 경우 수신자는 어떻게 해야 하나요?
- Sender reputation – 이 IP/도메인 조합이 이전에 정상 메일을 보낸 적이 있나요?
네 가지 모두를 올바르게 설정하면 캠페인이 받은편지함에 도착합니다. 하나라도 놓치면 확률과 싸워야 합니다.
1단계: 실제 기업 도메인에서 발송하지 않기
가장 흔한 실수는 피싱 시뮬레이션 플랫폼을 noreply@theirrealcompany.com 같은 실제 기업 도메인으로 지정하는 것입니다. 이렇게 하면 수신자가 테스트를 의심스러운 것으로 표시하면서 기업 도메인의 평판이 즉시 손상됩니다.
해결 방법
- 시뮬레이션용 별도 전용 도메인을 사용합니다. 예:
security-training.example-corp.com혹은 보유하고 있는 새로운 유사 도메인. - 실제 도메인에는
p=reject옵션으로 DMARC를 적용합니다. - 시뮬레이션 도메인에는
p=none(또는 충분히 워밍업된 후p=quarantine)을 적용해 수신자가 이를 전달 가능하지만 의심스러운 메일로 분류하도록 합니다. 이는 교육에 정확히 원하는 동작입니다.
2단계: 실제로 발신자를 인증하는 SPF
자신의 EC2 인스턴스에서 HailBytes SAT(또는 다른 플랫폼)를 실행하고 MX로 직접 전송하는 경우, 시뮬레이션 도메인의 SPF 레코드가 해당 IP를 허용해야 합니다:
v=spf1 ip4:203.0.113.42 -allSES, SendGrid, 또는 Postmark를 통해 릴레이하는 경우:
v=spf1 include:amazonses.com -all-all(hard‑fail) 한정자는 가장 강력한 신호를 제공합니다. ~all(soft‑fail)은 워밍업 단계에서 허용될 수 있습니다.
단계 3: DKIM, 올바르게
DKIM은 조용히 깨지는 부분입니다.
-
2048‑비트 키를 생성합니다:
openssl genrsa -out dkim.key 2048 -
공개 키를
selector._domainkey.sim-domain.example.com에 TXT 레코드로 게시합니다.
SAT에서는 기본 선택자를s1로 사용합니다 – 키를 교체할 경우 변경하세요. -
서명은 최소한
From,Subject,Date,To를 포함해야 합니다.
SMTP 릴레이가 헤더를 수정하면 서명이 깨지고 DKIM이 대시보드에 명확한 오류 없이 실패합니다.
DNS 엔트리를 확인합니다:
dig +short TXT s1._domainkey.sim-domain.example.com테스트 메시지를 스스로 보내고 원본 소스의 Authentication-Results 헤더를 확인하세요. dkim=pass가 표시되어야 합니다.
4단계: DMARC 정렬
DMARC는 SPF 또는 DKIM이 통과 하고 인증된 도메인이 From: 도메인과 일치해야 합니다. 이는 릴레이 서비스를 사용하는 거의 모든 사람을 곤란하게 합니다.
예시: From: 은 security@sim.example.com 이지만 DKIM은 amazonses.com 로 서명됨 → DKIM 자체는 통과하지만 DMARC 정렬이 실패합니다.
해결 방법
- 자체 도메인으로 서명 (최선).
- 또는 릴레이가 도메인과 정렬되는 사용자 정의
MAIL FROM을 사용하도록 설정 (허용 가능).
_dmarc.sim-domain.example.com에 DMARC를 게시:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100워밍업 기간에는 p=none이 의도된 설정입니다. 보고서에서 SPF와 DKIM이 지속적으로 통과하는 것이 확인되면 p=quarantine으로 전환하십시오.
Step 5: IP 워밍
새 IP가 첫날에 5 000개의 피싱 시뮬레이션을 보내면 DMARC가 얼마나 깨끗하든 바로 스팸으로 처리됩니다. 평판은 전송량과 패턴에 기반합니다.
새로운 시뮬레이션 IP를 위한 현실적인 워밍 스케줄
| Day(s) | Volume | Notes |
|---|---|---|
| 1‑3 | 50 | 내부 전용 테스트 계정 |
| 4‑7 | 200 | 자원봉사 파일럿 그룹, “스팸 아님”을 적극 표시 |
| 8‑14 | 500 | 첫 번째 소규모 부서 |
| 15+ | 2 000+ | 전체 조직, 포스트마스터 도구 모니터링 |
Microsoft와 Google 모두 포스트마스터 대시보드를 제공합니다. 활용하세요. 평판이 “low” 또는 “bad”으로 떨어지는 것을 보면, 수신자가 신뢰하는 속도보다 빠르게 보내고 있다는 뜻입니다.
Step 6: 수신자별 헤더 규칙
위의 모든 조치를 취했더라도 개별 사서함에는 특정 패턴을 격리하는 전송 규칙이 있을 수 있습니다. 보안 팀이 할 수 있는 가장 유용한 일은 시뮬레이션 도메인에 대해서만 격리를 우회하도록 메일 관리자들이 적용할 수 있는 내부 allow‑list 문서를 배포하는 것입니다. 대부분의 수신자는 도메인별 또는 IP별 우회를 지원합니다.
Microsoft 365 예시
- 연결 필터의 IP Allow List에 시뮬레이션 IP를 추가합니다.
*@sim-domain.example.com에서 온 메시지에 대해 SCL = -1을 설정하는 전송 규칙을 생성합니다.
이렇게 하면 스팸 필터링은 우회되지만 사용자 인식은 우회되지 않습니다 — 이메일은 여전히 의심스러운 형태로 도착하므로 이것이 바로 핵심 포인트입니다.
결과
고객이 HailBytes SAT와 함께 이 체크리스트를 진행하면, Microsoft 365에서의 수신함 배정 비율이 일반적으로 30‑40 %(캠페인 초기 상태)에서 90 %+(2주간 워밍 후 캠페인 실행)로 급상승합니다. 가장 큰 상승 요인은 IP‑워밍 마법이 아니라 DKIM 정렬을 올바르게 맞추는 것입니다.
숙제를 건너뛰고 싶다면, 플랫폼이 배포 과정에서 SPF/DKIM/DMARC 구조와 IP 워밍을 처리합니다 — 전체 가이드는 . 에서 확인하세요. 하지만 솔직히 말해, 위 체크리스트는 제품에 구애받지 않습니다. 어떤 시뮬레이션 플랫폼을 사용하든, 이 여섯 단계를 진행하세요.