DNS 보안과 이메일 인증은 브랜드 보호의 기본 인프라다

브랜드 사칭 메일을 줄이기 위해 SPF·DKIM·DMARC 레코드만 한 번 등록하고 끝내는 조직이 많다. 그러나 마케팅, CRM, 고객지원, 청구, 채용, 모니터링 서비스가 각각 메일을 보내면 발송 경로는 계속 바뀐다. 퇴출한 SaaS가 SPF에 남거나 새 서비스가 DKIM 정렬 없이 발송하면 정상 메일이 실패하고, 공격자가 방치된 발송 권한을 악용할 수 있다.

DNS와 이메일 인증은 단순 TXT 레코드 관리가 아니라 도메인 소유권, 발송 서비스, 키 수명주기, 보고서 분석, 변경 승인을 묶는 운영 체계다.

세 기술의 역할을 혼동하지 않는다

기술	확인하는 것	놓칠 수 있는 것
SPF	SMTP 발송 도메인에 허용된 서버인지	전달·포워딩, 보이는 From과의 불일치
DKIM	메시지가 서명 후 변조되지 않았고 해당 도메인 키로 서명됐는지	서명 도메인이 보이는 From과 다를 수 있음
DMARC	보이는 From 도메인과 SPF 또는 DKIM 인증 도메인이 정렬되는지	유사 철자 도메인, 표시 이름 사칭, 계정 탈취

DMARC 통과는 SPF와 DKIM을 둘 다 통과해야 한다는 뜻이 아니다. 정렬된 SPF 또는 정렬된 DKIM 중 하나가 유효하면 통과할 수 있다. 운영 안정성을 위해서는 가능한 발송 흐름에서 두 메커니즘을 모두 올바르게 구성하는 편이 좋다.

먼저 모든 발송원을 찾는다

정책을 강화하기 전에 최소 2~4주 동안 다음 경로를 인벤토리화한다.

• 기업 메일과 그룹웨어
• 마케팅·뉴스레터
• CRM·고객지원·티켓 시스템
• 결제·청구·영수증
• 채용·설문·전자서명
• 애플리케이션 트랜잭션 메일
• 모니터링·보안 알림
• 복합기, 레거시 서버, 현장 장비

각 발송원에 소유 부서, 서비스 계정, Envelope-From 도메인, DKIM 서명 도메인과 selector, 예상 발송량, 종료일을 기록한다. “누구 것인지 모르는 정상 메일”은 DMARC 강화의 가장 큰 장애물이다.

SPF는 한 레코드와 관리 가능한 범위로 유지한다

SPF는 발송 인프라가 바뀔 때마다 복잡해지기 쉽다.

• 루트 도메인과 하위 발송 도메인의 책임을 분리한다.
• 여러 TXT SPF 레코드를 중복 게시하지 않는다.
• 사용하지 않는 include와 오래된 IP를 제거한다.
• 벤더가 제공하는 범위를 그대로 추가하기 전에 실제 필요성을 확인한다.
• DNS 조회 한도와 재귀적 include를 정기 검사한다.
• 대량 발송은 전용 하위 도메인으로 분리해 영향 범위를 줄인다.

SPF만으로는 메일 전달 과정에서 인증이 깨질 수 있으므로 DKIM과 DMARC 정렬을 함께 본다.

DKIM 키와 selector를 운영 자산으로 다룬다

DKIM은 발송 서비스마다 별도 selector를 사용하면 소유자와 회전 상태를 추적하기 쉽다.

• selector 이름에 서비스·환경·연도를 식별할 수 있는 규칙을 둔다.
• 개인키는 발송 시스템 또는 승인된 키 관리 서비스에 보관한다.
• 키 생성, 활성화, 병행 서명, 이전 키 제거 순서를 문서화한다.
• DNS 캐시와 메일 지연을 고려해 이전 공개키를 즉시 삭제하지 않는다.
• 발송 서비스 종료 시 selector와 API 자격 증명을 함께 폐기한다.
• 약한 키나 지원 종료 알고리즘 사용 여부를 공급자 문서에서 확인한다.

키 회전은 새 selector로 병행 서명한 뒤 수신 측 통과율을 확인하고 이전 키를 제거하는 방식이 안전하다.

DMARC는 보고서에서 집행으로 이동한다

현재 DMARC 프로토콜 기준은 RFC 9989이며, 집계 보고와 실패 보고는 각각 RFC 9990과 RFC 9991에 정리돼 있다. 오래된 구현 문서만 참조하지 말고 메일 공급자와 분석 도구가 최신 형식을 지원하는지 확인한다.

전환 순서는 다음과 같다.

1. 전용 보고서 수신 주소와 처리 시스템을 만든다.
2. 모니터링 정책으로 집계 보고서를 수집한다.
3. 정상 발송원을 소유자와 연결하고 정렬 실패를 수정한다.
4. 하위 도메인과 비발송 도메인의 정책을 별도로 검토한다.
5. 제한된 범위에서 격리 정책을 적용한다.
6. 정상 메일 실패율과 고객지원 티켓을 확인한다.
7. 충분히 검증한 뒤 거부 정책으로 강화한다.
8. 신규 발송 서비스 등록을 변경 관리 절차에 포함한다.

정책 값만 바꾸지 말고 DMARC 보고서에서 소스 IP, 인증 결과, 정렬 도메인, 발송량 변화를 관찰한다. 보고서에는 개인정보와 운영 메타데이터가 포함될 수 있으므로 접근과 보존을 제한한다.

DNS 계정과 레코드 변경을 보호한다

메일 인증이 정확해도 DNS 계정이 탈취되면 공격자가 MX, SPF, DKIM, DMARC를 바꿀 수 있다.

• 등록기관과 DNS 관리자 계정에 피싱 저항 MFA를 적용한다.
• 등록기관 잠금과 중요 도메인의 변경 보호 기능을 검토한다.
• DNS 관리와 메일 서비스 관리를 다른 역할로 분리한다.
• API 토큰을 영역·레코드 유형별 최소 권한으로 제한한다.
• NS, MX, TXT, CAA 변경을 실시간에 가깝게 경보한다.
• 변경 전후 레코드와 TTL, 요청자, 티켓을 보존한다.

DNSSEC는 DNS 응답의 출처와 무결성을 검증하는 통제이며 SPF·DKIM·DMARC를 대신하지 않는다. DS와 KSK/ZSK 수명주기, 등록기관 연계, 롤오버 실패 시 복구를 별도로 시험한다.

탐지 신호

• DMARC 집계 보고서에 처음 보는 발송 IP·서비스가 나타난다.
• 정상 발송량 대비 SPF 또는 DKIM 실패율이 급증한다.
• 특정 selector의 서명 실패가 만료·회전 시점에 증가한다.
• 새 include, MX, NS, DMARC 보고 URI가 승인 없이 추가된다.
• 사용하지 않는 도메인에서 메일 발송이 관찰된다.
• 메일 전달 규칙 또는 OAuth 앱 승인과 동시에 사칭 메일이 증가한다.
• 비슷한 철자의 새 도메인이 등록되고 브랜드 표시 이름을 사용한다.
• 보고서 수집이 중단되거나 파일 크기가 비정상적으로 줄어든다.

유사 도메인과 표시 이름 사칭은 DMARC만으로 막을 수 없다. 브랜드 모니터링, 안전한 결제 절차, 보안 인식 프로그램, 피싱 신고 채널을 함께 운영한다.

실패 모드

실패	영향	교정
발송원 인벤토리 없이 거부 정책	정상 메일 차단	보고서 기반 단계적 강화
SPF include 누적	조회 실패와 소유자 불명	서비스별 하위 도메인·정기 정리
DKIM selector 공유	키 노출 영향이 여러 서비스로 확산	서비스별 selector와 회전
DMARC 통과만 KPI로 사용	계정 탈취·유사 도메인 놓침	로그인 보안·브랜드 탐지 결합
DNS 관리자 공유 계정	변경 책임 추적 불가	개인 계정·MFA·감사 로그
DNSSEC 롤오버 미시험	도메인 해석 장애	사전 검증과 롤백 절차

변경과 롤백 절차

DNS 변경은 캐시 때문에 즉시 되돌아오지 않는다. 정책 강화 전 TTL을 검토하고, 변경 창과 관찰 시간을 정한다. 정상 메일 실패가 발생하면 전체 인증을 제거하기보다 문제 발송원을 전용 하위 도메인으로 분리하거나 해당 selector·정렬을 수정한다.

1. 변경 전 레코드와 보고서 기준선을 저장한다.
2. 낮은 발송량 도메인 또는 하위 도메인에서 시험한다.
3. 인증 성공률, 반송, 고객지원 티켓을 모니터링한다.
4. 실패 원인이 확인되면 승인된 이전 레코드로 되돌린다.
5. DNS 전파가 완료될 때까지 이중 상태를 추적한다.
6. 변경 후 소유자·발송원 인벤토리를 갱신한다.

운영 체크리스트

• 모든 메일 발송 서비스와 소유자가 목록화돼 있다.
• SPF 레코드는 중복 없이 관리되고 오래된 include를 정리한다.
• 발송 서비스별 DKIM selector와 회전 일정이 있다.
• Envelope-From, DKIM 도메인, 보이는 From의 정렬을 확인한다.
• DMARC 집계 보고서를 지속적으로 수집·분석한다.
• 정책 강화는 모니터링에서 격리·거부로 단계화한다.
• 비발송·하위 도메인 정책도 검토했다.
• DNS·등록기관 관리자에 강한 MFA와 변경 경보가 있다.
• DNSSEC를 사용할 경우 키 롤오버와 복구를 시험했다.
• 유사 도메인·표시 이름·계정 탈취 대응을 별도로 운영한다.

참고 기준

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: DMARC
• RFC 9990: DMARC Aggregate Reporting
• RFC 9991: DMARC Failure Reporting
• RFC 9364: DNS Security Extensions Best Current Practice

결론

이메일 인증의 목표는 레코드 검사 사이트에서 초록색을 받는 것이 아니다. 모든 정상 발송원을 소유자와 연결하고, 도메인 정렬과 키 회전을 유지하며, DNS 변경과 보고서를 지속적으로 감시하는 것이 목표다. DMARC를 강화한 뒤에도 계정 탈취와 유사 도메인 사칭은 남으므로 사용자 신고와 결제 검증 절차까지 함께 운영해야 한다.