📧 메일 인증 확인
도메인을 입력하여 MX, SPF, DMARC, MTA-STS, TLS-RPT를 조회하고 유효성을 진단.
📚 이메일 인증 기초
• SPF: 이 도메인의 메일을 보낼 수 있는 IP/호스트를 TXT로 선언
• DKIM: 메시지에 서명을 추가 — 선택자가 필요하여 자동 감지 불가
• DMARC: SPF/DKIM 위의 정책
• MTA-STS: 수신측이 TLS 필수를 선언
• TLS-RPT: TLS 배송 실패 보고서 수신처
📖 이 진단으로 알 수 있는 것
이 진단은 DNS 만 보고 MX · SPF · DMARC · MTA-STS / TLS-RPT 의 설정 상황을 확인합니다. DKIM 은 포함되지 않습니다 — DKIM 공개키는 셀렉터 이름을 모르면 조회할 수 없고 셀렉터는 DNS 에서 열거할 수 없기 때문입니다. 또 여기가 전부 초록이어도 메일이 받은편지함에 도착한다고는 할 수 없습니다. 도달률을 정하는 것은 주로 발신 IP 와 도메인의 평판이며 인증 설정은 그 전제 조건에 불과합니다.
| 판정 항목 | 무엇을 보는가 | 걸렸을 때의 대처 |
|---|---|---|
| SPF 가 pass 여도 발신자는 위장 가능 | SPF 가 검증하는 것은 봉투의 발신자(Return-Path)이며 수신자에게 표시되는 From: 헤더는 전혀 보지 않습니다. 공격자는 자신이 관리하는 도메인에서 SPF 를 올바르게 설정한 뒤 From: 만 당신의 회사명으로 할 수 있습니다. SPF 단독으로는 사칭을 막을 수 없습니다. |
이 구멍을 막는 것이 DMARC 의 얼라인먼트로, From: 의 도메인과 SPF / DKIM 이 통과한 도메인이 일치할 것을 요구합니다. SaaS 를 통해 보내는 경우 기본 Return-Path 는 업체 도메인이므로 얼라인먼트가 맞지 않습니다. 각 서비스의 커스텀 Return-Path, 발신 도메인 인증 설정에서 bounce.example.com 같은 자기 도메인의 서브도메인으로 변경하세요. |
| DMARC 가 p=none 인 채 | p=none 은 인증에 실패해도 아무것도 하지 말라는 선언입니다. 설정해 두었다는 사실만 있고 사칭은 한 통도 막히지 않습니다. 레코드가 존재하므로 진단 도구에서는 초록이 되어 대책 완료로 오해되기 쉬운 상태입니다. |
rua=mailto:… 로 집계 리포트를 받아 2〜4주에 걸쳐 정규 발신원을 전부 파악합니다. 마케팅 도구, 청구 시스템, 사내의 오래된 스크립트 등 파악하지 못한 발신원이 반드시 나옵니다. 모두 인증을 통과시킨 뒤 p=quarantine; pct=10 부터 시작해 단계적으로 100 으로, 마지막에 p=reject 로 합니다. |
| 전달되면 SPF 는 반드시 깨진다 | 메일링 리스트나 자동 전달을 거치면 발신 IP 가 전달 서버의 것으로 바뀌므로 SPF 는 반드시 fail 합니다. 이는 설정 실수가 아니라 구조상의 성질입니다. DKIM 은 본문과 헤더의 서명이므로 전달 측이 고쳐 쓰지 않으면 그대로 남습니다. | DKIM 을 반드시 설정하세요. DMARC 는 SPF 와 DKIM 중 어느 한쪽만 통과하면 되므로 DKIM 이 있으면 전달되어도 인증이 유지됩니다. SPF 만으로 p=reject 로 올리면 전달된 메일이 일제히 튕깁니다. 제목에 접두사를 붙이는 유형의 메일링 리스트는 DKIM 도 깨뜨리므로 그 경우는 ARC 를 지원하는 수신 측에 기댈 수밖에 없습니다. |
메일을 받지 않는 발신 전용 도메인도 설정은 필요합니다. MX 를 비우지 말고 Null MX(0 ., RFC 7505)를 두고 v=spf1 -all 과 p=reject 를 선언해 두면 그 도메인을 사칭하는 스팸을 명확히 거부할 수 있습니다. 또 하나 실무에서 걸리기 쉬운 것이 발송 서비스 측 인증은 도메인명 완전 일치로 다뤄진다는 점으로, example.com 을 인증해도 mail.example.com 에서의 발송은 별개로 취급되어 튕길 수 있습니다. 본 사이트도 실제로 이것 때문에 발송이 멈췄고 상위 도메인 발신자로 통일해 해결했습니다.