SPF·DKIM은 PASS인데 DMARC는 FAIL? 발신 도메인 정렬 확인하기

FAIL 메일 한 통에서 도메인 세 개를 찾습니다

가온상사는 외부 서비스에서 news@example.com 주소로 뉴스레터를 보냅니다. 다음은 수신 서버가 기록한 결과의 가상 예시입니다. 설명에 필요한 부분만 남기고 서명의 긴 값은 생략했습니다.

From: 가온상사 소식 <news@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=mailer.example.net; s=send; ...

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

먼저 From에서 @ 뒤의 도메인을 적습니다. 이것이 DMARC가 보호하려는 주소의 기준입니다. 그다음 SPF 결과의 smtp.mailfrom과 DKIM 결과의 header.d를 나란히 놓습니다.

MAIL FROM은 서버 간 전송에서 사용하는 반송 주소입니다. 받은 메일에서는 보통 Return-Path로 확인할 수 있지만, SPF 검사에 실제 사용한 값은 수신 측 인증 결과와 함께 봅니다. 회신을 받을 Reply-To나 보낸 사람의 표시 이름을 비교하는 검사는 아닙니다. SPF의 MAIL FROM 검사 ↗

원본은 어디서 열고, 어떤 결과를 믿어야 하나요?

웹 Gmail에서는 받은 메일을 열고 답장 옆 더보기 메뉴에서 원본 보기를 선택합니다. 다른 메일 앱에서는 메시지 원본이나 인터넷 헤더를 보여 주는 메뉴를 찾습니다. 보낸편지함의 사본보다 실제로 받은 곳의 원본이 필요합니다. Gmail에서 전체 헤더 확인하기 ↗

원본에 Authentication-Results가 여러 개 있으면 맨 위나 PASS인 줄을 임의로 고르면 안 됩니다. 발신자도 같은 이름의 헤더를 넣을 수 있습니다. 결과 앞의 서버 이름은 단서일 뿐, 그 이름이 적혀 있다는 이유만으로 신뢰할 수는 없습니다. 수신 서비스가 신뢰하는 경계 안에서 기록한 결과를 기준으로 판단해야 합니다. 어느 줄인지 불분명하면 수신 측 관리자에게 원본과 발송 시각을 전달해 확인합니다. 인증 결과 헤더의 위조와 신뢰 경계 ↗

인증 결과가 아예 없거나 반송돼 받은 원본을 구할 수 없다면, FAIL이라고 추측하지 마세요. 발송 서비스의 전송 로그와 반송 메시지를 모아 수신 측 검사 결과를 요청하는 것이 먼저입니다.

인증 통과와 도메인 정렬을 한 경로 안에서 봅니다

가온상사 메일의 SPF PASS는 “지금 접속한 서버가 mailer.example.net의 허용 목록에 있다”는 뜻입니다. DKIM PASS는 “mailer.example.net의 서명이 유효하다”는 뜻입니다. 둘 다 회사의 example.com에 대한 증명은 아닙니다.

DMARC는 인증에 성공한 도메인을 From과 비교합니다. 둘의 관계가 정해진 기준에 맞는 것을 정렬, alignment라고 부릅니다. 통과 조건은 아래 두 경로 중 하나를 끝까지 만족하는 것입니다. DMARC의 도메인 정렬 규칙 ↗

예를 들어 서비스 도메인의 SPF만 PASS이고 회사 도메인의 DKIM은 FAIL이라면, SPF의 PASS와 DKIM의 회사 이름을 합쳐 통과시킬 수 없습니다. d=example.com이라는 글자가 헤더에 있는 것만으로도 부족합니다. 그 서명의 검증 결과가 PASS여야 합니다.

DKIM 서명이 여러 개라면 하나씩 짝을 맞춥니다

외부 서비스는 자기 도메인 서명과 고객 회사 도메인 서명을 함께 붙이기도 합니다. 서명마다 d=, 키를 찾는 이름인 s=, 검증 결과를 묶어 보세요. 회사와 정렬되는 유효한 서명이 하나 있으면 DKIM 경로로 DMARC를 통과할 수 있습니다. 여러 DKIM 서명과 서명 도메인 ↗

첫 번째 줄이 흔한 함정입니다. PASS인 서명과 회사 도메인 서명이 서로 다릅니다. 도구가 여러 서명을 한 결과로 요약했다면 세부 결과나 전체 헤더를 요청하세요.

r과 s는 어디까지 같은 도메인으로 볼지 정합니다

반송 주소에 bounce.example.com처럼 하위 도메인을 쓰는 회사도 있습니다. From이 example.com일 때 이를 같은 범위로 볼지 정하는 값이 aspf와 adkim입니다.

aspf는 SPF, adkim은 DKIM의 정렬 모드입니다. 기본값 r은 같은 조직 도메인에 속하면 허용하는 완화 모드이고, s는 도메인이 완전히 같아야 하는 엄격 모드입니다. 주소 전체를 비교하는 것은 아니므로 news@와 bounce@처럼 @ 앞의 이름이 다르다고 정렬이 실패하지는 않습니다. Microsoft의 정렬 모드 설명 ↗

마지막 주소는 앞부분에 회사 도메인이 들어 있지만 example.com의 하위 도메인이 아닙니다. 글자가 닮은 examp1e.com도 별개의 도메인입니다. 완화 모드는 비슷한 이름을 허용하는 설정이 아닙니다.

조직 도메인을 “마지막 두 단어”로 잘라 판단하는 것도 정확하지 않습니다. co.uk처럼 공용 접미사가 여러 단계인 경우가 있고, 현행 표준에는 DNS를 따라 조직 경계를 찾는 절차가 있습니다. 복잡한 하위 도메인 구조라면 수신 서비스의 실제 결과와 적용된 정책을 함께 확인합니다. 조직 도메인과 DNS 정책 탐색 ↗

여러 발송 서비스가 회사 하위 도메인을 사용하는 환경이라면 adkim=r; aspf=r부터 설계하는 것이 실용적입니다. s는 완전 일치를 요구할 이유가 있고, 필요한 발송 경로를 그 조건에 맞출 수 있을 때 선택합니다. 기존 s를 바꾸기 전에는 왜 엄격 모드를 골랐는지 확인하세요. 가온상사처럼 아예 다른 조직 도메인으로 인증된 메일은 r로 바꿔도 해결되지 않습니다.

가온상사는 회사 도메인 DKIM을 설정해 해결합니다

이제 수정할 곳을 고를 차례입니다. 가온상사의 뉴스레터 서비스가 회사 도메인으로 서명하는 custom DKIM을 지원한다고 가정하겠습니다. 서비스의 반송 주소는 그대로 두고, 회사 도메인의 유효한 서명을 추가하는 방법입니다.

1. 뉴스레터 서비스에서 보낼 도메인을 선택합니다

   실제 뉴스레터 서비스의 도메인 인증 설정에서 example.com을 등록합니다. 직원용 Google Workspace나 Microsoft 365의 DKIM을 켜는 것만으로 외부 뉴스레터까지 서명되지는 않습니다.

2. 그 서비스가 발급한 DNS 항목을 복사합니다

   레코드 이름, TXT 또는 CNAME이라는 종류, 값 또는 대상 주소를 한 묶음으로 등록합니다. 여러 항목을 요구하면 모두 추가합니다. 다른 회사의 공개키나 CNAME 대상을 조합하지 않습니다.

3. DNS 확인 후 실제 서명을 활성화합니다

   DNS 제공자가 도메인을 자동으로 붙여 이름이 중복되지 않는지 확인합니다. 서비스의 검증을 마친 뒤 서명을 활성화합니다. ‘도메인 소유 확인’만 끝낸 상태인지, 실제 캠페인에도 회사 DKIM이 적용됐는지 구분합니다.

4. 같은 캠페인 경로에서 새 테스트 메일을 보냅니다

   발신 주소를 news@example.com으로 두고 외부 테스트 수신함에 보냅니다. 관리 화면의 완료 표시와 별개로, 받은 원본에서 회사 도메인의 DKIM PASS가 실제로 나타나는지 확인합니다.

예를 들어 서명에 d=example.com; s=nl2026이 붙었다면 공개키 조회 이름은 nl2026._domainkey.example.com입니다. 이 이름은 확인할 위치를 설명한 예시입니다. 실제 selector와 DNS 값은 서비스가 발급한 것을 사용해야 합니다. TXT에 공개키를 직접 두는 서비스도, CNAME으로 서비스의 키를 가리키는 서비스도 있습니다. DKIM 공개키 조회 이름 ↗

Google Workspace도 DNS 등록 뒤 인증 시작과 수신 메일 검증을 별도로 안내합니다. 키가 존재하는지와 실제로 서명되는지를 모두 확인해야 합니다. Google의 DKIM 활성화·검증 절차 ↗

From: 가온상사 소식 <news@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=example.com; s=nl2026; ...

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=example.com header.s=nl2026;
  dmarc=pass header.from=example.com

수정 전과 비교하면 MAIL FROM은 여전히 mailer.example.net입니다. SPF 경로의 정렬 문제는 그대로지만, DKIM PASS인 example.com이 From과 일치하므로 DMARC는 통과합니다. 이 예시는 결과를 간단히 보여 주기 위해 회사 서명만 적었습니다. 실제로 서비스 자체 서명이 함께 남아 있어도 회사 서명의 결과를 확인하면 됩니다.

SPF 경로로 맞추려면 custom MAIL FROM이 필요합니다

서비스가 지원한다면 반송 주소를 bounce.example.com 같은 회사 하위 도메인으로 바꿀 수도 있습니다. 서비스 화면에서 custom MAIL FROM을 지정하고 발급된 DNS 값을 복사합니다. Amazon SES는 이 반송 도메인에 SPF와 MX를 요구합니다. 서비스별 요구값을 확인하고 회사 메일의 MX를 임의로 대신 넣지 않습니다. Amazon SES의 custom MAIL FROM 설정 ↗

이후 smtp.mailfrom=bounce.example.com으로 SPF가 PASS인지 확인합니다. From이 example.com이면 aspf=r에서는 정렬되고 aspf=s에서는 정렬되지 않습니다. 외부 발송 서비스의 정렬 수정 방법 ↗

두 방법을 모두 지원하지 않는다면 지원팀에 회사의 인증된 경로로 보낼 수 있는지 확인하고, 필요하면 서비스 변경을 검토합니다. From만 회사 하위 도메인으로 바꾸는 것으로는 외부 서비스 도메인과의 불일치가 사라지지 않습니다.

직접 받을 때만 통과한다면 전달 구간을 비교합니다

가온상사의 새 메일이 거래처의 자동 전달 주소를 거칠 때만 실패한다면, 중간 서버를 지나며 무엇이 달라졌는지를 확인합니다. 여기서는 원래 From을 유지하는 자동 전달을 말합니다.

전달 서버가 원래 MAIL FROM을 유지하면, 최종 수신 서버는 원래 도메인의 SPF로 전달 서버의 IP를 검사합니다. 그 IP가 허용되지 않았다면 SPF가 실패할 수 있습니다. 반면 회사 DKIM 서명이 그대로 유효하면 DKIM 경로로 DMARC를 통과할 수 있습니다. 메일 전달이 인증에 미치는 영향 ↗

SRS는 SPF를 도와도 회사와의 정렬을 보장하지 않습니다

일부 전달 서비스는 SRS라는 방식으로 MAIL FROM을 전달 서비스의 주소로 다시 씁니다. 이 경우 SPF가 PASS로 바뀔 수 있지만, 예를 들어 반송 도메인이 forwarder.example.net이고 From은 example.com이면 정렬되지 않습니다. SRS가 성공했다는 사실과 DMARC가 통과했다는 사실을 구분해야 합니다. Microsoft도 SRS만으로 DMARC 문제가 해결되지는 않는다고 안내합니다. Microsoft의 SRS와 DMARC 설명 ↗

메일링 리스트나 보안 장비가 서명된 제목을 바꾸거나 본문에 안내문을 붙이면 DKIM까지 실패할 수 있습니다. “회사 서명 도메인은 맞는데 DKIM이 통과하지 못함”과 “서명은 PASS인데 도메인이 다름”은 다른 문제입니다. 앞의 경우에는 키 조회와 서명 후 변경을, 뒤의 경우에는 발송 도메인 구성을 조사합니다. 변경 전후 원본과 검증 오류를 함께 봐야 원인을 좁힐 수 있습니다. 메일 내용 변경과 DKIM ↗

ARC는 중간 서버가 확인했던 인증 결과를 서명된 연결 정보로 전달하는 기술입니다. 최종 수신 서버는 ARC 검증 결과와 해당 중간 서버에 대한 신뢰를 바탕으로 처리에 참고할 수 있습니다. ARC가 유효하다고 DMARC를 강제로 PASS로 만드는 것은 아닙니다. DMARC FAIL인 메일을 수신 측 판단으로 허용하는 경우와 원래 인증이 통과한 경우를 구분해야 합니다. ARC 프로토콜의 목적과 처리 방식 ↗

따라서 전달 주소에서만 문제가 나면 직접 받은 사본과 전달된 사본을 한 쌍으로 확보합니다. 발신 IP, MAIL FROM, 회사 DKIM의 결과가 어느 구간에서 달라졌는지 확인한 뒤 전달 관리자와 서명 보존·SRS·ARC 지원을 점검합니다. 원래 회사의 SPF에 외부 전달 서버를 무작정 추가하는 것은 출발점이 아닙니다.

새 메일로 확인하고, 남은 오류는 원인별로 좁힙니다

DNS를 수정해도 어제 받은 메일에 적힌 FAIL은 바뀌지 않습니다. 그것은 당시 수신 서버가 기록한 결과입니다. DNS 조회와 서비스의 설정 확인이 끝난 뒤 문제였던 발송 경로에서 새 메일을 보내야 변경 효과를 알 수 있습니다.

같은 뉴스레터 서비스, 같은 From, 같은 종류의 캠페인으로 다시 보내 회사 DKIM과 DMARC의 PASS를 확인합니다. 자동 전달 경로도 별도로 검사합니다. 직원이 Gmail에서 직접 보낸 메일의 성공으로 뉴스레터 수정까지 검증한 것은 아닙니다.

permerror는 SPF 정책을 정상적으로 해석·평가할 수 없는 오류, temperror는 DNS 문제 같은 일시적 오류를 뜻합니다. 도메인 문자열이 맞아도 이런 결과는 SPF PASS가 아닙니다. 오류를 모두 정렬 문제로 묶지 말고, 검사 도구가 제시한 구체적 사유부터 확인합니다. SPF 결과 값의 의미 ↗

반대로 회사 도메인의 유효한 정렬 경로가 보이는데 DMARC만 실패했다면 원본 해석부터 다시 확인합니다. 다른 서버의 검사 결과를 섞어 읽었거나, 생각한 것과 다른 하위 도메인 정책이 적용됐을 수 있습니다. 이 단계에서는 DNS 값을 더 추가하기보다 수신 측 관리자에게 어떤 From과 정책으로 평가했는지 확인하는 편이 빠릅니다.

실제 캠페인 뒤에는 RUA에서 같은 발신처의 인증 결과가 개선되는지도 살펴봅니다. 다만 RUA는 집계이므로 특정 한 통의 오류는 원본과 전송 로그로 조사합니다. DMARC 집계 리포트 표준 ↗ 인증을 통과해도 스팸 분류나 반송이 남을 수 있으므로 수신 측 처리 사유는 따로 확인합니다.

실패 메일의 처리 정책을 p=none으로 바꾸거나 수신함의 허용 목록에 넣었다고 정렬 원인이 수정되지는 않습니다. 가온상사 사례처럼 어떤 인증 도메인이 바뀌었고, 새 메일에서 어느 경로로 통과했는지 확인할 수 있어야 수정 완료입니다.