이메일 DNS 레코드: MX, SPF, DKIM, DMARC

이메일은 서로 다른 역할을 하는 여러 DNS 레코드에 의존합니다. MX 레코드는 발신 메일 시스템에 도메인으로 들어오는 메시지를 어디로 전달해야 하는지 알려 줍니다. SPF는 어떤 발신 시스템이 허가되었는지에 대한 정책을 TXT 데이터로 게시합니다. DKIM은 DNS에 게시된 공개 키를 사용해 수신자가 암호화 서명을 검증할 수 있게 하고, DMARC는 정렬(alignment)에 실패한 메시지를 수신자가 어떻게 평가해야 하는지와 보고서를 어디로 보낼 수 있는지 알려 줍니다. 이 메커니즘들은 서로를 보완합니다. MX 레코드 하나가 올바르다고 해서 발신 메일이 인증되는 것은 아니며, 유효한 SPF 레코드가 수신 전달을 설정해 주는 것도 아닙니다.

수신 라우팅은 MX에서 시작됩니다

발신 메일 서버는 수신 도메인의 MX 레코드를 조회해 우선순위 값과 함께 하나 이상의 메일 교환기 호스트 이름을 받습니다. 대상이 여러 개일 때는 우선순위 숫자가 낮은 쪽이 먼저 선택되지만, 전송 시스템은 재시도와 가용성 로직을 적용할 수 있습니다. 대상 호스트 이름은 다시 자체 주소 확인이 필요합니다. 도메인에 MX 레코드가 없으면 메일 동작이 다른 DNS 규칙으로 대체될 수 있지만, 암묵적 대체에 의존하는 것은 의도한 구성을 직접 게시하는 것보다 대개 불명확합니다. MX 값을 이메일 제공업체의 최신 설정 안내와 대조하고, 메일에 사용하는 정확한 루트 도메인을 확인하세요.

SPF는 해당 도메인에 TXT 레코드로 게시되며 연결하는 발신자를 기준으로 평가됩니다. 조회 횟수 제한과 문법 규칙이 있으므로, 독립된 SPF 문자열 여러 개를 별도의 TXT 레코드로 복사해 넣으면 permerror가 발생할 수 있습니다. DKIM 레코드는 보통 발신자가 제공하는 셀렉터별 이름 아래에 게시되며, 셀렉터가 없으면 서명을 검증할 수 없게 됩니다. DMARC는 _dmarc 아래의 잘 알려진 이름을 사용하며, 더 엄격한 정책을 고려하기 전에 모니터링 모드로 시작할 수 있습니다. 값을 임의로 만들지 말고 도메인을 대신해 발송이 허가된 모든 메일 플랫폼에서 받으세요.

메일 인증에 정렬이 필요한 이유

DMARC는 설정된 정렬 모드에 따라 메시지의 보이는 From 도메인이 SPF 또는 DKIM으로 인증된 도메인과 정렬되는지 확인합니다. 이를 통해 수신자는 도메인의 허가된 사용과 단지 그 도메인에서 왔다고 주장하는 메시지를 구별할 수 있습니다. 인증된 엔벨로프 발신자가 보이는 From 도메인과 정렬되지 않으면 SPF는 통과해도 DMARC는 실패할 수 있고, 게시된 키가 없거나 잘못되었으면 DKIM 서명도 실패할 수 있습니다. 메일 플랫폼은 여러 발송 서비스를 쓰는 경우가 많으므로, 정책을 강화하기 전에 정당한 발신 출처를 모두 파악해 두어야 합니다.

• SPF를 수정하기 전에 도메인으로 메일을 보내는 모든 시스템을 나열합니다.
• 제공업체가 발급한 DKIM 셀렉터를 게시하고 정확한 셀렉터 이름을 확인합니다.
• 모니터링 준비 수준에 맞는 정책으로 DMARC 보고를 시작합니다.
• 제공업체를 마이그레이션한 후에는 MX 우선순위와 대상 주소 확인을 점검합니다.
• 정책을 강제하기 전에 집계 보고서를 검토하고 알 수 없는 발신자를 조사합니다.

마이그레이션 후 레코드 확인하기

이메일 제공업체를 옮길 때는 기존 DNS 구성을 내보낸 뒤 새 MX, SPF, DKIM, DMARC 레코드를 새 제공업체의 설정 체크리스트와 비교하세요. 일부 제공업체는 메일 레코드 외에 도메인 인증용 TXT 레코드도 요구합니다. 이전 발송 시스템은 정당한 트래픽을 계속 보내는 동안에만 허가를 유지하고, 모니터링 후 불필요해진 허가는 신중하게 제거하세요. DNS TTL 캐싱 때문에 모든 수신자가 변경을 동시에 보지는 못합니다. 공개 응답을 확인하고 대표적인 수신 시스템에 테스트 메시지를 보내 보되, 전달 결과는 평판, 콘텐츠, 수신 측 필터링에도 좌우된다는 점을 기억하세요.

DNS 조회는 레코드가 공개적으로 보이는지는 알려 줄 수 있지만, 메시지가 받은편지함에 도착할지는 그것만으로 증명하지 못합니다. MX 레코드 가이드와 SPF, DKIM, DMARC 설명에서 각 메커니즘을 다룹니다. DNS 체커로 특정 이름과 유형을 점검한 뒤, 통제된 테스트 메시지를 발송하고 제공업체 로그를 검토해 검증하세요. 체크리스트에서 라우팅과 인증을 분리해 두면 메일 변경이 훨씬 안전해집니다.

메일 DNS를 바꾸기 전에 목록부터 만드세요

많은 조직에는 정당한 발신자가 둘 이상 있습니다. 메일박스 제공업체, 마케팅 플랫폼, 티켓 시스템, 회계 애플리케이션, 모니터링 서비스가 모두 같은 도메인으로 발송할 수 있습니다. 각 공급업체, 발신 도메인, SPF 요구 사항, DKIM 셀렉터, 담당자를 정리한 목록을 만드세요. 각 공급업체가 보이는 From 도메인을 쓰는지 위임된 서브도메인을 쓰는지도 확인하세요. 이 목록은 안전한 DMARC 정책의 토대입니다. 보고서에서 메일 관리자가 존재하는 줄 몰랐던 시스템이 드러나는 경우가 많기 때문입니다. 공급업체는 최신 문서와 실제 테스트 메시지로 검증하고, 팀이 해당 트래픽이 더 이상 필요 없음을 확인한 뒤에만 불필요한 발신자를 제거하세요.