이메일 전달 가능성 검사
평판보다 먼저, 내용보다 먼저, 수신자는 단 하나의 질문을 던집니다. 이 도메인이 메일이 정말 자기 것이라는 것을 증명할 수 있는가? 이 검사는 그 증거를 읽습니다 — MX 레코드, SPF 발신자 목록(수신자가 세는 방식으로 펼치고 셈), _dmarc에 있는 DMARC 정책, 그리고 일반적인 선택기 아래 있는 DKIM 키 — 그리고 운영자가 고칠 순서대로 쉬운 말로 소견을 돌려줍니다.
계속 지켜보고 싶으신가요? myeventwatch로 무료로 모니터링 — 만료 및 중단 알림, 카드 불필요.
이 검사가 측정하는 것
스팸 필터링은 신원에서 시작합니다. 신원은 밀리초 만에 확인할 수 있기 때문입니다. 어떤 도메인에서 온 것이라고 주장하는 메일이 도착하면, 수신 서버는 그 도메인이 게시한 규칙을 조회합니다. SPF는 보내도록 허용된 서버를 이름 붙입니다. DKIM은 게시된 키로 검증할 수 있는 서명을 제공합니다. DMARC는 보이는 From 도메인이 그 두 가지 증거 중 하나와 정렬될 것을 요구하고, 어느 쪽도 없는 메일에 대한 처벌 — 없음, 격리, 거부 — 을 명시합니다. 이 페이지는 sysosx 서버의 GET /api/check/email-auth를 호출하는데, 이는 상태 검사가 사용하는 DNS 파서로 같은 레코드를 읽어 소견으로 바꿉니다: 프로토콜마다, 문제마다, 하나의 심각도로, 고칠 가치가 있는 순서대로.
소견 중 두 가지는 정직함에 대해 한마디 할 가치가 있습니다. 둘 다 검사기가 흔히 정밀도를 가장하는 곳이기 때문입니다. SPF 조회 수는 진짜입니다. 검사기는 수신자가 적용하는 것과 같은 규칙으로 include와 redirect 체인을 항목별로 펼치므로, 보고하는 숫자는 엄격한 수신자가 계산할 숫자와 같습니다 — 공급업체가 자기 레코드를 바꾸면서 레코드가 열 번이라는 조회 제한을 조용히 넘어 표류한 경우까지 포함해서요. 그리고 DKIM 결과는 전수조사가 아니라 탐색입니다. 키는 소유자가 선택한 선택기 이름 아래에 게시되고, 검사는 일반적인 것들을 시도하며, 그중 어느 것도 찾지 못했다고 해서 DKIM이 없다는 증명이 되지는 않습니다 — 다른 선택기 아래 있는 키는 밖에서 보이지 않으며, 결과는 도메인이 서명하지 않는다고 선언하는 대신 그 사실을 분명히 말합니다. 유일하게 완전한 DKIM 검사는 여전히 실제 메시지와 그 Authentication-Results 헤더입니다.
결과 읽는 법
실패부터 시작하세요. 그것들이 스팸 폴더가 가장 좋아하는 원인입니다. MX가 없다는 것은 그 도메인이 메일을 전혀 받을 수 없다는 뜻입니다. SPF가 없거나 +all로 끝나는 SPF 레코드는 누구나 당신이라고 주장할 수 있다는 뜻입니다 — 두 번째가 더 나쁩니다. 그 주장이 공식적으로 허용되기 때문입니다. 여러 개의 SPF 레코드는 SPF 평가 전체를 조용히 무효로 만듭니다. DMARC 레코드가 없다는 것은 실패한 메일에 명시된 처벌이 없고, 똑같이 값비싼 대가로, 당신의 도메인으로 보내는 사람이 누구인지 보여주는 집계 보고서를 아무도 수집하지 않는다는 뜻입니다 — 그 보고서들이 바로 스푸핑 캠페인이 보통 발견되는 방식입니다. 보고서가 도착하면 원시 XML로 도착합니다. DMARC 보고서 분석기는 .xml, .gz, .zip 파일을 로컬에서 열어 누가 통과했고, 누가 실패했으며, 무엇을 고쳐야 하는지를 출처별 표로 바꿉니다. 경고는 중간 상태입니다. p=none은 DMARC를 시작하기 좋은 곳이지만 멈추기 나쁜 곳입니다. ~all은 테스트 모드이지 목적지가 아닙니다. 그런 다음 그림의 나머지 절반을 보세요. 인증은 신원을 증명하고, DNS 블랙리스트 검사기는 평판을 측정합니다 — 둘 다 실행하세요. 완벽하게 인증된 도메인도 등재된 IP에 있으면 스팸으로 가고, 깨끗한 IP도 SPF가 깨져 있으면 마찬가지이기 때문입니다. 이를 모두 하나로 묶는 가이드는 이메일이 스팸으로 가는 이유입니다.
자주 묻는 질문
SPF, DKIM, DMARC는 무엇이며 어떻게 맞물리나요?
이것들은 “이 메일이 정말로 주장하는 그 도메인에서 온 것인가?”라는 질문에 대한, DNS에 게시된 세 가지 답입니다. SPF는 도메인을 위해 보내도록 허용된 서버를 나열합니다. DKIM은 도메인이 메시지에 암호학적으로 서명할 수 있게 하여, 수신자가 DNS에 게시된 키로 서명을 검증할 수 있게 합니다. DMARC는 이들을 하나로 묶습니다. 보이는 From 헤더의 발신 도메인이 SPF 또는 DKIM 결과와 정렬될 것을 요구하고, 어느 쪽도 정렬되지 않을 때 무엇을 할지 — 모니터링, 격리, 거부 — 를 수신자에게 알려줍니다. DMARC 없는 SPF는 서명 없는 제안입니다. DMARC가 다른 두 가지를 정책으로 만드는 것입니다.
세 가지가 모두 통과하는데도 메일이 여전히 스팸으로 갑니다. 왜인가요?
인증은 입장권이지 좌석 배정이 아니기 때문입니다. SPF, DKIM, DMARC를 통과한다는 것은 수신자가 메일이 진짜 당신의 것이라고 믿는다는 뜻입니다 — 그 뒤 배치(placement)는 평판과 내용에 달려 있습니다. 블랙리스트 등재(이 사이트의 블랙리스트 검사기로 확인하세요), 수신자 참여, 불만 비율, 발송량 패턴, 그리고 메시지 자체가 그것입니다. 인증 실패는 스팸 배치의 가장 흔한 고칠 수 있는 원인이며, 이 검사가 먼저 오는 이유가 그것입니다. 하지만 여기서 깨끗한 결과가 나오는데도 스팸 배치가 계속된다면, 문제는 신원이 아니라 평판이나 내용에 있습니다.
검사에서 DKIM 키를 찾을 수 없다고 합니다. 제 도메인이 서명하지 않는다는 뜻인가요?
아닙니다 — 그리고 결과 자체가 그 말 그대로 그렇게 말합니다. DKIM 키는 도메인 소유자가 선택한 선택기 이름 아래에 있으며, 도메인의 선택기를 밖에서 열거할 방법은 없습니다. 이 검사는 주요 제공업체가 사용하는 일반적인 선택기(default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill 등)를 탐색합니다. 다른 이름 아래 있는 키는 탐색에서 보이지 않습니다. 결정적인 검사는 실제 메시지입니다. 당신이 통제하는 사서함으로 메일을 보내고, 사용된 선택기와 서명이 검증되었는지를 보고하는 Authentication-Results 헤더를 확인하세요.
검사는 왜 SPF 조회 수를 세나요? 왜 제한이 10인가요?
SPF 레코드를 평가하려면 추가 DNS 조회가 필요할 수 있습니다 — include, a, mx, ptr, exists, redirect 항목마다 하나씩 듭니다. RFC 7208은 총합을 10으로 제한합니다. 이를 넘으면 수신자는 영구 오류를 반환하고 SPF 결과는 무효가 되는데, 이는 깔끔하게 평가되는 소박한 레코드보다 더 나쁠 수 있습니다. 제공업체가 추가될수록 레코드는 조용히 조회를 늘립니다(각 include는 자체 항목을 가져옵니다). 그래서 설정 당시 합법이던 레코드가 공급업체가 자기 레코드를 바꾸면서 제한을 넘어 표류할 수 있습니다. 이 검사는 수신자가 하듯 레코드를 펼쳐 실제 수를 보고하므로, 표류가 인증을 무효로 만들기 전에 볼 수 있습니다.
여러 소견이 실패라면 무엇을 먼저 고쳐야 하나요?
순서대로: 여러 개의 SPF 레코드(하나로 합치세요 — 그것이 고쳐지기 전까지 하위 모든 것이 신뢰할 수 없습니다), 없거나 +all인 SPF 레코드(실제 발신자 목록을 게시하고 -all로 끝내세요), 없는 DMARC 레코드(보고 주소와 함께 p=none으로 시작하세요. 그래야 강제하기 전에 누가 당신으로 보내는지 볼 수 있습니다), 그런 다음 보고서가 깨끗하게 들어오면서 DMARC를 p=none에서 p=reject 쪽으로 올리세요. 블랙리스트 등재가 있다면 그것은 병행 작업입니다 — 레코드를 수리하는 동안 그 원인을 고치고 등재 해제를 요청하세요. 저희 가이드는 그 순서를 이유와 함께 안내합니다: 이메일이 스팸으로 가는 이유.