SPF·DKIM·DMARC 확인 (메일 인증 점검)
도메인 이름만 DNS 조회에 쓰입니다. 입력한 도메인과, 그 도메인의 DNS 레코드가 가리키는 이름(선택자·include 대상 등)이 Cloudflare DNS(1.1.1.1)에 조회됩니다. 그 밖에는 아무것도 전송되지 않습니다. 익명 방문 통계만 집계합니다.
사용법
- 점검할 도메인을 입력합니다. 받은 메일의 보낸 사람 주소([email protected])를 그대로 붙여넣으면 @ 뒤의 도메인만 씁니다. 한글 도메인과 URL 도 받습니다.
- DKIM 까지 보려면 선택자(selector)를 넣습니다. 선택자는 그 도메인에서 받은 메일의 "원본 보기"에서 DKIM-Signature 헤더의 s= 값입니다. Google Workspace 는 google, Microsoft 365 는 selector1·selector2 처럼 흔한 값은 버튼으로 채울 수 있고, 비워 두면 DKIM 은 건너뜁니다.
- "점검"을 누르면 MX, SPF(include·redirect 를 끝까지 따라감), DMARC(_dmarc.도메인), DKIM(선택자._domainkey.도메인)을 Cloudflare DNS 에 조회합니다. 브라우저가 직접 조회하고 microlab 서버는 거치지 않습니다.
- 맨 위 네 칸에서 항목별 상태(설정됨·확인 필요·문제 있음·없음)를 보고, 아래에서 근거를 확인합니다. SPF 는 DNS 조회 횟수(10회 한도)와 빈 응답 횟수(2회 한도), 항마다의 뜻, 따라간 include 경로를 보여 주고, DMARC 는 태그별 뜻과 실제로 적용되는 정책을, DKIM 은 키 종류와 길이를 보여 줍니다.
- 설정을 고친 뒤에는 DNS 캐시(TTL)가 지난 다음 다시 점검합니다. "링크 복사"로 담당자와 결과를 공유할 수 있습니다 — 도메인은 주소의 # 뒤에 실려 이 사이트 서버로 전송되지 않습니다.
자주 묻는 질문
SPF 의 "DNS 조회 10회 제한"은 무엇이고, 왜 이렇게 세나요?
SPF 를 평가하는 수신 서버는 include·a·mx·ptr·exists 메커니즘과 redirect 수정자를 합쳐 10개까지만 처리하고, 넘으면 permerror(영구 오류)로 판정해야 합니다(RFC 7208 §4.6.4). ip4·ip6·all 은 세지 않습니다. include 한 레코드 안의 include 도 모두 합산되므로, 메일 발송 서비스 몇 개를 include 하면 금방 넘습니다. 수신 서버는 발신 IP 가 맞는 항에서 평가를 멈추기 때문에, 이 도구는 어느 항에도 맞지 않아 끝까지 가는 경우(사칭 메일이 타는 경로)를 기준으로 평가 순서대로 번호를 매깁니다. 같은 도메인을 두 곳에서 include 하면 두 번 셉니다. 조회 결과가 NXDOMAIN 이거나 비어 있는 "빈 응답(void)"은 2회를 넘으면 역시 permerror 입니다 — a 항은 연결 종류에 맞는 주소를 조회하므로(§5.3) 이 도구는 IPv4 로 보내는 경우를 기준으로 셉니다.
~all 과 -all, ?all 은 무엇이 다른가요?
all 은 앞의 어느 항에도 맞지 않은 모든 서버에 대한 결과입니다. -all(fail)은 "허용하지 않음"이라는 분명한 선언이고 처리는 수신 서버 정책에 달려 있어 거부될 수 있습니다(RFC 7208 §8.4). ~all(softfail)은 "아마 허용하지 않음"으로, 수신 서버는 이것만으로 거부하지 말고 더 의심해 보라고 권고받습니다(§8.5) — 스팸함으로 갈 수 있습니다. ?all(neutral)은 아무 주장도 하지 않는 것이라 SPF 가 없는 것과 똑같이 취급됩니다(§8.2). +all 은 인터넷의 모든 서버를 허용하므로 누구나 이 도메인을 사칭해 SPF 를 통과할 수 있습니다. 보내는 서버를 빠짐없이 적었는지 확신이 없다면 ~all 로 시작해 DMARC 보고서로 확인한 뒤 판단하는 경우가 많습니다.
SPF 레코드를 두 개 만들면 안 되나요? (흔한 오해)
안 됩니다. 발송 서비스를 추가할 때 v=spf1 로 시작하는 TXT 를 하나 더 만드는 실수가 흔한데, 한 도메인에 SPF 레코드가 둘 이상이면 수신 서버는 permerror 로 판정합니다(RFC 7208 §4.5, §3.2). 두 레코드의 항을 하나로 합쳐야 합니다. 레코드가 255자를 넘어 나눠야 할 때는 레코드를 두 개로 만드는 것이 아니라, 한 레코드 안에서 문자열을 "…" "…" 처럼 나눠 적습니다 — 수신 서버는 이 문자열들을 공백 없이 이어 붙여 읽습니다(§3.3). 그래서 나눈 자리 앞뒤에 필요한 공백은 직접 넣어야 합니다. 이 도구도 같은 규칙으로 이어 붙여 해석합니다.
p=none 이면 DMARC 가 없는 것과 같은가요?
처리 요청만 보면 비슷하지만 같지는 않습니다. p=none 은 DMARC 에 실패한 메일에 대해 수신 서버에 별도 조치를 요청하지 않는 모니터링 단계입니다(RFC 7489 §6.3 p). 대신 rua 에 적은 주소로 집계 보고서를 받을 수 있어, 이 도메인 이름으로 어떤 서버가 메일을 보내고 SPF·DKIM 이 통과하는지 알 수 있습니다. 보고서로 정상 발신이 모두 통과하는 것을 확인한 뒤 quarantine(의심 메일로 처리 요청)이나 reject(거부 요청)로 올리는 것이 일반적인 순서입니다. pct 로 일부 메일에만 먼저 적용할 수도 있습니다(§6.6.4). 레코드가 둘이거나 v=DMARC1 이 첫 태그가 아니면 수신 서버는 DMARC 를 아예 적용하지 않으므로(§6.6.3) 형식도 함께 확인합니다.
DKIM 이 "없음"으로 나오는데 실제로는 서명하고 있어요. 왜 그런가요?
DKIM 공개키는 선택자마다 다른 이름(선택자._domainkey.도메인)에 있고, DNS 에서 선택자 목록을 알아낼 방법은 없습니다(RFC 6376 §3.1). 입력한 선택자에 키가 없다는 뜻일 뿐, 다른 선택자로 서명하고 있을 수 있습니다. 그 도메인에서 받은 메일의 원본을 열어 DKIM-Signature 헤더의 s= 값을 확인해 넣으세요. 반대로 여기서 키가 보인다고 해서 실제로 서명해 보내는지는 알 수 없습니다 — 서명은 메일 헤더에 있습니다. p= 가 비어 있으면 키를 폐기했다는 뜻이고(§3.6.1), RSA 키가 1024비트보다 짧으면 수신 서버는 그 서명을 유효하다고 보지 않습니다(RFC 8301 §3.2).
모두 "설정됨"인데도 메일이 스팸함으로 가요. 이 도구의 한계는 무엇인가요?
이 도구는 DNS 에 공개된 설정만 봅니다. 실제 메일을 보내 보지 않으므로 DKIM 서명 검증, SPF·DKIM 도메인과 보낸 사람(From) 도메인의 정렬(RFC 7489 §3.1), 발신 IP 의 평판, 본문 내용은 확인하지 못합니다. 메일을 받아 줄지, 스팸함에 넣을지는 결국 수신 서버의 자체 정책입니다(RFC 7208 §8, RFC 7489 §6.7) — 그래서 이 도구는 "스팸함으로 갈 수 있습니다"처럼 가능성으로만 말합니다. 또 공개 접미사 목록을 쓰지 않아 DMARC 조직 도메인은 후보로만 보여 주고, 외부 보고서 주소 확인도 "다른 조직일 때" 조건부로 판단합니다. MTA-STS·BIMI·역방향 DNS 는 점검하지 않습니다. 악의적으로 깊은 레코드가 조회를 무한정 만들지 못하게 SPF 는 조회 항 40개, 외부 보고서 주소는 5곳까지만 확인하고 전체 30초가 지나면 멈춥니다 — 이렇게 생략한 부분은 "도구 조회 상한으로 확인 생략"으로 따로 표시하며, 수신 서버의 판정과는 무관합니다.
입력한 도메인은 어디로 가나요?
입력한 도메인과 선택자로 만든 DNS 이름(예: _dmarc.example.com)은 브라우저에서 Cloudflare DNS(cloudflare-dns.com, 1.1.1.1 서비스)로 바로 조회됩니다. microlab 서버나 scan-api 는 거치지 않고, 그 밖에는 아무것도 전송되지 않습니다. SPF 의 include 를 따라가는 조회도 같은 경로로 브라우저가 합니다. 공유 링크의 도메인은 주소의 # 뒤(해시)에 있어 이 사이트 서버로 보내지지 않습니다. 익명 방문 통계만 집계합니다.