회사 이메일이 스팸으로 분류될 때 DKIM 설정 점검하기

스팸 필터링 환경 변화와 기업 이메일의 신뢰성

최근 2025년을 기준으로 이메일을 통한 업무 커뮤니케이션은 여전히 필수적인 비즈니스 도구로 자리 잡고 있습니다. 그러나 수신자의 메일함에 안전하게 도달하지 못하고 스팸함으로 분류되는 사례가 빈번하게 발생하고 있습니다. 실제로 글로벌 이메일 보안기업 Barracuda의 2024년 보고서에 따르면 기업 이메일의 17%가 스팸 또는 의심메일로 분류되어 수신함이 아닌 별도의 폴더로 이동되고 있는 것으로 나타났습니다. 이러한 현상은 기업 신뢰도 저하와 업무 차질, 더 나아가 비즈니스 기회 상실로까지 이어질 수 있습니다.

이메일이 스팸으로 분류되는 주요 원인 중 하나는 발신자의 신원이 제대로 검증되지 않았을 때입니다. 이를 해결하기 위해 대표적으로 사용되는 기술이 바로 DKIM(DomainKeys Identified Mail)입니다. DKIM은 이메일의 발신 도메인이 해당 메일을 실제로 보냈음을 암호화된 서명으로 증명하는 메커니즘으로, 이메일 위조 방지와 신뢰성 강화에 매우 중요한 역할을 담당합니다.

DKIM 개념 및 동작 원리

DKIM은 공개키 기반 암호화 기술을 활용하여 이메일 헤더에 디지털 서명을 추가합니다. 구체적으로, 발신 메일 서버는 도메인에 대한 비공개 키(Private Key)로 일부 헤더와 본문 내용을 해시(암호화)한 뒤, 해당 해시값을 DKIM-Signature라는 헤더에 포함시킵니다. 수신 서버는 DNS에 공개된 공개 키(Public Key)를 활용해 서명을 검증함으로써, 해당 이메일이 실제 발신 도메인에서 생성됐고 중간에 변조되지 않았음을 확인할 수 있습니다.

DKIM은 SPF(Sender Policy Framework), DMARC(Domain-based Message Authentication, Reporting & Conformance)와 함께 이메일 인증의 3대 축으로 여겨집니다. DKIM이 제대로 설정되어 있지 않거나, 서명 검증에 실패할 경우, 구글(Gmail), 마이크로소프트(Outlook), 네이버, 다음 등 주요 이메일 서비스 제공업체의 스팸 필터는 해당 메일을 신뢰할 수 없는 발신자로 간주해 스팸 폴더로 분류할 가능성이 매우 높아집니다.

이메일이 스팸으로 분류되는 DKIM 관련 주요 이슈

DKIM이 제대로 설정되어 있지 않거나, 설정은 되어 있어도 잘못 구성된 경우 이메일의 신뢰성이 훼손되어 스팸 판정이 내려질 수 있습니다. 2024년 기준으로 국내외 IT기업에서 가장 많이 발생하는 DKIM 관련 이슈는 다음과 같습니다.

- DKIM 레코드 미설정: 신규 도메인을 도입하거나, 기존 메일 서버를 변경하면서 DKIM 레코드를 등록하지 않은 경우

- DKIM 키 만료 또는 교체 미비: DKIM 키의 주기적 교체가 이루어지지 않아, 만료된 키로 인해 인증 오류가 발생하는 경우

- DNS 레코드 오타 또는 누락: 공개키(Public Key)를 DNS TXT 레코드에 등록할 때 오타가 있거나, 일부 정보가 누락된 경우

- 메일 발송 시스템 분산 운영 시 각 시스템별 DKIM 일관성 미흡: 여러 시스템 또는 외부 서비스(예: 마케팅 자동화 플랫폼)에서 메일을 발송하면서 DKIM 설정이 일관되지 않은 경우

- 이메일 서명 헤더 변조: 중간 경로에서 이메일 내용이 변경되어 DKIM 서명이 무효화되는 경우

이러한 이슈는 메일 발송자의 의도와 무관하게 수신자의 스팸 필터에 의해 신뢰도가 떨어진 것으로 간주되어, 정상적인 업무 메일도 스팸으로 분류되는 원인이 됩니다.

DKIM 설정 점검을 위한 사전 준비

DKIM 설정을 점검하기 전, 우선 자신이 사용하는 도메인과 메일 시스템의 구조를 명확히 파악해야 합니다. 회사마다 메일 시스템 환경은 크게 세 가지로 나뉩니다.

1. 자체 메일서버 운영: 사내에 직접 메일 서버(Exchange, Postfix, Sendmail 등)를 구축해 운영하는 경우

2. 클라우드 기반 메일 서비스 이용: 구글 워크스페이스(Google Workspace), 마이크로소프트 365(Microsoft 365), 네이버웍스 등 SaaS 형태의 서비스를 이용하는 경우

3. 외부 메일 발송 서비스(마케팅 플랫폼 등) 병행: 자체 시스템과 외부 서비스(예: 메일침프, 센드그리드 등)에서 동시에 이메일을 발송하는 경우

와이파이 속도 올리기 비법 바로 가기

각 환경에 따라 DKIM 설정 위치와 방식이 상이하므로, 도메인 관리자, IT 담당자, 외부 서비스 공급자와의 협업이 필요합니다. 자신이 관리하는 도메인의 DNS 접근 권한이 있는지, 메일 시스템 설정 권한이 있는지도 반드시 확인해야 합니다.

DNS에 등록된 DKIM 레코드 점검 방법

DKIM 설정의 핵심은 도메인 DNS에 올바른 TXT 레코드가 등록되어 있는지 확인하는 것입니다. 일반적으로 DKIM 공개키는 다음과 같이 등록됩니다.

- 레코드 타입: TXT

- 호스트 이름(Selector): [selector]._domainkey.[도메인명]

- 값(Value): v=DKIM1; k=rsa; p=[공개키]; 기타 옵션

예를 들어, selector가 'mail', 도메인이 example.com일 경우 'mail._domainkey.example.com'이라는 TXT 레코드가 등록되어 있어야 합니다. 'p=' 다음에는 길이가 2048비트 이상의 RSA 공개키가 들어갑니다.

DNS 레코드 점검은 nslookup, dig 등 커맨드라인 도구를 활용하거나, 구글의 admin toolbox, MXToolbox, DKIMCore 등 DKIM 레코드 검사 웹사이트를 통해 손쉽게 확인할 수 있습니다. 다음은 nslookup을 이용한 예시입니다.

```

nslookup -type=TXT mail._domainkey.example.com

```

정상적으로 DKIM 레코드가 조회되고, 그 값이 메일 시스템에 설정한 공개키와 일치한다면 1차 점검은 완료된 것입니다. 오타, 누락, 공개키 길이 부족 등은 반드시 바로잡아야 하며, 최근 2024년 보안 권고 기준으로는 공개키 길이가 최소 2048비트 이상이어야 안전하다고 권장되고 있습니다.

메일 서버의 DKIM 서명 활성화 확인

DNS 레코드 설정만으로 DKIM이 동작하는 것은 아니며, 실제 메일 발송 서버에서 DKIM 서명 기능이 활성화되어야 합니다. 메일 발송 시스템에 따라 설정 방법이 다르므로, 각각의 환경에 맞는 점검이 필요합니다.

1. 자체 서버(예: Postfix)

- opendkim, dkim-milter 등 DKIM 모듈이 정상적으로 동작 중인지 확인합니다.

- 설정 파일에 selector, private key 경로, 도메인 정보가 정확하게 입력되어 있는지 점검합니다.

- 메일 발송 로그(/var/log/maillog 등)에 DKIM 서명 관련 오류가 없는지 살펴봅니다.

2. 구글 워크스페이스/마이크로소프트 365 등 클라우드 서비스

- 관리자 콘솔에서 DKIM 설정 메뉴를 이용해 서명 여부를 확인합니다.

- 구글의 경우 'Gmail > 인증 > DKIM'에서 서명 상태가 '활성화됨'인지 체크해야 합니다.

3. 외부 발송 서비스(메일침프, 센드그리드 등)

- 각 플랫폼의 발신 도메인 인증 메뉴에서 DKIM 설정이 'Verified' 또는 'Authenticated'로 표시되는지 확인합니다.

- 여러 서비스가 동일 도메인으로 메일을 발송하는 경우, 각 서비스별 별도 selector 사용을 권장합니다.

이 과정에서 메일 시스템과 DNS의 설정이 서로 일치하지 않거나, DKIM 모듈이 비활성화된 경우, 정상적으로 DKIM 서명이 생성되지 않아 스팸 필터에 걸릴 가능성이 높아집니다.

인터넷 느려짐 체크리스트 바로 가기

테스트 메일을 통한 DKIM 서명 검증

설정이 완료된 후에는 반드시 실제 메일을 발송해 DKIM 서명이 제대로 적용되는지 확인해야 합니다. 이때 Gmail, Outlook, 네이버, 다음 등 주요 포털 이메일로 테스트 메일을 보낸 후 수신함에서 헤더 정보를 확인합니다.

Gmail의 경우, 수신한 메일의 '원본 보기' 메뉴를 클릭하면 'DKIM-Signature' 헤더가 존재하고, 'DKIM: PASS'로 표시되는지 확인해야 합니다. Outlook에서도 유사한 방식으로 '인터넷 헤더 보기'에서 DKIM 관련 정보를 확인할 수 있습니다.

또한, mail-tester.com, MXToolbox Email Test, dkimvalidator.com 등 외부 DKIM 검사 서비스를 활용하면, 보다 상세하게 DKIM 서명 유무, selector, key 길이, DNS 레코드 일치 여부 등을 종합적으로 진단할 수 있습니다.

DKIM 서명 실패(FAIL) 시 주요 원인과 대처법

실제 점검 중 DKIM 서명 검증이 실패로 나타나는 경우, 다음과 같은 원인을 점검해야 합니다.

- 서명 생성시 사용한 selector와 DNS에 등록된 selector 불일치

- DNS TTL 미반영: 신규 레코드 등록 후 DNS 전파에 시간이 필요함(최대 수 시간~하루)

- 메일 본문 또는 헤더 변경: 중간 경유지에서 메일 내용이 수정되어 해시값 불일치 발생

- DNS 서버 오류 또는 캐시 문제: 외부에서 해당 레코드를 조회하지 못하는 경우

- 키 길이 부족 또는 포맷 오류: 공개키 길이가 짧거나, 특수문자 등으로 인해 포맷이 깨진 경우

이러한 문제는 각각의 증상에 맞게 DNS 레코드를 다시 등록하거나, 메일 발송 시스템의 DKIM 설정을 재확인하는 방식으로 해결해야 합니다. 특히 여러 메일 시스템이 혼재된 환경에서는 각 시스템별로 DKIM selector를 구분하여 관리하는 것이 충돌 및 혼선을 방지하는 데 도움이 됩니다.

DKIM과 함께 점검해야 할 SPF, DMARC

DKIM 인증만으로는 스팸 분류 문제를 완전히 해결할 수 없습니다. 최근 2024~2025년 기준으로 구글, 마이크로소프트 등 글로벌 메일사업자는 DKIM, SPF, DMARC 3종 인증을 모두 요구하는 추세입니다.

- SPF(Sender Policy Framework): 해당 도메인에서 메일을 발송할 수 있는 IP(서버) 목록을 DNS에 명시

- DMARC(Domain-based Message Authentication, Reporting and Conformance): DKIM, SPF 검증 실패 시 메일 수신 정책(Reject, Quarantine, None)을 정의하고, 인증 실패 통계를 보고받는 역할

SPF는 반드시 도메인 DNS에 'v=spf1 ...' 형식의 TXT 레코드가 등록되어야 하며, 실제 메일 발송 서버의 IP가 포함되어야 합니다. DMARC는 'v=DMARC1; p=none/quarantine/reject; rua=...' 형식으로 등록하며, 이 정책에 따라 메일 수신자가 인증 실패 메일을 어떻게 처리할지 결정합니다.

DKIM과 SPF, DMARC를 모두 올바르게 설정하면, 이메일의 신뢰도가 크게 향상되어 스팸 분류 확률이 현저히 낮아집니다. 실제로 구글의 2024년 공식 발표에 따르면 DMARC, DKIM, SPF가 모두 성공(PASS)한 도메인은 그렇지 않은 도메인 대비 스팸 분류 비율이 약 90% 이상 감소한다고 밝혔습니다.

앱테크 실수 5가지 알아보기 바로 가기

주기적인 점검과 DKIM 키 관리의 중요성

DKIM은 일회성 설정이 아니라, 주기적으로 점검·관리해야 하는 보안 요소입니다. 2025년 기준 최신 보안 베스트 프랙티스는 다음과 같습니다.

- DKIM 키의 정기적 교체(최소 1년 주기): 오래된 키는 노출 위험이 있으므로, 정기적으로 신규 키로 갱신해야 합니다.

- DNS 레코드 점검 자동화: DNS 모니터링 도구를 통해 DKIM 레코드 오류, 만료 등을 실시간으로 확인

- 발송 시스템 추가/변경 시 DKIM 재설정: 신규 시스템, 외부 발송 플랫폼 추가 시마다 반드시 DKIM 설정 반영

- DMARC 리포트 수신 및 분석: DMARC 정책에 따라 인증 실패 메일 통계를 주기적으로 분석해, 이상 징후를 조기에 파악

특히 최근에는 해킹, 피싱 공격이 증가함에 따라, 공격자가 도메인을 탈취해 위조 메일을 발송하는 사례가 늘고 있습니다. DKIM 키 관리가 허술하면, 공격자가 키를 탈취해 정상 메일로 위장할 수 있기 때문에 반드시 안전한 환경(예: 접근제어, 암호화 저장)에서 키를 보관해야 합니다.

스팸 분류 문제에 대한 종합적 접근과 실무 적용 전략

DKIM 점검은 이메일 스팸 분류 문제를 해결하는 매우 핵심적인 절차이나, 단독으로는 완벽하지 않습니다. 실제 2025년 최신 IT 보안 환경에서는 DKIM, SPF, DMARC를 동시에 적용하는 멀티레이어 인증체계가 표준으로 자리잡고 있습니다.

이메일이 스팸으로 분류되는 근본적인 원인은 발신자의 신원이 불확실하거나, 메일 내용이 의심스럽게 보일 때입니다. 따라서 DKIM 등 기술적 인증 외에도 다음과 같은 추가적인 실무 전략이 필요합니다.

- 메일 본문 내 의심스러운 링크, 대량 발송 패턴, 광고성 키워드 사용 자제

- 수신자의 적극적 신고(스팸 신고) 패턴 점검 및 대응

- 메일 발송 빈도, 수신자 리스트 관리, 발송량 조정 등 '발신 평판(Sender Reputation)' 관리

- 메일 발송 후 스팸 분류 현황을 주기적으로 모니터링하고, 이슈 발생 시 신속한 피드백 체계 마련

특히 DKIM 등 인증이 제대로 적용된 상태에서 여전히 스팸함으로 분류되는 경우, 메일 본문 패턴, 발송 빈도, 수신자의 행동(스팸 신고율 등)을 종합적으로 점검해야 하며, 필요시 주요 수신자(고객사 이메일 관리자 등)와 협의해 화이트리스트 등록 등 추가 조치를 취할 수도 있습니다.

결국 기업 이메일의 신뢰성을 지키는 일은 단순히 DKIM 한 가지 요소만으로는 완성될 수 없습니다. 기술적 인증, 시스템 운영, 내부 정책, 사용자 교육 등 종합적인 관점에서 접근해야 스팸 분류 문제를 근본적으로 개선할 수 있습니다.

최신 동향과 향후 전망

2025년 기준으로, 글로벌 이메일 서비스 사업자들은 점차 도메인 인증 미비 이메일에 대해 수신 거부 또는 강력한 필터링 정책을 적용하는 방향으로 정책을 강화하고 있습니다. 구글, 마이크로소프트, 야후 등은 DMARC 정책 미설정 도메인에서 대량 메일 발송 시 수신 자체를 차단하는 사례가 늘고 있습니다.

또한, DKIM 공개키의 길이(2048비트 이상) 권고, DNSSEC(도메인 네임 시스템 보안 확장) 적용 등 추가적인 보안 강화 움직임도 확대되고 있습니다. 국내에서도 2024년 하반기부터 대형 포털 및 금융기업을 중심으로 강화된 이메일 인증 정책 도입이 가속화되고 있습니다.

결론적으로, 회사 이메일이 스팸으로 분류되는 문제를 예방하기 위해서는 DKIM 설정을 정확하게 점검하고, 주기적으로 관리하는 것이 필수적입니다. 더불어, SPF, DMARC 등 인증 체계를 모두 갖추고, 메일 발송 시스템의 전반적인 신뢰성을 지속적으로 유지하는 것이 바람직합니다. 실무 담당자는 이러한 이메일 인증 체계의 중요성을 인식하고, 사전 점검과 정기적인 모니터링을 통해 기업의 디지털 신뢰도를 높이는 데 힘써야 하겠습니다.