DMARC 레코드란?

2026년 11월 4일

DMARC 레코드는 도메인의 DNS 설정에 추가하는 짧은 텍스트 한 줄입니다. 도메인에서 보냈다고 주장하지만 보안 검사에 실패한 이메일을 어떻게 처리할지 다른 메일 서버에 알려 줍니다. 또한 도메인 이름으로 발송되어 그 서버들이 받은 이메일에 대한 보고서를 어디로 보낼지도 알려 줍니다.

한 문장으로 말하면: DMARC는 “내 도메인에서 보냈다고 하는 이메일이 실제로 내가 보낸 것이 아니라면, 스팸함에 넣거나 차단하고, 나에게 보고서를 보내 주십시오”라고 말하는 공개 규칙입니다.

예시로 보는 DMARC

문제

누구나 이메일을 보내면서 From 줄에 다른 사람의 주소를 넣을 수 있습니다. 도메인이 example.com이라고 가정해 보겠습니다. 사기범이 고객에게 다음과 같은 이메일을 보냅니다.

From: billing@example.com
Subject: Your invoice is overdue
Pay here: http://pay-now.example.net

고객은 example.com을 보고 믿습니다. 하지만 이 이메일은 보낸 적이 없는 메일입니다.

이미 있는 두 가지 검사

Gmail이나 Outlook 같은 메일 서비스 제공업체는 모든 이메일에 두 가지 검사를 이미 실행할 수 있습니다.

SPF: 이 이메일은 example.com이 메일 발송을 허용한 서버에서 왔는가?
DKIM: 이 이메일에 example.com의 디지털 서명이 있는가?

이 검사만으로는 빈틈이 있습니다. 사기범은 자기 도메인으로 이 검사를 통과하면서, From 줄에는 여전히 다른 사람의 도메인을 표시할 수 있습니다. 검사 결과와 고객이 보는 주소를 연결하는 것이 없습니다.

DMARC가 추가하는 것

DMARC는 규칙 하나를 추가합니다. SPF 또는 DKIM이 From 줄에 표시된 도메인과 같은 도메인으로 통과해야 한다는 규칙입니다. 이 일치를 정렬(alignment)이라고 합니다. 두 검사 모두 그 도메인으로 통과하지 못하면, 이메일은 DMARC에 실패합니다.

DMARC로는 실패한 이메일을 어떻게 처리할지도 정할 수 있습니다.

DMARC 레코드를 부분별로 보기

example.com의 DNS 설정에 다음 줄을 추가합니다.

v=DMARC1; p=reject; rua=mailto:reports@example.com

각 부분의 뜻은 다음과 같습니다.

v=DMARC1: “이것은 내 DMARC 규칙입니다.”
p=reject: “example.com에서 보냈다고 하지만 검사에 실패한 이메일은 차단해 주십시오.”
rua=mailto:reports@example.com: “내 이름으로 이메일을 보내는 모든 발신자에 대해 매일 보고서를 보내 주십시오.”

가짜 이메일은 어떻게 되는가

사기범이 billing@example.com으로 보낸 이메일이 Gmail에 도착합니다.
Gmail이 SPF와 DKIM을 실행합니다. 두 검사 모두 example.com으로 통과하지 못합니다.
Gmail이 DMARC 레코드를 읽습니다. 레코드에는 p=reject라고 되어 있습니다.
Gmail이 이메일을 차단합니다. 고객은 이 메일을 보지 못합니다.

실제로 보낸 이메일은 같은 검사를 통과하므로 평소처럼 전달됩니다.

p의 세 가지 선택지

설정	DMARC에 실패한 이메일의 처리	사용 시기
p=none	아무 조치도 하지 않습니다. 평소처럼 전달되고, 보고서를 받습니다.	처음, 실제 발신 서비스를 모두 찾는 동안
p=quarantine	스팸함으로 갑니다.	실제 발신 서비스가 모두 통과한 뒤
p=reject	완전히 차단됩니다.	실제 메일이 실패하지 않는다고 확신할 때

대부분의 도메인이 하는 DMARC 설정

p=none으로 시작해 매일 오는 보고서를 읽습니다.
이메일 도구, 고객 지원 도구 등 도메인으로 이메일을 보내는 실제 서비스를 모두 찾습니다. 각 서비스가 검사를 통과하는지 확인합니다.
p=quarantine으로, 그다음 p=reject로 옮깁니다. 이제 정책을 따르는 수신 측에서는 누구도 도메인을 위조할 수 없습니다.

그래서 대부분의 도메인은 감시만 하는 다음과 같은 레코드로 시작합니다.

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

이 가이드의 나머지 부분에서는 DMARC 레코드의 각 부분과 나중에 추가할 수 있는 옵션을 더 자세히 설명합니다.

SPF, DKIM, From 주소를 조금 더 자세히

DMARC는 SPF와 DKIM 위에서 작동합니다. SPF와 DKIM 가이드에서 두 가지를 모두 자세히 다룹니다. 간단히 정리하면 다음과 같습니다.

SPF는 도메인의 이메일을 보낼 수 있는 서버의 목록입니다. 수신 서버는 이메일이 그 목록에 있는 서버에서 왔는지 확인합니다.

DKIM은 각 이메일에 붙이는 디지털 서명입니다. 수신 서버는 DNS에 있는 키로 서명을 확인합니다. 서명이 유효하면, 이메일이 전송 중에 바뀌지 않았고 도메인이 서명했다는 뜻입니다.

From 주소는 수신자가 받은편지함에서 보는 발신자 주소입니다. 예를 들어 hello@example.com입니다. DMARC는 SPF 또는 DKIM이 이와 같은 도메인으로 통과했는지 확인합니다.

DMARC 레코드의 형태

DNS의 어디에 두는가

DNS는 도메인의 공개 설정 목록입니다. DNS 호스트에서 편집하며, DNS 호스트는 보통 도메인을 구입한 회사나 호스팅 업체입니다. DMARC 레코드는 TXT 레코드이며, TXT 레코드는 일반 텍스트를 담는 DNS 항목입니다.

호스트 이름 _dmarc에 추가합니다. 대부분의 DNS 관리 화면은 끝에 도메인을 자동으로 붙이므로, _dmarc는 _dmarc.example.com이 됩니다.

흔한 실수 하나를 주의하십시오. 일부 관리 화면은 _dmarc만 입력하도록 되어 있습니다. 여기에 전체 이름 _dmarc.example.com을 입력하면, 레코드가 _dmarc.example.com.example.com에 만들어집니다. 수신 서버는 그곳에서 레코드를 찾지 못합니다.

작성 규칙

반드시 v=DMARC1으로 시작해야 합니다. 이 부분이 레코드의 맨 앞에 있어야 합니다. DMARC1은 대문자여야 합니다. v=dmarc1으로 쓰거나, 다른 부분을 앞에 두거나, 철자를 틀리면 수신 서버는 레코드 전체를 무시합니다. 그러면 도메인은 DMARC 정책이 없는 것으로 처리됩니다.
각 부분은 세미콜론으로 구분합니다. 세미콜론 앞뒤에 공백이 있어도 됩니다.
정책이 없는 경우. p 부분이 없거나 잘못되었지만, 레코드의 rua에 유효한 보고서 주소가 있다고 가정해 보겠습니다. 이 경우 수신 측은 정책을 p=none으로 처리합니다. p와 rua가 모두 없거나 잘못되었다면, 수신 측은 해당 도메인의 DMARC를 완전히 건너뜁니다.
DMARC 레코드는 하나만 게시합니다. 수신 서버가 v=DMARC1으로 시작하는 TXT 레코드를 두 개 이상 발견하면, 모두 버립니다. 이 규칙은 현재 DMARC 표준인 RFC 9989에 있습니다. 레코드가 두 개라고 정책이 두 개가 되지는 않습니다. 오히려 도메인이 전혀 보호되지 않습니다.

레코드를 확인하는 방법

컴퓨터의 터미널에서 명령어로 레코드를 조회할 수 있습니다.

dig TXT _dmarc.example.com +short
nslookup -type=TXT _dmarc.example.com

Linux와 macOS에서는 dig를 사용합니다. 레코드가 따옴표 안에 한 줄로 출력됩니다. Windows에서는 nslookup을 사용합니다. DNS 서버가 돌려주는 레코드가 표시됩니다.

명령어를 실행해도 아무것도 나오지 않는다면, 둘 중 하나입니다. 레코드가 아직 DNS 전체에 퍼지지 않았거나, 잘못된 호스트 이름에 추가된 것입니다.

DMARC의 모든 태그와 필요한 태그

p=none처럼 DMARC 레코드를 이루는 각 부분을 태그라고 합니다. 2026년 5월에 나온 현재 표준에는 태그가 11개 있습니다.

태그	하는 일(쉽게 설명)	가능한 값	생략하면	필요한가?
v	“이것은 DMARC 레코드입니다”라고 알립니다. 맨 앞에 와야 합니다.	DMARC1	필수	예
p	정책: 실패한 이메일을 어떻게 처리할지 정합니다. 도메인과 하위 도메인에 적용됩니다.	none, quarantine, reject	rua가 유효하면 none으로 처리	예
rua	매일 오는 요약 보고서를 보낼 곳	쉼표로 구분한 하나 이상의 mailto: 주소	보고서를 받지 못함	예
sp	news.example.com처럼 실제로 있는 하위 도메인에 대한 별도 정책	none, quarantine, reject	p와 같음	하위 도메인에 다른 규칙이 필요할 때만
np	DNS에 존재하지 않는 하위 도메인에 대한 정책	none, quarantine, reject	sp와 같음. sp가 없으면 p와 같음	지어낸 하위 도메인을 차단할 때만
adkim	DKIM 도메인이 얼마나 정확히 일치해야 하는지. r = 완화, s = 엄격	r, s	r	거의 필요 없음. 보통은 완화
aspf	SPF 도메인이 얼마나 정확히 일치해야 하는지. r = 완화, s = 엄격	r, s	r	거의 필요 없음. 보통은 완화
t	테스트 모드. 수신 측이 정책을 한 단계 약하게 적용합니다	y, n	n	더 엄격한 정책으로 옮기는 동안만
ruf	실패한 이메일 하나하나에 대한 보고서를 보낼 곳	쉼표로 구분한 하나 이상의 mailto: 주소	보고서를 받지 못함	개인정보 보호 제한 때문에 거의 필요 없음
fo	개별 이메일 보고서의 옵션	0, 1, d, s	0	ruf를 쓸 때만
psd	공개 접미사 도메인(public suffix domain)임을 표시	y, n, u	u	공개 접미사나 DNS 일부를 나누어 주는 대규모 조직만

완화와 엄격은 이렇게 작동합니다. 완화에서는 하위 도메인도 일치로 인정되므로, mail.example.com은 example.com과 일치합니다. 엄격에서는 두 도메인이 정확히 같아야 합니다.

2026년 표준에서는 예전 태그 세 개가 폐지되었습니다. 비율 태그(pct), 보고서 형식 태그(rf), 보고 주기 태그(ri)입니다. 남아 있는 pct=100은 해가 되지 않습니다. 100보다 작은 pct는 정책을 도입하는 동안 이메일의 일부에만 정책을 적용할 때 쓰였습니다. 이제는 새 t 태그가 그 역할을 합니다.

대부분의 도메인에 필요한 것: v, p, rua뿐입니다.

하위 도메인에 다른 규칙이 필요하면 sp나 np를 추가합니다.
psd는 그대로 두십시오. DNS 일부를 나누어 주는 대규모 조직(psd=n)이나 co.uk 같은 공개 접미사(psd=y)를 운영할 때만 필요합니다.
완화 일치(adkim=r, aspf=r)가 기본값이며 거의 모든 도메인에 맞습니다. 정렬 태그는 엄격한 규정 때문에 하위 도메인으로 서명할 수 없는 경우에만 필요합니다.

이 태그로 레코드를 만들거나 예전 레코드를 정리하려면 DMARC 레코드 생성기를 사용할 수 있습니다.

p=none, quarantine, reject가 실제로 하는 일

p 태그는 레코드에서 가장 중요한 부분입니다. DMARC에 실패한 이메일을 어떻게 처리할지 수신 서버에 알려 줍니다. 선택지는 세 가지입니다. 각각이 완전한 보호로 가는 한 단계입니다.

p=none: 감시만 합니다. 수신 측은 실패한 이메일을 특별히 처리하지 않습니다. 평소처럼 전달되며, 일반적인 스팸 필터만 적용됩니다. rua의 보고서와 함께 쓰는 이 설정을 RFC 9989는 Monitoring Mode(모니터링 모드)라고 부릅니다. 전송에 아무 위험 없이, 도메인으로 이메일을 보내는 모든 서비스를 보여 줍니다.

p=quarantine: 스팸함으로 보냅니다. 수신 측은 실패한 이메일을 의심스러운 메일로 처리합니다. 대부분의 메일 서비스 제공업체에서는 수신자의 스팸함으로 갑니다. 이렇게 하면 수신자를 가짜 이메일로부터 보호할 수 있습니다. 설정이 잘못된 도구에서 보낸 실제 이메일도 스팸함에서 찾을 수 있으므로 사라지지 않습니다.

p=reject: 차단합니다. 수신 측은 실패한 이메일을 거부합니다. 대부분은 전송 단계에서 5로 시작하는 영구 오류 코드로 거부합니다. 이메일은 메일함에 도착하지 않습니다. 대신 발송 서버가 반송 메시지를 받습니다.

수신 측이 항상 정책을 따르지는 않습니다

정책은 명령이 아니라 요청입니다. 표준에 따르면 수신 측은 p=reject만을 이유로 이메일을 거부해서는 안 됩니다. 이메일에 대해 아는 것이 그 밖에 없다면, 대신 quarantine으로 처리해야 합니다. 메일 서비스 제공업체는 정책 외에도 자체 발신자 평판 데이터와 스팸 필터를 함께 사용합니다.

reject에 SPF만이 아니라 DKIM이 필요한 이유

전달(포워딩)은 SPF를 깨뜨립니다. 누군가 업무 이메일을 개인 계정으로 전달한다고 가정해 보겠습니다. 전달하는 서버는 자체 IP 주소로 이메일을 보냅니다. 이 주소는 SPF 레코드에 없으므로 SPF 검사가 실패합니다.

DKIM은 전달 후에도 유지됩니다. 서명이 이메일 안에 들어 있으므로, 유효한 상태로 남고 도메인과도 계속 일치합니다. 그래서 p=reject를 쓰는 도메인은 SPF에만 의존하지 말고 반드시 DKIM을 사용해야 합니다.

t=y로 하는 테스트 모드

RFC 9989는 테스트 모드를 추가했습니다. t=y로 설정하면 수신 측은 게시한 정책보다 한 단계 약하게 적용합니다.

reject는 quarantine으로 처리됩니다.
quarantine은 none으로 처리됩니다.

테스트 모드는 보고서를 바꾸지 않습니다. 정책이 p=none일 때는 아무 효과도 없습니다. 더 엄격한 정책을 확정하기 전에, 그 정책이 실제 이메일에서 어떻게 작동하는지 볼 수 있게 해 줍니다.

하위 도메인: sp와 np

하위 도메인은 marketing.example.com이나 support.example.com처럼 도메인 앞에 붙은 추가 이름입니다. 많은 회사가 하위 도메인에서 이메일을 보냅니다. sp와 np 태그는 자체 DMARC 레코드가 없는 하위 도메인에 적용할 규칙을 정합니다.

수신 측이 올바른 레코드를 찾는 방법

수신 측은 먼저 From 줄에 있는 정확한 도메인의 DMARC 레코드를 찾습니다. news.example.com에서 보내고 _dmarc.news.example.com이 있다면, 그 레코드를 사용합니다.
그곳에 레코드가 없으면, _dmarc.example.com에 있는 기본 레코드를 찾습니다. 도메인 이름을 한 부분씩 끝쪽으로 올라가며 찾습니다. 이때 Public Suffix List는 사용하지 않습니다.
기본 레코드를 찾으면, 발송한 하위 도메인이 DNS에 존재하는지 확인합니다.

그다음 규칙을 고릅니다.

하위 도메인이 존재하면 sp를 적용합니다. sp가 없으면 p를 적용합니다.
하위 도메인이 존재하지 않으면(DNS가 “그런 이름이 없음”을 뜻하는 NXDOMAIN을 돌려주면) np를 적용합니다. np가 없으면 sp를, sp도 없으면 p를 사용합니다.

예시

_dmarc.example.com에 다음 레코드가 게시되어 있다고 가정해 보겠습니다.

v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@example.com

이 레코드는 세 가지 다른 규칙을 정합니다.

example.com 자체에서 보낸 이메일에는 p=reject가 적용됩니다. DMARC에 실패하면 차단하도록 수신 측에 요청합니다.
DNS에 존재하는 하위 도메인인 news.example.com에서 보낸 이메일에는 sp=quarantine이 적용됩니다. 업체가 설정을 잘못해 뉴스레터가 실패했다고 해 보겠습니다. 이 메일은 반송되지 않고 스팸함으로 갑니다.
DNS에 존재하지 않는 invoices-2026.example.com 같은 지어낸 이름에서 보낸 이메일에는 np=reject가 적용됩니다. 실제 하위 도메인에는 quarantine이 적용되더라도, 누군가 그냥 지어낸 하위 도메인에는 엄격한 규칙이 적용됩니다.

DMARC 보고서란?

DMARC 보고서에는 두 종류가 있습니다.

rua로 설정하는 집계 보고서. 매일 오는 요약입니다.
ruf로 설정하는 실패 보고서. 실패한 이메일 하나하나를 설명합니다.

집계 보고서(rua)

집계 보고서는 Gmail 같은 메일 서비스 제공업체 한 곳에서 보내는 요약입니다. 그 업체가 받은 이메일 중 도메인에서 보냈다고 주장하는 이메일을 모두 나열합니다. 소프트웨어가 읽도록 만든 구조화된 텍스트 파일인 XML 파일입니다. 업체는 이 보고서를 이메일 첨부 파일로 보내며, 일반 .xml 파일이나 .xml.gz 같은 압축 파일 형태입니다.

각 보고서는 보통 UTC 기준 하루를 다룹니다. 표준에 따르면 수신 측은 집계 보고서를 적어도 24시간마다 보내야 합니다. 다만 보고서를 보낼 의무는 없습니다.

다음은 줄인 보고서 예시입니다.

<feedback>
  <report_metadata>
    <org_name>mail.receiver.example</org_name>
    <report_id>20261003.example.com</report_id>
    <date_range>
      <begin>1790985600</begin>
      <end>1791071999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.10</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>bounces.esp-mail.example</envelope_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result></dkim>
      <spf><domain>bounces.esp-mail.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

블록별로 내용은 다음과 같습니다.

<report_metadata>: 이 보고서는 mail.receiver.example에서 왔습니다. UTC 기준 하루 전체를 다룹니다.
<policy_published>: 수신 측이 확인한 example.com의 정책입니다. 여기서는 p=none과 sp=none입니다.
<row>: IP 주소 192.0.2.10에서 이메일 412건이 도착했습니다.
SPF: <auth_results>를 보면 SPF는 통과했지만, bounces.esp-mail.example 도메인으로 통과했습니다. 이 도메인은 From 도메인인 example.com이 아닙니다. 그래서 <policy_evaluated>에서는 일치하지 않았으므로 SPF가 fail로 표시됩니다.
DKIM: <auth_results>를 보면 DKIM은 example.com으로 통과했습니다. 이는 <identifiers>에 표시된 From 도메인과 일치합니다. 따라서 DKIM이 통과하고 일치했으므로, 이 이메일 412건은 DMARC를 통과했습니다.

핵심은 간단합니다. <auth_results>는 SPF와 DKIM 검사 자체의 결과를 보여 줍니다. <policy_evaluated>는 각 검사가 From 도메인과도 일치했는지 보여 줍니다. DMARC가 사용하는 것은 뒤의 결과입니다.

실패 보고서(ruf)

실패 보고서는 포렌식 보고서라고도 하며, 실패한 이메일을 하나씩 설명합니다. 이메일의 헤더와 수신자에 대한 정보가 들어갈 수 있습니다. 이런 개인정보 위험 때문에 많은 수신 측은 세부 정보를 대부분 지우거나, 실패 보고서를 아예 보내지 않습니다. fo 태그는 이 보고서의 옵션을 정합니다. ruf를 쓸 때만 의미가 있습니다.

보고서 읽기

표준은 집계 보고서를 직접 읽지 말고 소프트웨어로 읽기를 권장합니다. 여러 메일 서비스 제공업체로 메일을 보낸다면, 업체마다 매일 따로 보고서를 보내기 때문입니다.

DMARC 이메일은 왜 오는가?

DMARC 레코드의 rua 태그에 주소가 들어 있기 때문에 매일 이런 이메일을 받습니다. 도메인 이름으로 보낸 이메일을 받는 모든 메일 서비스 제공업체가 그 태그에 있는 각 주소로 매일 요약을 보냅니다.

제목 줄은 RFC 9990에서 정한 고정된 형식을 따릅니다.

Report Domain: example.com Submitter: mail.receiver.example Report-ID: 20261003.example.com

Submitter는 Google이나 Microsoft처럼 이메일을 검사한 업체입니다. XML 보고서가 첨부되며, 압축되어 있는 경우가 많습니다.

이 보고서를 개인 받은편지함으로 보내지 마십시오. 대신 rua가 별도의 메일함이나 보고서 처리 서비스를 가리키게 하십시오. 이렇게 설정한 기억이 없다면 DMARC 레코드를 확인하십시오. 이전 관리자가 추가했거나, 이메일 플랫폼의 설정 안내에 따라 추가되었을 수 있습니다.

다른 도메인으로 보고서 보내기

도메인이 example.com이고, 보고서를 reports.example.net에 있는 주소로 받고 싶다고 가정해 보겠습니다. 받는 쪽 도메인이 보고서 수신에 동의해야 합니다. 받는 쪽 도메인은 DNS에 TXT 레코드를 게시해 동의를 표시합니다. 이 레코드가 없으면 수신 측은 그 주소를 무시하고 보고서를 보내지 않습니다.

레코드는 다음 호스트 이름에 둡니다.

example.com._report._dmarc.reports.example.net  TXT  v=DMARC1

보고서 처리 서비스는 대신 와일드카드 레코드(*._report._dmarc.reports.example.net)를 게시하는 경우가 많습니다. 이 레코드 하나로 모든 고객 도메인이 처리되므로, 고객 도메인마다 따로 설정할 필요가 없습니다.

메일을 잃지 않고 p=none에서 reject로 옮기는 방법

곧바로 reject로 바꾸지 마십시오. 한 단계씩 올리십시오.

감시를 시작합니다. _dmarc에 p=none과 작동하는 rua 주소를 넣은 DMARC 레코드를 게시합니다. 보고서를 받기 시작하며, 전송에는 아무 변화가 없습니다.
발신 서비스를 고칩니다. 보고서를 읽습니다. 도메인으로 이메일을 보내면서 검사에 실패하는 실제 서비스를 모두 찾아 설정을 고칩니다.
quarantine으로 옮깁니다. 실제 발신 서비스가 모두 꾸준히 통과하면 p=quarantine으로 바꿉니다. 스팸함을 확인해 실제 이메일이 그곳에 들어가지 않는지 확인합니다.
reject로 옮깁니다. p=reject로 바꿉니다. 이제 도메인 이름으로 보낸 가짜 이메일은 수신자에게 도착하기 전에 차단됩니다.

시간이 걸릴 수 있습니다. 표준에 따르면, 모든 발신 서비스가 통과하게 만드는 데는 발송 빈도에 따라 여러 달이 걸릴 수 있습니다. 청구 도구, 고객 지원 도구, 마케팅 플랫폼은 놓치기 쉬우므로 보고서를 계속 검토하십시오.

사용자가 메일링 리스트에 글을 올린다면 더 천천히 진행하십시오. 표준은 p=none으로 적어도 한 달, 그다음 quarantine으로 같은 기간을 두라고 제안합니다. reject로 옮기기 전에 결과를 비교하십시오. 메일링 리스트는 제목을 바꾸거나, 바닥글을 추가하거나, 메시지를 다시 보내는 경우가 많습니다. 이런 변경은 SPF를 깨뜨리고, 때로는 DKIM도 깨뜨립니다. 몇 주 분량의 보고서를 비교하면 reject가 메일을 차단하기 전에 이런 문제를 발견할 수 있습니다.

마지막 단계에는 테스트 모드를 사용하십시오. t=y를 사용하면, 수신 측이 계속 quarantine을 적용하는 상태에서 p=reject를 게시할 수 있습니다. 수신 측이 reject에 어떻게 반응하는지 볼 수 있으며, 실패한 이메일은 반송되지 않고 여전히 스팸함으로 갑니다.

엄격한 SPF에 대한 참고. SPF 레코드가 -all로 끝나면, 일부 수신 측은 DMARC가 실행되기 전에 SPF 검사 단계에서 실패한 이메일을 거부합니다. 이런 이메일은 DMARC 검사까지 가지 않습니다. 매일 오는 보고서에도 나타나지 않습니다.

흔한 DMARC 레코드 실수

DMARC 레코드가 두 개

첫 번째 레코드를 수정하지 않고 두 번째 TXT 레코드를 추가할 때 자주 생깁니다. RFC 9989에 따라 수신 측은 두 레코드를 모두 보고 모두 버립니다. 그러면 도메인은 DMARC 레코드가 전혀 없는 것처럼 동작합니다.

해결 방법: DNS를 확인하고 모든 태그를 하나의 TXT 레코드로 합칩니다.

레코드가 _dmarc가 아니라 기본 도메인에 있음

호스트 이름에 example.com을 입력하면, 레코드는 _dmarc.example.com이 아니라 기본 도메인에 만들어집니다. 메일 서버는 _dmarc 이름에서만 DMARC를 찾으므로 이 레코드를 찾지 못합니다.

해결 방법: 호스트 이름을 _dmarc로 설정합니다.

v=DMARC1이 맨 앞에 없거나 대소문자가 틀림

v=dmarc1으로 입력하거나 p=none; v=DMARC1처럼 시작하면 레코드가 깨집니다. 수신 측은 이 레코드를 무시합니다.

해결 방법: 레코드의 맨 앞에 v=DMARC1을 두고, 그 뒤에 세미콜론을 붙입니다.

mailto: 없는 보고서 주소

rua=mailto:dmarc@example.com 대신 rua=dmarc@example.com으로 쓰면 주소 형식이 깨집니다. 수신 측은 mailto: 없는 주소를 사용할 수 없으므로 보고서가 오지 않습니다.

해결 방법: rua와 ruf의 모든 주소를 mailto:로 시작합니다.

허가 없이 다른 도메인으로 보고서를 보냄

업체 도메인으로 보고서를 보내는데 그 도메인이 허가 레코드를 게시하지 않았다면, 보고서를 받지 못합니다.

해결 방법: 앞에서 설명한 대로, 외부 보고서 주소마다 그에 맞는 _report._dmarc 레코드가 있는지 확인합니다.

SPF만으로 reject 설정

전달은 이메일을 보내는 IP 주소를 바꾸므로, 전달된 이메일은 SPF에 실패합니다. DKIM이 없으면 실제로 전달된 이메일이 DMARC에 실패해, reject 정책에서 반송됩니다.

해결 방법: p=none에서 다음 단계로 넘어가기 전에, 이메일을 보내는 모든 서비스에서 DKIM 서명을 설정합니다.

예전 가이드에 나오는 폐지된 태그

예전 가이드 중에는 비율 태그를 100이나, 부분 도입을 위한 20 같은 값으로 추가한 경우가 많습니다. 남아 있는 pct=100은 해가 되지 않지만, 비율을 정해 도입하는 방식은 더 이상 표준에 없습니다.

해결 방법: 예전 비율 태그를 제거합니다. 변경하는 동안 더 약한 정책이 필요하다면 t=y를 사용합니다.

자주 묻는 질문

DMARC 레코드가 정말 필요합니까? 개인 Gmail이나 Outlook 계정으로 이메일을 보낸다면 필요합니다. Google과 Microsoft는 모두 하루 5,000건 이상을 보내는 발신자에게 From 도메인이 일치하는 DMARC 레코드를 게시하도록 요구합니다. 발송량이 적은 발신자도 DMARC 레코드를 두는 것이 좋습니다. rua를 넣은 p=none 레코드는 비용이 들지 않으며, 보고서를 보면 누가 도메인 이름으로 이메일을 보내는지 알 수 있습니다.

DMARC 레코드는 어떻게 확인합니까? 터미널에서 dig TXT _dmarc.yourdomain.com +short를 실행하거나, Windows에서는 nslookup -type=TXT _dmarc.yourdomain.com을 실행합니다. 결과로 v=DMARC1으로 시작하는 레코드가 나와야 합니다. Gmail 계정으로 테스트 이메일을 보내고, 메일을 열어 “원본 보기”를 선택하는 방법도 있습니다. DMARC를 통과했는지 표시됩니다.

DMARC fail은 무슨 뜻입니까? 이메일이 두 검사에 모두 실패했다는 뜻입니다. SPF와 DKIM 모두 보이는 From 도메인과 일치하는 도메인으로 통과하지 못했습니다. 그러면 수신 측은 정책을 따릅니다. 일부는 550 5.7.1 Email rejected per DMARC policy for example.com처럼 분명한 거부 메시지를 돌려보냅니다. 원인은 반송 메시지를 읽어 찾을 수 있습니다. Gmail은 DMARC 레코드가 없으면 오류 코드 4.7.31을, From 도메인이 일치하지 않으면 4.7.32를 사용합니다.

DMARC 레코드를 두 개 이상 둘 수 있습니까? 아니요. 한 도메인에는 DMARC 레코드를 하나만 게시할 수 있습니다. RFC 9989에 따르면 수신 서버가 레코드를 두 개 이상 발견하면 모두 버려야 합니다. 그러면 도메인에 DMARC 정책이 없는 상태가 됩니다. 두 번째 레코드를 추가하지 말고 기존 레코드를 수정하십시오.

DMARC로 비슷한 도메인을 막을 수 있습니까? 아니요. DMARC는 DNS에 있는 정확한 도메인만 보호합니다. 두 글자의 순서를 바꾸거나 .net처럼 끝을 다르게 한 비슷한 도메인을 누군가 등록하는 것은 막을 수 없습니다. 가짜 표시 이름도 막을 수 없습니다. 비슷한 도메인에는 회사 이름을 흉내 낸 새 도메인 등록을 감시하는 것 같은 다른 대책이 필요합니다.

DMARC 레코드는 이메일이 실제로 자사에서 보낸 것임을 증명합니다. 하지만 더 이상 존재하지 않는 주소로 보내는 문제에는 도움이 되지 않습니다. 다음 발송 전에 리스트를 Giggal.ai(영어)로 검사해 무효 주소를 제거하고 반송률을 낮게 유지하십시오.