DMARC 설정 방법 DNS 레코드 등록부터 인증 확인까지

설정 전에 회사 메일이 나가는 길부터 확인합니다

DMARC는 회사가 DNS에 공개하는 인증 정책입니다. DNS는 도메인 정보를 조회하는 인터넷 주소록이고, 수신 서버는 그곳에서 정책을 읽습니다. Google Workspace를 쓰더라도 실제 설정은 DNS 운영 업체의 관리 화면에서 합니다.

먼저 담당자에게 현재 네임서버와 DNS 운영 업체를 확인합니다. 도메인을 구입한 업체와 다를 수 있습니다. 가온상사도 DNS를 별도 서비스로 이전해 두었습니다. 예전 관리 화면에 값을 넣으면 저장은 되어도 인터넷에서 조회되지 않을 수 있습니다.

메일 서비스 이름보다 실제 From 주소가 중요합니다

다음으로 회사 주소를 사용하는 발신처를 적습니다. 직원 계정만 확인하고 끝내면 홈페이지 알림이나 청구 시스템을 놓치기 쉽습니다. 가온상사는 각 부서에 최근 발송 메일 한 통과 서비스 관리자를 요청했습니다.

세 경로의 From 도메인은 같아도 발송 서버와 서명 설정은 다릅니다. 직원 메일 한 통의 인증 성공으로 나머지를 대신 확인할 수 없습니다. news.example.com 같은 하위 도메인으로 보내는 서비스도 따로 적습니다.

SPF·DKIM을 먼저 보는 이유

SPF는 전송에 쓰는 주소인 MAIL FROM의 도메인을, DKIM은 전자서명에 적힌 d= 도메인을 인증합니다. DMARC는 그중 통과한 인증의 도메인이 화면에 보이는 From과 맞는지 확인합니다. 이 관계가 도메인 정렬입니다. SPF 또는 DKIM 한 경로에서 통과와 정렬을 함께 만족하면 DMARC는 통과합니다.

가능한 발신 경로에는 SPF와 DKIM을 모두 설정해 두는 편이 좋습니다. 외부 서비스에는 특히 “우리 도메인으로 서명하는 기능이 켜져 있는지”를 확인하세요. 서비스 자체 도메인의 인증만 통과하면 부족할 수 있습니다. Microsoft의 DMARC 구성·정렬 설명 ↗

처음 등록할 때는 이 한 줄로 관찰을 시작합니다

아직 DMARC 레코드가 없는 가온상사는 먼저 집계 보고서로 정상 메일의 문제를 찾기로 했습니다. 아래의 p=none은 DMARC 실패를 이유로 격리나 거부를 요청하지 않는 값입니다. 모든 메일을 받아 달라는 허용 설정은 아닙니다.

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
TTL: DNS 제공업체 기본값 또는 회사 운영 기준

여기서 rua는 집계 보고서를 받을 주소입니다. 가온상사는 IT 담당자가 확인할 전용 편지함을 먼저 만들었습니다. 주소를 DNS에 적는다고 편지함이 자동으로 생기지는 않습니다.

1. 권한이 있는 DNS 관리 화면에서 example.com을 엽니다

   기존 _dmarc 레코드를 확인하고 변경 전 값을 보관합니다.

2. 새 레코드의 유형을 TXT로 선택합니다

   이름 또는 호스트 칸에는 제공업체 방식에 맞춰 _dmarc를 입력합니다. 최종 이름이 _dmarc.example.com이 되는지 미리보기나 저장 목록에서 확인합니다.

3. 값 칸에 v=DMARC1로 시작하는 문자열을 넣습니다

   Type, Name, Value 같은 항목 이름은 값에 포함하지 않습니다. 세미콜론으로 구분한 정책 문자열만 넣고, RUA 주소의 오타와 mailto: 접두사를 확인합니다.

4. 저장한 뒤 외부 DNS 조회로 다시 확인합니다

   TTL은 DNS 응답이 캐시에 남을 수 있는 시간입니다. 저장 버튼을 눌렀다고 모든 수신 서버가 즉시 새 값을 읽는 것은 아닙니다.

이름 칸은 특히 자주 틀립니다. 도메인 이름을 자동으로 붙이는 화면에 _dmarc.example.com 전체를 넣으면 _dmarc.example.com.example.com으로 저장될 수 있습니다. 반대로 전체 이름을 요구하는 업체도 있습니다. 입력 칸의 모양보다 저장된 최종 DNS 이름을 기준으로 확인하세요. Google의 DMARC DNS 등록 안내 ↗

또한 DMARC는 별도의 TXT 레코드입니다. 기존 v=spf1 값 뒤에 이어 붙이거나 DKIM 공개키를 지우고 넣지 않습니다. 이 세 설정은 이름과 역할이 서로 다릅니다.

각 항목은 무엇을 정하고, 언제 바꿔야 할까요?

기본 정책, 보고서 수신처, 정렬 방식을 이해한 뒤 필요한 옵션을 추가하면 됩니다. 아래의 시작값은 새로 도입해 발신처를 점검하는 회사를 기준으로 합니다.

r에서 s로 바꾸는 일이 항상 더 좋은 설정은 아닙니다

From이 example.com이고 정상 서비스의 DKIM 서명이 d=mail.example.com이라면, 같은 조직 도메인에 속하므로 완화 정렬인 r에서는 맞는 것으로 볼 수 있습니다. s는 완전히 같은 도메인을 요구하므로 이 DKIM 경로는 정렬되지 않습니다. 비슷하게 생긴 별도 도메인을 r이 허용한다는 뜻은 아닙니다.

하위 도메인 권한을 외부 조직에 맡기는 등의 이유로 엄격한 경계가 필요하면 s를 검토할 수 있습니다. 변경 후에도 각 정상 메일에 통과 가능한 인증 경로가 남는지 먼저 확인하세요.

sp와 np를 생략해도 하위 도메인이 무조건 제외되지는 않습니다

조직 도메인인 example.com의 정책을 따르는 하위 도메인은 별도 지정이 없으면 p의 영향을 받습니다. 자체 DMARC가 없는 news.example.com의 발신도 상위 정책을 바꾸기 전에 확인해야 합니다. 다만 From이 news.example.com이고 _dmarc.news.example.com에서 유효한 자체 정책을 찾으면 그 정책이 우선 적용됩니다. 반면 SPF 허용 목록은 상위 도메인에서 자동 상속되지 않습니다.

np의 “존재하지 않음”은 DNS 기준입니다. 웹사이트로만 쓰는 shop.example.com이 DNS에 존재한다면, 메일을 보내지 않는다는 이유로 np 대상이 되지는 않습니다. np가 없을 때는 적용 가능한 sp, 그것도 없으면 p를 따릅니다.

ruf와 fo는 RUA와 다릅니다. fo=0은 정렬된 인증 통과 경로가 모두 없을 때, fo=1은 한 경로라도 정렬된 통과를 만들지 못했을 때 개별 실패 보고서를 요청합니다. 기본값은 0이며 ruf가 없으면 쓰이지 않습니다. 메일별 정보가 포함될 수 있고 수신자 지원도 제한적이므로, 처음에는 RUA 운영부터 갖춥니다. DMARC 표준의 항목 정의 ↗

보고서를 받을 주소와 읽을 담당자를 함께 정합니다

RUA는 수신 측이 관찰한 발신 서버, 건수, 인증 결과를 모아 보내는 집계 보고서입니다. XML 파일이며 압축 첨부로 도착할 수도 있습니다. 문의 메일처럼 한 통씩 읽기보다는 분석 도구에서 발신처별로 묶어 보는 방식이 알맞습니다.

가온상사는 전용 편지함에 외부 메일과 첨부파일이 들어오는지 확인하고, IT 담당자가 매주 발신처 목록과 대조하도록 정했습니다. 그룹 주소를 쓴다면 외부 발신자의 메일을 차단하는 설정이 없는지도 확인합니다. 보고서 보관만 하고 아무도 보지 않는다면 p=none을 다음 단계로 바꿀 근거가 쌓이지 않습니다. Google의 보고서 수신·분석 안내 ↗

외부 분석 서비스를 쓸 때는 받는 곳의 동의가 필요합니다

회사 도메인과 다른 조직의 주소로 RUA를 보내도록 설정하면 보고서를 받을 곳의 DNS 동의가 필요합니다. 아무 주소나 써서 다른 회사의 편지함에 대량의 보고서가 몰리게 하는 일을 막기 위한 절차입니다.

회사: example.com
RUA 주소: aggregate@reports.example.net

회사 DNS의 _dmarc.example.com 값에 포함:
rua=mailto:aggregate@reports.example.net

보고서를 받는 업체의 DNS에 공개할 TXT 이름:
example.com._report._dmarc.reports.example.net
TXT 값: v=DMARC1

위의 긴 이름은 보고서를 받는 reports.example.net 운영자가 관리하는 DNS에 있습니다. 회사 DNS에 같은 문자열을 그대로 추가하는 작업이 아닙니다. 업체가 고객 도메인별로 등록하거나 여러 도메인에 대한 동의를 처리할 수 있으므로, 가입 후 발급되는 RUA 값과 연결 상태를 확인하세요. 외부 보고서 수신처의 검증 절차 ↗

보고서는 실시간으로 오지 않습니다. 흔히 하루 단위로 집계하지만 생성·배송 시점은 수신 서비스에 따라 다르고, 보고서를 보내지 않는 곳도 있습니다. 등록 직후 메일함이 비어 있다는 이유만으로 실패라고 판단하지 마세요. 충분히 기다려도 오지 않으면 주소 오타, 외부 메일 수신, 외부 수신 동의, 해당 기간의 실제 발송 여부를 순서대로 확인합니다.

DNS 조회와 새 메일의 인증 결과를 나누어 확인합니다

DNS 조회 도구의 초록색 표시는 주로 “정책을 찾을 수 있다”는 뜻입니다. 실제 메일이 인증 조건을 만족하는지는 따로 봐야 합니다.

1. 저장한 이름에서 하나의 정책이 조회되는지 봅니다

# macOS / Linux
dig +short TXT _dmarc.example.com

# Windows 등 nslookup 사용 환경
nslookup -type=TXT _dmarc.example.com

# 기대하는 TXT 값의 예
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

결과에서 이름과 정책, 보고서 주소를 읽어 봅니다. 아무 값도 없으면 _dmarc 철자, 도메인 자동 추가, 실제 DNS 관리 위치를 먼저 확인합니다. 값이 다르면 캐시와 변경 이력을 비교합니다. 조회 결과가 비어 있을 때마다 레코드를 다시 추가하면 중복 문제가 생길 수 있습니다.

v=DMARC1으로 시작하는 별개의 TXT 레코드가 두 개라면 하나로 정리해야 합니다. 여러 정책을 나란히 두고 수신자가 골라 쓰게 할 수는 없습니다. 다만 하나의 TXT 값이 "v=DMARC1; p=none; " "rua=mailto:…"처럼 여러 문자열 조각으로 표시되는 것은 다릅니다. 따옴표 개수만 세지 말고 DNS 관리 화면에서 실제 레코드 수와 이어 붙인 값을 확인하세요.

2. 실제 발신 서비스에서 새 메일을 보냅니다

가온상사는 직원 메일과 뉴스레터에서 외부 수신함으로 테스트 메일을 보냈습니다. Gmail의 원본 보기처럼 수신 서비스가 제공하는 화면에서 헤더를 열고, 그 수신 서버가 기록한 인증 결과를 봅니다. 메일 본문에 적힌 PASS 문구는 근거가 아닙니다.

직원 메일은 통과했지만 뉴스레터에서 아래 결과가 나왔다고 해 보겠습니다. 다음 헤더는 설명용으로 필요한 부분만 만든 가상 예시입니다.

From: Gaon News <news@example.com>
Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=bounce.mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

인증이 통과한 도메인은 둘 다 발송 업체의 example.net에 속합니다. From의 example.com과 다르므로 DMARC가 실패합니다. 가온상사는 허용 IP를 더 넣기 전에 뉴스레터 서비스의 회사 도메인 인증과 DKIM 서명 설정을 확인했습니다.

서비스 관리 화면에서 example.com을 발신 도메인으로 등록하고, 그 서비스가 발급한 TXT 또는 CNAME을 회사 DNS에 넣습니다. DNS 확인을 통과한 뒤 실제 서명이 활성화됐는지도 봅니다. 이름과 값은 서비스마다 다르므로 임의의 DKIM 레코드로 대신하지 않습니다. 그런 다음 같은 뉴스레터 경로에서 새 메일을 다시 보냅니다.

From: Gaon News <news@example.com>
Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=bounce.mailer.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

SPF 도메인은 그대로지만 DKIM이 회사 도메인으로 통과했습니다. 그래서 DMARC도 통과합니다. 이 결과는 p=none을 바꿔 얻은 것이 아니라 발신 서비스의 인증 구성을 바로잡아 얻은 것입니다. DKIM 자체가 실패한다면 정렬을 논하기 전에 DNS 공개키와 서명 활성화부터 점검해야 합니다. Google의 인증·정렬 문제 해결 안내 ↗

3. 보고서에서 수정 이후의 발송을 확인합니다

다음 보고서가 오면 집계 기간을 먼저 봅니다. 설정을 바꾸기 전 실패가 섞여 있다고 수정이 실패한 것은 아닙니다. 가온상사는 뉴스레터 담당자가 확인한 발송 시간과 서비스 정보를 대조해 수정 이후 메일의 결과를 살폈습니다. 낯선 발신 IP가 보이면 바로 주소 도용으로 분류하지 않고 누락된 서비스인지 먼저 조사합니다.

RUA는 보고를 제공한 수신자의 관찰 범위입니다. 보고서에 서비스가 안 나온다고 그 서비스가 없다고 단정할 수 없고, 인증 통과 건수가 곧 받은편지함 도착 건수인 것도 아닙니다. 실제 수신 테스트와 발송 서비스의 반송 기록을 함께 보아야 합니다. 집계 보고서의 기간과 관찰 정보 ↗

정책을 강화할 시점은 날짜보다 확인한 메일로 정합니다

가온상사는 직원 메일과 뉴스레터의 통과를 확인했지만 바로 reject로 바꾸지는 않았습니다. 아직 월말 청구서를 실제 경로에서 확인하지 않았기 때문입니다. 뉴스레터 수천 통의 통과보다 청구서 몇 통의 실패가 사업에 더 큰 영향을 줄 수 있습니다.

정책을 강화하기 전에는 발신처 목록의 각 행에 근거를 붙여 보세요. 누가 관리하는지, 어느 From으로 보냈는지, 통과한 정렬 경로가 무엇인지, 언제 새 메일로 확인했는지가 있어야 합니다. 비밀번호 재설정이나 고객지원 답장처럼 중요한 자동 메일, 드문 정기 발송, 전달을 거치는 실제 업무 경로도 포함합니다. 해결하지 못한 정상 발신처의 실패가 남아 있다면 그 원인을 먼저 처리합니다.

이 근거를 갖춘 뒤 실패 메일을 의심 메일로 처리하도록 요청하는 p=quarantine, 이후 수신 거부를 요청하는 p=reject를 검토합니다. 수신 서버는 자체 보안 정책과 함께 최종 처리하므로 결과도 계속 확인해야 합니다. “일주일이 지났으니 변경”처럼 기간만으로 결정하지 않는 것이 핵심입니다. Google의 단계적 DMARC 도입 안내 ↗

가온상사는 이 과정에서 뉴스레터의 빠진 서명을 찾아 고쳤고, 월말 청구서도 검증 대상에 넣었습니다. 회사에서도 발신 서비스 추가·교체 때 같은 확인 절차를 거치도록 남겨 두세요. 담당자가 바뀌어도 정책을 이어서 운영할 수 있습니다.