No DMARC record found: 도메인에 빠져 있는 한 줄

핵심 요약

• 이 메시지는 _dmarc.yourdomain.com에 TXT 레코드가 없다는 뜻입니다. 메일 서버가 고장 난 것이 아닙니다.
• 호스트가 _dmarc이고 값이 v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com인 TXT 레코드 하나를 추가하세요. p=none이면 메일 배달은 이전과 똑같이 유지됩니다.
• Gmail, Yahoo, Outlook.com은 대량 발송자에게만 이 레코드를 요구합니다. 그래도 추가하세요. Google은 도메인 전체를 합산하고 대량 발송자 분류를 결코 해제하지 않으며, 보고서는 레코드가 있어야 오기 시작합니다.
• 검사 도구가 여전히 아무것도 찾지 못하면 잘못된 DNS 호스팅 업체, 중복된 호스트 이름, 두 개의 DMARC 레코드를 의심하세요. 레코드가 두 개면 서로를 무효로 만듭니다.
• 표준은 2026년 5월 RFC 9989로 바뀌었습니다. pct가 사라지고 t와 np가 새로 생겼습니다. Google 도움말은 2026년 10월 기준으로 여전히 pct를 설명합니다.

“No DMARC record found”(DMARC 레코드를 찾을 수 없음)는 검사 도구가 DNS에 _dmarc.yourdomain.com의 TXT 레코드를 물었는데 아무 답도 받지 못했다는 뜻입니다. 메일 서버에 고장 난 것은 없습니다. 해결책은 호스트가 _dmarc이고 값이 v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com인 TXT 레코드 하나입니다. p=none이면 메일은 이전과 똑같이 배달됩니다. 수신 측에 내가 DMARC에 참여한다는 것을 알리고, 보고서를 받기 시작할 뿐입니다.

DMARC는 SPF, DKIM과 함께 세 가지 이메일 레코드 가운데 세 번째입니다. SPF는 내 도메인으로 발송해도 되는 서버를 나열합니다. DKIM은 메시지마다 서명합니다. DMARC는 둘 중 어느 것도 From 주소의 도메인을 보증하지 못할 때 수신 측이 어떻게 해야 하는지, 그리고 일일 요약을 어디로 보내야 하는지 알려 줍니다. 2026년 5월부터는 이전의 RFC 7489를 대체한 RFC 9989에 정의되어 있습니다. 많은 가이드가 아직 이전 버전을 설명하고 있으며, 2026년 10월 기준 Google 도움말 페이지도 마찬가지입니다.

추가할 레코드

도메인의 DNS를 관리하는 곳에 로그인하세요. 네임서버가 가리키는 회사이며, 도메인을 구입한 회사와 항상 같지는 않습니다. 다음 값으로 새 레코드를 추가합니다.

영역 파일의 한 줄로 적으면 완성된 레코드는 다음과 같습니다.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

example.com을 내 도메인으로 바꾸세요. 세 부분의 역할은 다음과 같습니다.

• v=DMARC1은 이 줄이 DMARC 레코드임을 표시합니다. 맨 앞에 와야 하고 DMARC1은 대문자여야 합니다. 그렇지 않으면 수신 측은 레코드 전체를 무시합니다.
• p=none은 정책입니다. 내 메일을 평소대로 처리하라는 뜻입니다. 이 레코드 때문에 차단되거나 스팸함으로 옮겨지는 메일은 없습니다.
• rua=mailto:…는 일일 보고서를 받을 주소입니다. 레코드를 게시하기 전에 그 주소나 나에게 전달되는 별칭을 만들어 두세요.

Google은 DMARC 설정에서 같은 세 필드를 안내합니다. 또한 DMARC를 추가하기 전에 SPF와 DKIM이 48시간 동안 작동하고 있을 것을 요구합니다. 검사 도구가 이 둘도 문제로 표시한다면 그것부터 고치세요.

제대로 되었는지 확인하는 방법

DNS에 직접 물어보세요. macOS나 Linux에서는 터미널을 열고 dig를 사용합니다. Windows에서는 nslookup을 사용합니다.

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

레코드가 적용되었다면 그 줄이 따옴표 안에 담겨 돌아옵니다. 다음은 2026년 10월 5일에 Google의 도메인이 답한 내용입니다.

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

빈 응답은 레코드가 아직 없거나 수신 측이 찾는 위치에 없다는 뜻입니다. 직접 조회해 그 줄이 보이면, 메시지를 띄웠던 검사 도구를 다시 실행하세요. 예를 들어 MXToolbox는 이 문제를 “No DMARC Record found”라고 표현하고 “도메인에 게시된 DMARC 레코드가 없다”고 설명합니다.

DMARC 레코드 각 부분의 의미

레코드는 세미콜론으로 구분된 tag=value 쌍의 목록입니다. 표준에서 필수인 것은 v뿐이며 맨 앞에 와야 합니다. p는 두 번째에 두세요. Google 도움말은 “v 태그와 p 태그를 먼저 나열해야 한다”고 밝히고, 이전 표준도 같은 순서를 요구했습니다. 다음은 RFC 9989 4.7절의 태그입니다.

오래된 레코드는 흔히 pct=100으로 끝납니다. 이 태그는 실패한 메일의 일부에만 정책을 적용하려는 용도였습니다. RFC 9989는 이 태그를 rf, ri와 함께 삭제했고 그 이유를 밝힙니다.

운영 경험에 따르면 “pct” 태그는 지정된 값이 0이나 100(기본값)이 아닌 한 대체로 정확하게 적용되지 않았으며, 다른 값에서의 부정확성은 구현마다 크게 달랐다.

수신 측은 모르는 태그를 무시해야 하므로 오래된 pct=100은 해가 되지 않습니다. 2026년 10월 5일에도 yahoo.com과 microsoft.com의 레코드에는 이 태그가 남아 있었고, Google 도움말 페이지는 여전히 단계적 적용에 pct를 권장합니다. 새 레코드에는 넣지 마세요.

하루에 이메일 몇 통만 보내도 DMARC가 필요한가요?

대형 메일 제공업체들이 공개한 규칙에 따르면 DMARC 레코드는 대량으로 발송할 때부터 필수입니다. 그 아래에서는 권장 사항입니다.

출처는 Google의 이메일 발신자 가이드라인, Yahoo의 Sender Best Practices, Microsoft의 대량 발송자 대상 공지이며 모두 2026년 10월 기준입니다. 메일함 하나에서 하루 30통을 보낸다면 어느 곳도 이 레코드를 요구하지 않습니다. 그래도 지금 추가해야 할 이유가 세 가지 있습니다.

• 기준은 도메인 단위로 세며, 초기화되지 않습니다. Google은 같은 기본 도메인에서 나와 개인 Gmail 계정으로 가는 모든 메시지를 하위 도메인까지 포함해 합산합니다. 발신자 FAQ는 이렇게 말합니다. “위 기준을 한 번이라도 충족한 발송자는 영구적으로 대량 발송자로 간주됩니다.”
• Google과 Yahoo 모두 모든 발송자에게 권장합니다. Google은 “도메인에 항상 SPF, DKIM, DMARC를 설정할 것을 권장한다”고 씁니다. Yahoo는 “모든 발송자가 메일을 보내는 도메인마다 DMARC 정책을 게시할 것을 강력히 촉구”합니다.
• 레코드가 없으면 보고서를 받지 못합니다. 보고서는 어떤 서버가 From 줄에 내 도메인을 넣어 메일을 보내는지 보여 줍니다. 내 도구든 모르는 사람이든 모두 나옵니다.

대량 발송자에게는 레코드가 없을 때 불이익이 따릅니다. Google의 발신자 FAQ는 이에 대한 일시적 오류 4.7.31을 싣고 있습니다. “발송 도메인에 DMARC 레코드가 없거나, DMARC 레코드가 DMARC 정책을 지정하지 않습니다.” 같은 페이지는 2025년 11월부터 요건을 충족하지 못하는 메일이 “일시적 및 영구적 거부”를 겪는다고 말합니다.

레코드를 추가했는데도 검사 도구가 아무것도 찾지 못하나요?

그렇다면 대개 다음 중 하나가 원인입니다. 위의 dig 조회로 하나씩 확인하세요.

• 엉뚱한 곳에서 DNS를 수정했습니다. 네임서버가 등록 업체와 다른 회사에 있다면 등록 업체에 입력한 레코드는 조회되지 않습니다. dig +short NS example.com으로 누가 내 도메인에 대해 응답하는지 볼 수 있습니다.
• 호스트가 틀렸습니다. 레코드가 example.com 자체에 있거나, 위에서 설명한 것처럼 중복된 이름에 있습니다. 수신 측은 _dmarc.example.com만 조회합니다.
• DMARC 레코드가 두 개입니다. 이 부분에서 표준은 엄격합니다. “하나의 대상에 대해 DMARC 정책 레코드가 여러 개 반환되면 모두 폐기된다.” 하나로 합치세요. 보고서 주소가 둘이면 쉼표로 구분해 하나의 rua에 넣습니다.
• 첫 태그가 정확히 v=DMARC1이 아닙니다. 소문자, DMARC 1 같은 오타, 또는 그 앞에 놓인 p=는 레코드를 무효로 만듭니다.
• 레코드 유형이 TXT가 아니거나, 문서에서 값을 복사하면서 둥근 따옴표가 함께 붙었습니다. 값은 일반 텍스트로 입력하고, DNS 호스팅 업체의 도움말이 요구하지 않는 한 따옴표 없이 넣으세요.
• 이전 응답이 아직 캐시에 남아 있습니다. 리졸버는 “그런 레코드 없음”을 한동안 기억합니다. 조회에 네임서버 이름을 붙여 내 네임서버 가운데 하나에 직접 물어보세요. 예를 들면 dig +short TXT _dmarc.example.com @ns1.example.net입니다. 거기서 레코드가 보이면 검사 도구도 곧 따라옵니다.

보고서가 가는 곳과 활용 방법

From 줄에 내 도메인이 들어간 메일을 받은 모든 수신 측이 rua 주소로 보고서를 보냅니다. Google의 DMARC 보고서 정보 페이지에 따르면 보고서는 “보통 하루에 한 번 이메일로 발송”됩니다. 보고서는 XML 파일이며 대개 압축되어 이메일에 첨부됩니다. 형식은 RFC 9990이 설명합니다.

Google은 큰 조직이 “매일 수백 건, 많게는 수천 건의 보고서를 받을 수도 있다”고 경고하며 그룹이나 전용 메일함을 권장합니다. 그 수는 얼마나 많이, 얼마나 많은 도메인으로 보내느냐에 달려 있으므로 메일함 한두 개에서는 훨씬 적게 옵니다. dmarc@ 같은 별칭에 전용 폴더로 보내는 필터를 걸어 두면 충분합니다.

주소는 레코드와 같은 도메인에 있는 것이 좋습니다. 보고서를 다른 곳에서 받고 싶다면 그 다른 도메인이 자체 레코드를 게시해 동의해야 합니다. 그 레코드가 없으면 수신 측은 그 주소를 무시해야 합니다(RFC 9990 4절).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

무료 Gmail 주소를 보고서 주소로 쓸 수 없는 이유가 이것입니다. 2026년 10월 5일에 확인했을 때 gmail.com은 그런 레코드를 게시하지 않았습니다.

파일에서 각 record 블록은 발송 서버 하나를 나타냅니다. IP 주소, 메시지 수, 그리고 policy_evaluated 아래에 DKIM과 SPF가 내 도메인에 대해 통과했는지가 들어 있습니다. 살펴볼 것은 두 가지입니다. 아는 서버인데 fail이 나오면 고쳐야 하며, 방법은 SPF와 DKIM은 통과하는데 DMARC가 실패할 때에서 설명합니다. 모르는 서버는 잊고 있던 도구이거나 내 이름을 쓰는 누군가입니다.

p=none 이후: 정책을 강화할 시점

p=none은 모니터링 모드입니다. 메일 제공업체가 요구하는 최소 조건을 충족하지만, 누군가 내 주소를 위조하는 것을 막지는 못합니다. 그것을 막는 것은 실패한 메일을 의심스럽게 처리해 달라고 요청하는 p=quarantine과 거부해 달라고 요청하는 p=reject뿐입니다.

강화하기 전에 내 메일의 정당한 발송 출처가 모두 통과해야 합니다. RFC 9989는 그런 빈틈을 시행하려는 “어떤 시도보다 먼저 반드시 해결해야 한다”고 말하며, 발송 빈도에 따라서는 확신이 서기까지 “여러 달”의 보고서가 필요할 수 있다고 합니다. Google의 단계적 적용 페이지는 일주일치 보고서면 “대개 충분하다”고 봅니다. 메일함 하나에 도구 한두 개라면 Google의 수치에 더 가깝겠지만, 매달 한 번 나가는 청구서 발송과 문의 양식까지 보고서에 나타나도록 몇 주는 지켜보세요.

단계 자체에 대해서는 두 출처가 서로 다릅니다. Google은 여전히 p=quarantine; pct=5로 시작해 숫자를 올리라고 제안합니다. 표준은 pct를 삭제했고 대신 다음을 제시합니다.

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y는 당분간 실패를 한 단계 낮게, 즉 none으로 처리해 달라고 수신 측에 요청합니다. 보고서가 계속 깨끗하면 t=y를 지우세요. 이 태그를 모르는 수신 측은 태그를 무시하고 quarantine을 그대로 적용한다는 점, 그리고 2026년 10월 기준으로 Google의 페이지들은 t를 언급하지 않는다는 점에 유의하세요. 더 엄격한 정책이 아직 고칠 수 없는 메일에 영향을 준다면 p=none에 머무르세요.

WarmupBay의 역할

메일함을 연결하면 WarmupBay는 그 도메인의 SPF, DKIM, DMARC를 점검합니다. DMARC 레코드가 없으면 복사해서 쓸 수 있는 완성된 레코드를 보여 줍니다. 그래도 워밍업은 시작할 수 있습니다. 72시간 후에도 레코드가 없으면 워밍업이 중지됩니다.

WarmupBay가 레코드를 대신 추가해 줄 수는 없습니다. DNS는 내 것이기 때문입니다. DMARC 보고서를 수집하거나 읽지도 않습니다. WarmupBay가 하는 것은 레코드 다음 단계입니다. 내 메일함이 공동 풀의 다른 메일함들과 하루에 이메일 몇 통을 주고받습니다. 3통에서 시작해 매일 한 통씩 늘어나므로 발송 활동이 점진적으로 쌓입니다. 하루 10통까지 무료입니다. 점검과 워밍업이 다루는 범위를 보거나, 레코드가 갖춰지면 메일함을 연결하세요.

자주 묻는 질문

example.com의 DMARC 레코드는 news.example.com 같은 하위 도메인에도 적용되나요?

네. 수신 측은 먼저 _dmarc.news.example.com의 레코드를 조회합니다. 없으면 조직 도메인인 example.com의 레코드로 넘어갑니다. 하위 도메인에 적용되는 정책은 sp를 설정했다면 sp의 정책이고, 그렇지 않으면 p의 정책입니다.

rua 주소 없이 v=DMARC1; p=none만 게시해도 되나요?

네. 유효한 레코드이며 게시된 정책으로 인정됩니다. 다만 보고서를 받지 못하므로 내 메일이 통과하는지, 다른 누가 내 도메인을 쓰는지 볼 수 없습니다. Yahoo는 작동하는 rua 주소를 강력히 권장한다고 하고, Google은 항상 포함할 것을 권장합니다.

아웃리치에만 쓰는 두 번째 도메인에도 DMARC 레코드가 필요한가요?

네. 수신 측은 메시지마다 From 주소의 도메인을 조회하므로, 주 도메인의 레코드는 다른 도메인에 적용되지 않습니다. 두 번째 도메인에도 같은 한 줄을 쓰세요. 그 보고서를 주 도메인의 주소로 받으려면 주 도메인이 ‘보고서가 가는 곳’ 섹션에서 설명한 승인 레코드를 게시해야 합니다.

이메일을 전혀 보내지 않는 도메인은 무엇을 게시해야 하나요?

엄격한 한 쌍입니다. M3AAWG는 메일을 전혀 보내지 않는 도메인에 SPF 레코드 v=spf1 -all과 p=reject인 DMARC 레코드를 권장합니다. 아무도 그 도메인을 From 주소에 쓰지 못하게 하기 위해서입니다. DMARC의 경우 _dmarc에 v=DMARC1; p=reject 한 줄입니다.

p=none은 p=quarantine이나 p=reject보다 내 메일에 불리한가요?

Gmail, Yahoo, Outlook.com이 공개한 발신자 규칙은 최소 p=none을 요구하며 그보다 엄격한 것은 요구하지 않습니다. 정책은 DMARC에 실패한 메일을 어떻게 처리할지를 정하며, 여기에는 내 이름을 도용한 위조 메일도 포함됩니다. 한 가지 기능에는 더 엄격한 정책이 필요합니다. 메시지 옆에 로고를 보여 주는 BIMI는 Google 도움말에 따르면 quarantine이나 reject가 있어야 합니다.

출처

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)