Zimbra 서버에 DKIM, SPF 및 DMARC 레코드를 구성하는 방법

DKIM, SPF, DMARC는 발신 이메일 인증의 세 가지 핵심 요소를 해결하며, 안정적인 Zimbra 구축을 위해서는 이러한 기술들이 서로 연동되어야 합니다. SPF는 수신자에게 발신 도메인을 사용하여 이메일을 보낼 수 있는 시스템을 알려줍니다. DKIM은 도메인에 연결된 암호화 서명을 추가합니다. DMARC는 SPF 또는 DKIM 인증이 통과되었는지 확인하고, 통과한 인증 정보가 메시지의 From 헤더에 표시된 도메인과 일치하는지 확인한 후, 처리 및 보고 정책을 게시합니다.

현재 표준 관련 중요한 세부 사항 하나가 있습니다. 2026년 10월 현재, DMARC 프로토콜의 활성 사양은 2026년 5월에 발표된 RFC 9989 입니다 . 이 사양은 이전 RFC 7489를 대체하고 배포 관련 세부 사항을 변경하는데, 여기에는 이전 pct태그를 더 이상 사용하지 않도록 하고 t테스트 태그를 도입하는 내용이 포함됩니다. 이전 Zimbra 가이드나 DNS 튜토리얼에서 이전 DMARC 예제를 복사하는 경우 이 점을 유의해야 합니다.

DNS 변경 전에 필요한 사항

Zimbra MTA에 대한 관리자 셸 액세스 권한, 발신 도메인의 권한 있는 공용 DNS 영역에 대한 액세스 권한, 그리고 해당 도메인을 사용하여 합법적으로 메일을 보내는 모든 시스템의 전체 목록이 필요합니다. 이 목록에는 Zimbra 서버, 릴레이 또는 스마트 호스트, 마케팅 플랫폼, 티켓팅 시스템, 클라우드 애플리케이션 및 재해 복구 메일 서비스가 포함될 수 있습니다.

흔히 Zimbra 호스트에 대한 레코드만 게시하는 것으로 충분하다고 오해합니다. Zimbra가 실제로 유일한 승인된 발신자인 경우에만 충분합니다. SPF는 SMTP ID를 기준으로 평가되며, DMARC는 적용이 활성화되면 누락된 타사 발신자를 노출시킬 수 있습니다. 조치: 제한적인 SPF 또는 DMARC 정책을 게시하기 전에 모든 아웃바운드 소스를 목록화하십시오.

Zimbra 이메일 인증을 구성하기 전에 터미널에 표시되는 zmhostname, zmprov gad 및 mail.example.com에 대한 DNS A 레코드 조회 결과입니다. — SPF, DKIM 또는 DMARC 레코드를 생성하기 전에 Zimbra 호스트 이름, 호스팅 메일 도메인 및 공용 DNS 매핑을 확인하십시오.

1단계: Zimbra에서 DKIM 키를 생성합니다.

Zimbra에는 zmdkimkeyutil도메인 수준의 DKIM 서명 유틸리티가 포함되어 있습니다. Zimbra 공식 문서에 따르면 이 유틸리티는 MTA 서버에서 실행해야 합니다. DKIM 데이터가 없는 도메인에 DKIM 데이터를 추가하려면 Zimbra 계정으로 로그인하여 다음 명령을 실행하세요.

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

이 명령은 DKIM 데이터를 Zimbra의 LDAP 도메인 항목에 저장하고 게시해야 하는 선택자와 공개 TXT 레코드를 출력합니다. Zimbra의 DKIM 서명 문서에는-q 기존 DKIM 데이터를 조회, -u업데이트 및 -r삭제하는 방법 도 설명되어 있습니다 .

최신 Zimbra 설치 환경에서는 온라인에서 볼 수 있는 예시와 출력되는 선택기 값이 다를 수 있습니다. 선택기는 '' 또는 default'' 와 같은 고정된 단어가 아니므로 zimbra, 서버에서 출력되는 선택기를 정확히 사용해야 합니다. 조치: 공개 키 레코드를 수동으로 재구성하는 대신 명령 출력에서 전체 공개 키 레코드를 복사하십시오.

Zimbra 터미널에서 `zmdkimkeyutil -a -d example.com` 명령어를 실행하고 DKIM 선택기와 공용 DNS TXT 데이터를 표시하는 화면입니다. — MTA에서 Zimbra의 DKIM 유틸리티를 실행하고, 해당 유틸리티가 도메인에 대해 반환하는 선택기와 공개 키를 사용하십시오.

2단계: DKIM TXT 레코드를 게시합니다.

DKIM 검증자는 셀렉터와 를 조합하여 생성된 이름으로 DNS에서 공개 키를 조회합니다 ._domainkey. 이 메커니즘은 RFC 6376 에 정의되어 있습니다 . 실제 DNS 제공업체 관점에서 레코드는 일반적으로 다음과 같습니다.

필드	예
유형	문자
이름	YOUR_SELECTOR._domainkey
값	v=DKIM1; k=rsa; p=공개키

레코드 이름만 입력할지 YOUR_SELECTOR._domainkey전체 레코드를 입력할지는 YOUR_SELECTOR._domainkey.example.comDNS 제어판에 따라 다릅니다. 일부 제공업체는 자동으로 영역 이름을 추가합니다. 작업: 저장하기 전에 제공업체에서 최종 정규화된 레코드 이름을 미리 확인하여 실수로 잘못된 레코드를 생성하지 않도록 하십시오 ...example.com.example.com.

DNS TXT 레코드 형식에서 _domainkey 아래에 DKIM 선택기가 표시되고 DKIM1 RSA 공개 키 값이 나타납니다. — DKIM 선택기를 게시하고 `_domainkey`Zimbra에서 생성된 전체 공개 키를 붙여넣으세요.

3단계: 발신 도메인에 대한 SPF TXT 레코드를 하나 생성합니다.

SPF는 발신 권한을 설정하려는 도메인에 DNS TXT 레코드로 게시됩니다. RFC 7208은v=spf1 SPF에 TXT 레코드를 요구하며, 동일한 소유자 이름에 여러 개의 SPF 레코드가 있는 경우 영구적인 오류가 발생한다고 명시하고 있습니다. 즉, 메일 서비스를 추가한다는 이유만으로 두 번째 TXT 레코드를 생성하지 마십시오 .

Zimbra 서버가 안정적인 공용 IPv4 주소 하나에서 직접 전송하는 경우, 최소한의 예는 다음과 같습니다.

v=spf1 ip4:203.0.113.10 -all

도메인의 MX 레코드에 참조된 모든 호스트가 정상적인 아웃바운드 발신자인 경우, 일반 MX 레코드를 사용할 수 있습니다 mx. 하지만 타사 서비스에서 SPF 포함 도메인을 게시하는 경우, 별도의 include:메커니즘이 필요할 수 있습니다. 정확한 레코드 형식은 배포 환경에 따라 다르므로, 모든 환경에서 사용 가능한 단일 Zimbra SPF 문자열은 없습니다.

~all흔히 저지르는 또 다른 실수는 '허용'이 '허용하지 않음 '보다 항상 안전하다고 가정하는 것 입니다 -all. 진정한 문제는 승인된 발신자 목록이 완전한지 여부입니다. 목록이 완전 -all하다면 엄격한 접근 방식이 합리적입니다. 조치: 모든 적법한 발신자를 하나의 SPF 레코드에 승인하고, 실제 운영 환경에서 검증한 다음, all해당 증거를 바탕으로 최종 승인 대상을 선택하십시오.

SPF는 가능한 한 단순하게 유지하십시오. RFC 7208은 평가 중에 DNS 조회를 유발하는 메커니즘 및 수정자를 10개로 제한합니다. 이 제한을 초과하면 오류가 발생할 수 있습니다 permerror. 조치: 다른 공급업체를 추가하기 전에 DNS 확장 메커니즘을 포함한 개수를 세십시오.

DNS TXT 레코드 양식에는 루트 도메인에 IP 주소 203.0.113.10 및 -all 옵션이 포함된 SPF 정책이 표시되어 있습니다. — 간단한 직접 전송 설정을 통해 단일 SPF TXT 레코드에서 Zimbra 공용 IP를 인증할 수 있으며, 환경에 필요한 경우에만 다른 합법적인 발신자를 추가할 수 있습니다.

4단계: 먼저 모니터링 모드로 DMARC를 게시합니다.

DMARC 정책은 다음 주소에 게시되어 있습니다 _dmarc.example.com. 신중한 첫 번째 레코드는 다음과 같습니다.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none데이터 수집 중에 수신자가 DMARC 정책에 따라 처리 방식을 변경하지 않도록 요청합니다. 이 rua주소는 집계 보고서를 요청하며, 현재 집계 보고서 형식은 RFC 9990 에 명시되어 있습니다 . 관리되지 않는 개인 사서함 대신 DMARC 보고서를 처리할 수 있는 사서함 또는 보고 서비스를 사용하십시오.

이전 문서의 배포 예시를 맹목적으로 복사하지 마십시오. RFC 9989는 운영 경험상 적용이 일관되지 않은 것으로 나타났기 때문에 역사적인 문서로 간주됩니다 pct=10. 현재 표준은 필요한 경우 동작 테스트에 사용합니다. 조치: 보고서를 작성하고 분석하는 것부터 시작하십시오. 안전 장치로 백분율 샘플링에 의존하지 마십시오.pct=25pctt=yp=none

DNS 양식에서 v=DMARC1, p=none, 집계 보고서 사서함을 가진 _dmarc라는 이름의 TXT 레코드를 생성합니다. — DMARC 모니터링 레코드를 생성하여 `_dmarc`격리 또는 거부를 요청하기 전에 실제 발신 소스를 확인하십시오.

5단계: 공용 DNS에서 세 가지 레코드를 모두 확인합니다.

DNS 제공자가 레코드를 게시한 후에는 권한 있는 서버 외부 또는 공용 DNS를 볼 수 있는 리졸버에서 해당 레코드를 쿼리할 수 있습니다. 예를 들면 다음과 같습니다.

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

SPF의 경우, 해당 소유자 이름으로 시작하는 TXT 응답이 하나만 v=spf1존재하는지 확인하십시오. DKIM의 경우, 선택기가 Zimbra에 현재 저장된 값과 정확히 일치하는지 확인하십시오. DMARC의 경우, 예상되는 이름으로 사용 가능한 DMARC 정책 레코드가 하나만 있는지 확인하십시오.

DNS 전파는 서비스 제공업체, TTL(Time To Live) 및 리졸버 캐시에 따라 달라집니다. 권한 있는 네임서버에 즉시 반영되는 변경 사항이라도 다른 곳에 캐시되어 있을 수 있습니다. 조치: Zimbra의 오래된 응답을 탓하기 전에 최소한 하나의 독립적인 공용 리졸버를 사용하여 테스트하십시오.

터미널에서 dig 명령어를 사용하여 example.com의 SPF, DKIM 선택기 및 DMARC TXT 레코드를 조회합니다. — 독립적인 DNS 조회를 사용하여 공개 레코드가 게시하려는 정책과 일치하는지 확인하십시오.

6단계: 실제 메시지를 전송하고 인증 일치 여부를 확인합니다.

Zimbra 도메인에서 다른 공급자의 사서함으로 메시지를 보내고 전체 메시지 헤더를 검사합니다. 일반적으로 성공적인 결과는 DKIM 서명 및/또는 SPF 통과 결과와 함께 DMARC 통과 결과를 보여줍니다. 이는 적어도 하나의 인증된 ID가 보이는 발신 도메인과 일치하기 때문입니다.

여기서 또 다른 오해가 드러납니다. DMARC는 SPF와 DKIM 모두 통과해야 하는 것이 아닙니다. 정렬된 SPF ID 또는 정렬된 DKIM ID 중 하나만 통과하면 됩니다. RFC 9989는 SPF와 DKIM 모두에 대해 완화된 정렬을 기본값으로 정의하고 있지만 aspf, adkim엄격한 정렬을 요청할 수도 있습니다 s. 조치: 정렬된 DMARC 통과를 제공하는 메커니즘이 정확히 무엇인지 검사 Authentication-Results하고 식별해야 합니다.

example.com에 대한 spf=pass, dkim=pass 및 dmarc=pass를 포함한 인증 결과를 보여주는 원래 메시지 보기 — 실제 외부 전송 테스트에서는 SPF 또는 DKIM 통과뿐만 아니라, 보이는 발신 도메인에 대한 DMARC도 통과해야 합니다.

7단계: 보고서 내용이 모두 정상일 경우에만 모니터링에서 집행 단계로 넘어갑니다.

DMARC 데이터에서 정상적인 발신자가 인증 및 정렬을 올바르게 수행하는 것으로 확인되면 정책을 p=quarantine또는 최종적 으로 변경할 수 있습니다 p=reject. 현재 표준에서 , none, quarantine는 reject도메인 소유자가 인증되지 않은 사용을 평가한 내용을 나타내지만, 수신자는 여전히 로컬에서 처리할 재량권을 가집니다.

DMARC를 전달률 최적화 수단으로 간주하지 마십시오 p=reject. DMARC는 주로 인증 및 도메인 남용 방지용 도구이며, 수신자의 신뢰를 자동으로 보장하거나 수신함 도달을 보장하지 않습니다. 조치: DMARC 적용은 수신함 도달률 향상이라는 명목이 아니라, 인증 범위 확대를 기반으로 한 보안 차원의 결정으로 이루어져야 합니다.

8단계: 기존 DNS 레코드를 즉시 삭제하지 않고 DKIM 키를 교체합니다.

도메인의 DKIM 데이터를 업데이트하려면 Zimbra는 다음 사항을 안내합니다.

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

이 명령은 업데이트된 DKIM 데이터를 생성하고 새 DNS 항목을 생성합니다. Zimbra는 이전 키로 서명된 메시지가 전송 중이거나 대기 중인 동안에도 계속 검증될 수 있도록 이전 TXT 레코드를 일정 기간 동안 DNS에 남겨두는 것을 권장합니다. 조치: 먼저 새 선택기를 게시하고 검증한 다음, 이전 선택기를 일시적으로 유지한 후 제거하십시오.

Zimbra 터미널에서 zmdkimkeyutil -u -d example.com 명령어를 실행하고 새 선택기와 이전 선택기를 임시로 유지해야 함을 나타내는 표를 지정합니다. — DKIM 키 교체 시에는 새 키를 게시하고 이전 선택자를 일시적으로 유지하여 이전 서명된 메일도 계속 유효성을 검사할 수 있도록 합니다.

간편 참고: 각 기록이 증명하는 내용

제어	무엇을 확인하는가	설정하는 곳	주요 실패 원인 회피
SPF	송신 호스트가 SMTP ID에 대한 권한을 가지고 있는지 여부	공개 DNS TXT 레코드	여러 개의 SPF 레코드 또는 누락된 제3자 발송인
DKIM	메시지가 서명 도메인에 대한 유효한 서명을 포함하는지 여부	Zimbra 키 생성 및 공개 DNS TXT 키	잘못된 선택자이거나 공개 키가 잘렸습니다.
DMARC	SPF 또는 DKIM이 통과하고 발신 도메인과 일치하는지 여부	공개 DNS TXT 레코드는 다음과 같습니다.`_dmarc`	합법적인 발신자가 일치하기 전에 강제 시행

짐브라 관련해서 꼭 확인해야 할 사항들

Zimbra의 이메일 보호 지침에 따르면 DKIM은 도메인별로 생성하여 각 도메인의 공용 DNS에 게시해야 합니다. 또한 이전 구성에서 특정 페르소나 또는 자동 응답기 동작과 관련하여 발생할 수 있는 정렬 문제에 대해서도 설명합니다. 이러한 세부 사항은 보편적인 것이 아니라 상황에 따라 다릅니다. 배포 환경에서 별칭, 페르소나, 릴레이 또는 특이한 봉투-발신 재작성을 사용하는 경우 해당 메시지 경로를 별도로 테스트해야 합니다.

다중 도메인 Zimbra 설치의 경우, 각 송신 도메인에 대해 DKIM 설정 및 DNS 게시를 반복해야 합니다. SPF 및 DMARC 또한 도메인 정책이므로, 호스팅된 도메인 중 하나에 대한 레코드가 관련 없는 다른 도메인에 자동으로 적용된다고 가정해서는 안 됩니다. 조치: 엄격한 DMARC 적용을 활성화하기 전에 모든 도메인과 모든 아웃바운드 경로에 대한 간단한 테스트 매트릭스를 구축하십시오.

최종 검증 체크리스트

v=spf1각 송신 도메인에는 로 시작하는 SPF 레코드가 정확히 하나씩 있습니다 .
SPF 레코드에는 승인된 모든 아웃바운드 경로가 포함되며 SPF DNS 처리 제한 내에 유지됩니다.
Zimbra는 해당 도메인에 대해 저장된 선택자를 사용하여 발신 메일에 서명합니다.
일치하는 DKIM 공개 키는 공개 DNS에서 확인할 수 있습니다 selector._domainkey.
DMARC TXT 레코드는 _dmarc.domain현재 구문을 사용하여 게시됩니다.
외부 테스트 메시지는 SPF 또는 DKIM 통과를 보여주므로 DMARC 통과도 확인되었습니다.
종합 보고서는 모니터링 단계에서 격리 또는 거부 단계로 넘어가기 전에 검토됩니다.
기존 DKIM 선택기는 전환 기간 동안 일시적으로 유지되며 전환 기간이 종료된 후에만 제거됩니다.

이러한 검사를 통과하면 Zimbra 서버는 단순히 세 개의 DNS 레코드를 게시하는 것이 아니라 원격 수신자가 검증할 수 있는 일관된 인증 체인을 제공하는 것입니다. 이는 가이드에서 예시 문자열 하나를 복사하는 것보다 훨씬 중요한데, 올바른 SPF 소스, DKIM 선택기 및 DMARC 적용 시점은 메일이 실제로 조직을 떠나는 방식에 따라 달라지기 때문입니다.