mark_email_read 이메일 DNS 점검기 (SPF, DKIM, DMARC) star

이메일 인증이 작동하는 방식

세 가지 DNS 레코드가 함께 작동하여 누군가가 귀하의 도메인에서 보낸 것처럼 위조된 메일을 보내지 못하도록 막습니다. SPF(Sender Policy Framework)는 해당 도메인을 대신해 메일을 발송할 권한이 명시적으로 부여된 서버 목록을 DNS에 게시합니다 — 수신 서버는 접속한 IP를 이 목록과 대조합니다. DKIM(DomainKeys Identified Mail)은 발신되는 모든 메시지에 암호화 서명을 추가합니다. 수신 서버는 DNS에서 공개 키를 가져와 메시지가 전송 중에 변조되지 않았는지 검증하는데, 이는 SPF만으로는 감지할 수 없는 부분입니다. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 이 둘을 하나로 묶습니다: SPF나 DKIM 검증이 실패했을 때 수신 서버가 어떻게 처리해야 하는지 — 아무 조치도 하지 않거나, 스팸으로 보내거나, 아예 거부하도록 — 지정하며, 취합 리포트를 요청하여 사칭자를 포함해 실제로 누가 귀하의 도메인 명의로 메일을 보내고 있는지 확인할 수 있게 해줍니다.

구체적인 예를 들면, 이 세 가지 레코드가 하나도 없다면 공격자는 [email protected]에서 보낸 것처럼 보이는 이메일을 보낼 수 있으며, 대부분의 메일 서버는 수신자에게 아무런 경고 없이 이를 그대로 받은편지함으로 전달합니다. 위의 점검기에 도메인을 입력하면 DNS-over-HTTPS를 통해 MX, SPF, DKIM(일반적인 셀렉터를 자동으로 시도), DMARC를 조회한 뒤 정확히 무엇이 빠져 있는지 표시합니다: SPF 레코드가 전혀 없는 경우, p=none에 머물러 있는 DMARC 정책(모니터링만 하고 실질적인 보호 효과는 전혀 없음), 서로 충돌하는 두 개의 SPF 레코드(검증을 완전히 무너뜨리는 표준 위반), 또는 SPF 문자열 끝에 all 메커니즘이 빠져 있는 경우입니다.

알아두어야 할 사항

브랜드 평판이나 받은편지함 전달률을 신경 쓰는 사람이라면 이 세 가지 레코드를 모두 올바르게 설정하는 것은 선택 사항이 아닙니다 — SPF, DKIM, DMARC에 공백이 있는 도메인은 스푸핑당하기 쉬울 뿐 아니라, 정상적인 메일조차 스팸으로 분류될 가능성이 높습니다. Gmail, Yahoo, Outlook 같은 주요 제공업체들이 발신자를 신뢰하기 전에 완전한 인증을 점점 더 많이 요구하기 때문입니다. 순서대로 진행하면 이 작업은 안전합니다: 먼저 SPF를 게시하고, 메일 제공업체를 통해 DKIM 서명을 추가한 다음, p=none으로 시작하는 DMARC를 추가하여 실제 메일을 위험에 빠뜨리지 않으면서 취합 리포트를 지켜볼 수 있게 하십시오 — 마케팅 도구, CRM, 티켓 시스템 등 모든 정상적인 발신 출처가 확인되고 정렬된 뒤에야 격리(quarantine)나 거부(reject)로 전환하십시오.

• 하나의 도메인에는 SPF TXT 레코드가 단 하나만 있을 수 있습니다 — 여러 서비스(Google Workspace, 마케팅 플랫폼, CRM 등)를 사용한다면 별도의 레코드를 게시하는 대신 모든 include 메커니즘을 하나의 문자열로 합치십시오.
• DKIM 셀렉터는 제공업체마다 다릅니다: Google Workspace는 대개 "google"로 게시하고, Microsoft 365는 "selector1"이나 "selector2"를 사용합니다 — 자동 점검에서 아무것도 찾지 못한다면, 제공업체의 정확한 셀렉터 이름을 확인하여 직접 입력하십시오.
• 이 도구는 DNS 설정만 점검합니다. 블랙리스트 상태를 확인하거나 메시지 내용을 스캔하지는 않습니다 — 이는 올바르게 구성된 DNS 기반 위에 쌓이는 별도의 이메일 전달률 계층입니다.