n8n으로 이메일 헤더 분석하기 — SPF·DKIM·DMARC 인증과 IP 평판으로 피싱 메일 걸러내기

n8n.io 공식 템플릿 마켓플레이스에 공개된 워크플로우를 가져오면, Gmail에 새 메일이 도착할 때마다 SPF·DKIM·DMARC 인증 결과와 발신 IP의 지리정보·평판 점수를 자동으로 뽑아 하나의 분석 결과로 정리할 수 있습니다. 의심 메일을 눈으로 뜯어보던 일이 구조화된 데이터로 바뀝니다.

이 템플릿 하나로 보여줄 수 있는 것

보안 관련 직무 면접에서 "피싱 메일을 어떻게 걸러내나요?"라는 질문을 받으면, 대부분 "의심스러우면 클릭하지 않는다" 수준의 답이 나옵니다. 이 템플릿을 직접 만들어봤다면 다르게 답할 수 있습니다. "메일 헤더의 SPF·DKIM·DMARC 인증 결과와 발신 IP의 평판 점수를 자동으로 뽑아, 스푸핑 가능성이 있는 메일을 구조적으로 판별하는 워크플로우를 구성해봤습니다."

문장 하나지만 안에 들어간 역량은 세 가지입니다.

• 이메일 인증 프로토콜 이해 — SPF·DKIM·DMARC가 각각 무엇을 검증하는지, 헤더 어디에 그 결과가 남는지 실습으로 확인한 경험
• 외부 위협 정보 API 조합 — 발신 IP 하나를 지리정보 API와 평판 스코어링 API 두 곳에 동시에 물어봐서 하나의 판단 근거로 합치는 경험
• 보안 자동화 파이프라인 설계 — 사람이 메일함을 열어 눈으로 확인하던 작업을 트리거 기반 자동 분석으로 옮겨본 경험

이 세 가지는 이메일 보안뿐 아니라 로그인 시도 이상 탐지, 결제 사기 탐지, 접속 IP 기반 리스크 스코어링처럼 "IP 하나를 근거로 위험도를 매기는" 유형의 SecOps 자동화 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Analyze email headers for IP reputation and spoofing detection - Gmail이라는 이름으로 공개된 템플릿이고, 제작자는 Angel Menendez입니다. 카테고리는 SecOps로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 IT 담당자와 보안 분석가, 그리고 이메일 보안을 강화하려는 조직을 대상으로 합니다. 이메일 스푸핑과 피싱은 여전히 주요한 보안 위협인데, 헤더를 분석하면 메일이 어디서 왔는지, 인증을 통과했는지, 발신 IP의 신뢰도가 어느 정도인지를 알 수 있어서 스푸핑 탐지와 신뢰도 평가에 도움이 된다고 설명합니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조 자체에 집중합니다.

구조 — Trigger / Task / Target

공식 문서는 이 워크플로우가 하는 일을 5개 기능으로 설명합니다. 이걸 데이터팝콘 방식인 Trigger/Task/Target 세 칸과, 노드 미리보기에 실제로 등장하는 노드 타입(HTTP Request, If, Merge)을 근거로 재구성하면 이렇습니다.

• Trigger — Gmail Trigger가 받은편지함에 새 메일이 도착하는 것을 감지합니다.
• Task — 메일 헤더를 추출한 뒤 두 갈래로 나뉩니다. 하나는 SPF·DKIM·DMARC 인증 결과를 업계 표준 보안 규격에 맞춰 검증하는 흐름이고, 다른 하나는 발신 IP를 뽑아 지리정보(IP-API)와 스팸·평판 점수(IP Quality Score)를 외부 API로 조회하는 흐름입니다. 두 흐름의 결과는 다시 하나로 합쳐집니다.
• Target — 공식 설명은 이 결과를 "하나의 JSON 응답으로 통합해 타 시스템 연동에 활용한다"고 정리합니다. 즉 기본값은 슬랙 알림이나 이메일 발송이 아니라, 분석 결과를 구조화된 데이터 하나로 정리하는 것입니다.

노드 미리보기 칩에는 HTTP Request·If·Merge 외에 "+9 more"라는 표기가 붙어 있어, 캔버스 전체는 최소 12개 노드로 구성돼 있을 것으로 보입니다. 다만 정확한 연결 순서와 나머지 노드의 역할은 공식 텍스트와 카드 미리보기 이상으로는 확인되지 않아서, 위 다이어그램은 5개 기능 설명과 확인된 노드 타입을 조합해 재구성한 것이라는 점을 밝혀둡니다. 특히 If 노드가 정확히 어떤 조건으로 분기하는지는 공식 문서에 명시돼 있지 않고, 인증·평판 결과를 근거로 위험도를 나누는 역할일 것으로 추정한 부분입니다.

인증 분석 단계도 짚어둘 점이 있습니다. Gmail을 포함한 대부분의 메일 서버는 수신 메일에 대해 SPF·DKIM·DMARC 검사를 이미 수행하고, 그 결과를 헤더 어딘가에 남겨둡니다. 이 템플릿의 "인증 분석" 단계는 새로 인증을 수행한다기보다, 이렇게 이미 채워진 헤더값을 읽어 검증하는 방식일 가능성이 큽니다. 공식 문서가 이 부분까지 명시하지는 않아 확정할 수는 없지만, "인증을 직접 수행"과 "이미 나온 결과를 읽어 판단"은 설계상 꽤 다른 이야기라 구분해서 이해해두는 게 좋습니다.

만들기

공식 Setup 단계는 총 3개입니다. 짧아 보이지만 각 단계 안에 확인할 게 여러 개 들어 있어서 순서대로 풀어씁니다.

1. Gmail 인증

Gmail Trigger 노드에 Gmail 계정 크리덴셜을 연결합니다. 이 트리거가 받은편지함을 감시하는 시작점이므로, 여기서 인증이 안 되면 이후 단계는 아예 실행되지 않습니다.

2. API 키 준비 (선택)

발신 IP를 조회하는 두 외부 서비스는 성격이 다릅니다. 지리정보를 조회하는 IP-API는 공식 설명에 "엔드포인트에 접근 가능한지 확인하라"고만 돼 있고 별도 키 발급 안내가 없습니다. 반면 평판 점수를 매기는 IP Quality Score(ipqualityscore.com)는 API 키를 발급받으라고 명시돼 있습니다. 즉 지리정보 조회는 키 없이 되는 서비스, 평판 점수 조회는 키가 필요한 서비스로 나뉘어 있는 셈입니다.

공식 문서는 이 API 키 단계를 "선택"이라고 표시하는데, 이유는 IP Quality Score가 월 단위로 제한된 무료 조회를 제공하기 때문이라고 설명합니다. 2026년 8월 기준 IP Quality Score 공식 요금제 페이지에는 무료 플랜이 월 1,000회 조회로 명시돼 있습니다(공식 요금제 페이지). 개인 실습이나 포트폴리오용으로는 충분한 양이지만, 실제 조직 메일함처럼 트래픽이 많은 환경에 그대로 붙이면 금방 소진될 수 있는 규모라는 점은 감안해야 합니다.

3. 워크플로우 활성화

캔버스 상단의 토글을 Active로 바꿔야 실시간으로 들어오는 메일을 처리합니다. 비활성 상태에서는 수동 실행으로 과거 메일 한 통을 골라 테스트해보는 정도만 가능합니다.

주의할 점 · 제약

공식 문서와 카드 정보를 근거로 정리하면 세 가지입니다.

• 평판 조회에 월별 무료 한도가 있다 — 앞서 확인한 대로 IP Quality Score 무료 플랜은 월 1,000회 조회로 제한돼 있습니다(2026년 8월 기준). 메일함에 스팸이 몰리는 시기에는 이 한도를 빨리 소진할 수 있어서, 운영 단계에서는 유료 플랜 전환이나 조회 빈도 조절을 함께 고려해야 합니다.
• 기본값은 알림이 아니라 분석 결과다 — 이 템플릿은 그 자체로 슬랙이나 이메일로 경고를 보내주지 않습니다. 공식 커스터마이징 아이디어에도 "Gmail - Respond to Webhook 노드를 추가해 슬랙·이메일 등으로 알림을 보내라"는 항목이 별도로 있어서, 실제로 사람에게 알림을 보내려면 이 부분을 직접 추가해야 합니다.
• 노드 미리보기 이상의 세부 구조는 공개 텍스트만으로 확인이 안 된다 — 노드 미리보기 칩이 보여주는 건 HTTP Request·If·Merge 세 가지와 "+9 more"뿐입니다. 전체 노드 구성과 정확한 분기 로직을 보려면 템플릿을 실제로 임포트해서 캔버스를 직접 열어봐야 합니다.

공식 커스터마이징 아이디어 중에는 SIEM 연동(Splunk, ELK Stack으로 결과 전달), Set 노드의 SPF·DKIM·DMARC 검증 로직을 조직 정책에 맞게 수정하기, VirusTotal이나 AbuseIPDB 같은 API를 추가해 IP 분석을 강화하기도 포함돼 있습니다. 템플릿을 그대로 쓰는 데서 그치지 않고 확장할 여지가 많다는 뜻이기도 합니다.

포트폴리오·면접 포인트

포트폴리오에는 실제로 도착한 메일 한 통을 이 워크플로우에 넣고, SPF·DKIM·DMARC 결과와 IP 평판 점수가 정리된 실행 결과 화면을 캡처해두면 됩니다. 인증에 실패했거나 평판 점수가 낮은 메일 한 통을 예시로 함께 보여주면, 정상 메일과 의심 메일이 어떻게 다르게 나오는지가 한눈에 비교됩니다.

면접에서는 "왜 IP 평판만 보지 않고 SPF·DKIM·DMARC까지 같이 보나요?" 같은 질문이 나올 수 있습니다. 답은 이렇습니다. 발신 IP의 평판이 깨끗해도 발신 도메인이 위조됐다면 인증 결과에서 걸리고, 반대로 인증은 통과했어도 발신 IP 자체가 스팸 인프라로 알려져 있다면 평판 점수에서 걸립니다. 한쪽만 보면 놓치는 케이스가 다른 쪽에서 잡히기 때문에 두 신호를 같이 보는 것이라고 설명할 수 있으면, 노드를 나열하는 대신 탐지 로직을 이해하고 있다는 인상을 줍니다.

다음 액션

다음 편에서는 도메인을 다시 AI 에이전트 쪽으로 옮겨, n8n 네이티브 Evaluation 노드로 멀티 에이전트 워크플로우의 도구 호출 정확도를 측정하는 템플릿을 다룹니다. 이번 편이 "외부 신호를 모아 위험도를 판단하는" 구조였다면, 다음 편은 "에이전트 스스로의 출력을 채점하는" 구조라 같은 자동화 안에서도 판단 대상이 완전히 달라지는 걸 보게 됩니다.