# DMARC 정책: 30일 만에 p=none에서 p=reject로 정식 URL: https://brew.new/ko/blog/dmarc-p-none-to-reject-in-30-days 글쓴이: Thomas Park 게시일: 2026-10-04 수정일: 2026-10-04 DMARC는 `_dmarc.`에 두는 TXT 레코드예요. From 헤더에 내 도메인을 쓰면서 정렬된 SPF와 DKIM을 통과하지 못한 메일을 어떻게 처리할지, 그리고 보고서를 어디로 보낼지 수신 측에 알려 줘요. `p=none`은 보고서만 요청하고, `p=quarantine`은 실패한 메일을 의심스러운 메일로 취급하라고, `p=reject`는 아예 거부하라고 수신 측에 요청해요. Gmail, Yahoo, Microsoft는 대량 발신자의 `p=none`을 허용해요. 그래서 많은 도메인이 `p=none`을 게시하는 데서 멈추고, 스푸핑을 보고만 받을 뿐 막지는 않아요. [2026년 4월](https://redsift.com/blog/email-authentication-bespinlabs-redsift)에 인용된 Red Sift의 도메인 7,330만 개 분석에 따르면, DMARC 정책이 하나라도 있는 도메인은 14.9%였고 `p=reject`를 적용한 도메인은 2.5%였어요. 또 다른 DMARC 업체인 EasyDMARC는 DMARC를 쓰는 Fortune 500 기업 중 62.7%가 `p=reject`를 쓰는 반면, Inc. 5000 기업은 15.2%에 그친다고 [2025년에 발표했어요](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/). 이 글은 업무용 메일, ESP 한두 곳, 헬프데스크, 결제 도구에서 메일을 보내는 도메인을 30일 만에 `p=reject`로 옮기는 계획을, 레코드 하나하나 짚어 가며 설명해요. 30일은 발신용 하위 도메인에 맞는 기간이에요. 직원들이 일상 업무 메일에 쓰는 도메인은 더 오래 걸려요. ## 핵심 요약 - 1일 차에 `v=DMARC1; p=none; rua=mailto:...` 레코드를 게시하세요. `rua`가 없으면 수신 측은 집계 보고서를 보내지 않아야 해요. - 모든 정상 발신원은 From 도메인에 정렬된 SPF 또는 DKIM을 통과해야 해요. 대부분의 도구에서는 내 도메인으로 DKIM 서명을 한다는 뜻이에요. - SPF에서 DNS 조회가 필요한 항목은 중첩된 include까지 포함해 10개 이내로 유지하세요. 넘으면 모든 메일이 `permerror` 결과를 받아요. - 15일 차에 `p=quarantine`으로, 22일 차에 `p=reject`로 넘어가세요. 두 번 모두 보고서에 문제가 없는 한 주를 보낸 뒤에 넘어가요. 직원들이 일상 업무 메일에 쓰는 도메인이라면, RFC 9989는 처음 두 단계를 각각 한 달씩 유지하라고 해요. - RFC 9989(2026년 5월)는 `pct` 태그를 폐지(historic)했어요. `pct=10`, `pct=50`으로 조금씩 올리는 방식은 건너뛰세요. - BIMI를 쓰려면 조직 도메인에 `p=quarantine` 또는 `p=reject`가 있어야 하고, `sp=none`이 없어야 하며, SVG Tiny PS 로고와 함께 Gmail에서는 VMC나 CMC도 필요해요. ## 2026년 DMARC의 변화 2026년 5월, IETF는 2015년에 나온 정보성(Informational) 문서인 RFC 7489를 DMARCbis로 대체했어요. DMARCbis는 RFC 9091까지 대체하는 제안 표준(Proposed Standard)인 [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)와, 집계 보고를 다루는 [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html)으로 이루어져요. 여기서 중요한 변화는 세 가지예요. - **`pct`는 폐지(historic)됐어요.** 부록 A.6은 이 태그가 “지정한 값이 0이나 100이 아니면 대개 정확하게 적용되지 않았다”고 설명해요. - **`pct=0` 대신 `t=y`를 써요.** 수신 측은 게시한 정책보다 한 단계 낮은 정책을 적용하므로, `p=reject; t=y`는 quarantine처럼 동작해요. 테스트용 스위치예요. - **`np` 태그가 새로 생겼어요.** DNS에 존재하지 않는 하위 도메인에 적용되며, 구형 수신 측은 이 태그를 무시해야 해요. 조직 도메인을 찾을 때도 이제 공개 접미사 목록(public suffix list) 대신 DNS 트리 탐색을 써요. ## DMARC가 의존하는 세 가지 레코드 DMARC는 SPF나 DKIM이 통과하고, **동시에** 통과한 도메인이 From 도메인과 정렬될 때 통과해요. 정렬된 통과 하나면 충분해요. ### SPF와 10회 조회 한도 SPF는 엔벨로프 도메인(`MAIL FROM` 또는 반송 경로)에 대해 메일을 보낼 수 있는 서버를 승인해요. DMARC가 쓰는 SPF 식별 정보는 HELO가 아니라 이 도메인뿐이에요. [RFC 7208의 4.6.4절](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4)은 DNS 조회가 필요한 항목을 10개로 제한해요. `include`, `a`, `mx`, `ptr`, `exists`, `redirect`가 여기에 해당하고, 중첩된 include 안의 항목까지 모두 세요. `ip4`, `ip6`, `all`은 세지 않아요. 한도를 넘으면 결과는 `permerror`가 돼요. 같은 절은 “빈 조회(void lookup)”도 최대 두 번까지만 허용하는데, 보통 더는 존재하지 않는 호스트 이름을 include할 때 생겨요. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` 이 레코드만으로도 각 업체가 중첩해 둔 항목을 세기 전에 이미 조회 4회를 써요. 그러니 `dig +short TXT ` 명령으로 체인을 끝까지 따라가며 하나씩 확인하세요. 10회 이내로 유지하려면 쓰지 않는 도구를 빼거나, ESP마다 `bounce.example.com` 같은 별도의 반송 경로 하위 도메인을 두세요. 하위 도메인마다 10회 한도가 따로 적용돼요. Microsoft의 [SPF 설정 가이드](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)는 DKIM과 DMARC도 쓰는 도메인이라면 `-all`로 끝내라고 권장해요. 많은 ESP는 기본적으로 자체 반송 경로 도메인을 쓰는데, 이 도메인은 내 도메인과 정렬되지 않아요. 커스텀 반송 경로를 설정하거나, 정렬은 DKIM에 맡기세요. ### DKIM: 2048비트 키, 셀렉터, 키 교체 DKIM은 도메인 `d=`와 셀렉터 `s=`로 각 메시지에 서명하고, 수신 측은 `._domainkey.`에서 공개 키를 가져와요. `d=vendor-mail.example`로 서명하는 도구는 DKIM은 통과하지만 DMARC는 실패해요. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html)에 따르면 서명자는 최소 1024비트 RSA 키를 반드시 써야 하고, 2048비트 키를 쓰는 것이 권장돼요. [Google 발신자 가이드라인](https://support.google.com/mail/answer/81126)도 개인 Gmail 계정으로 가는 메일에 대해 같은 기준을 제시해요. 2048비트 키는 TXT 문자열 한도인 255자를 넘기 때문에, 하나의 레코드 안에 따옴표로 묶은 여러 문자열로 나눠 넣어요. 대부분의 DNS 호스팅 업체는 이 분할을 알아서 해 줘요. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` 발송 시스템마다 별도의 셀렉터를 주고, 셀렉터 이름은 절대 재사용하지 마세요. `s202610`처럼 날짜를 넣으면 이력을 읽기 쉬워요. M3AAWG의 [키 교체 모범 사례](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)는 최소 6개월마다 키를 교체하라고 해요. 1. 새 셀렉터를 게시하고 전파될 때까지 기다리세요. 2. 서명을 새 키로 전환하세요. 3. 전송 중인 메일도 검증될 수 있도록 이전 공개 키를 7~30일 동안 DNS에 남겨 두세요. 4. 이전 셀렉터는 `p=` 값을 비워서 폐기하세요. 삭제하지는 마세요. ### 정렬: 완화 또는 엄격 RFC 9989는 두 가지 모드를 정의해요. | 모드 | 태그 | 통과한 SPF/DKIM 도메인 | From 도메인 | 정렬 여부 | |---|---|---|---|---| | 완화(relaxed, 기본값) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | 예, 같은 조직 도메인 | | 엄격(strict) | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | 아니요, 이름이 정확히 일치해야 함 | | 두 모드 모두 | | `vendor.example.net` | `example.com` | 아니요 | RFC 9989는 “거의 모든 도메인 소유자가 완화 정렬로 충분하다고 판단했다”고 적고 있어요. `aspf`와 `adkim`은 빼 두세요. 엄격한 SPF 정렬을 쓰면 하위 도메인에 두는 일반적인 반송 경로가 정렬되지 않아요. ## 30일 계획 ![4단계로 나눈 30일 DMARC 일정표: 1~7일 차 rua 보고서를 받는 p=none, 8~14일 차 발신원 수정, 15일 차 p=quarantine, 22일 차 p=reject, 30일 차부터 BIMI, 단계마다 정확한 TXT 레코드 표시.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *단계별 레코드예요. 보고서에 문제가 없는 한 주를 보낸 뒤에만 다음 단계로 넘어가세요.* | 기간 | 정책 | 할 일 | 다음 단계로 넘어갈 조건 | |---|---|---|---| | 1~7일 차 | `p=none` | `rua`와 함께 게시, 모든 발신원 목록 작성 | Google, Yahoo, Microsoft의 보고서 7일분 확보 | | 8~14일 차 | `p=none` | DKIM과 SPF 수정, 쓰지 않는 발신원 정리 | 모든 정상 발신원이 정렬된 SPF 또는 DKIM 통과 | | 15~21일 차 | `p=quarantine` | 격리된 정상 메일이 있는지 모니터링 | 실패하는 정상 발신원 없이 7일 경과 | | 22~30일 차 | `p=reject` | 보고서 계속 확인, `np=reject` 추가 | 한 주 동안 안정적 | | 30일 차 이후 | `p=reject` | BIMI 시작 | 인증서 발급 | 2주 차에 아무도 고칠 수 없는 발신원이 나오면 `p=none`에 머무르세요. 내 인보이스를 스스로 거부하는 것보다는 정책 적용이 늦어지는 편이 나아요. ### 1~7일 차: 보고서를 받도록 p=none 게시하기 ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` 보고서는 gzip으로 압축한 XML 파일이고, 수신 측마다 최소 하루 한 번씩 보내요. 그러니 `rua`는 사람이 아니라 보고서 처리 서비스를 가리키게 하세요. 주소가 다른 조직 도메인에 있으면, RFC 9990에 따라 수신 측은 `example.com._report._dmarc.` 레코드로 허용되지 않는 한 그 주소를 무시해요. 보고서 처리 서비스는 이 레코드를 직접 게시해 두지만, 내가 소유한 다른 도메인이라면 직접 추가해야 해요. DMARC 레코드는 정확히 하나만 게시하세요. 설정 마법사 때문에 `_dmarc.example.com`에 `v=DMARC1` 레코드가 두 개 생기면, 수신 측은 둘 다 버려요. `ruf`는 생략하세요. RFC 9989에 따르면 개인정보 보호를 중시하는 수신 측은 실패 보고서의 내용을 대부분 가리거나 아예 보내지 않아요. Microsoft의 [대량 발신자 요건 발표](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730)에 실린 FAQ도 `rua` 보고서는 보내지만 `ruf`를 보낼 계획은 없다고 밝혀요. ### 집계 보고서 읽는 법 RFC 9990은 정책 도메인마다 하나씩 “매일(또는 더 자주)” 보내는 XML 보고서를 설명해요. 다음은 RFC의 샘플을 바탕으로 만든 레코드 하나예요. ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` `policy_evaluated` 안의 `dkim`과 `spf`는 **정렬** 결과이고, `disposition`은 수신 측이 실제로 한 조치예요. `auth_results`에는 원래의 인증 결과와 해당 도메인이 담겨요. 이 예시에서는 둘 다 `vendor.example`로 통과했기 때문에, 둘 다 정렬에는 실패했어요. 업체가 내 이름으로 메일을 보내면서 내 도메인으로 서명하지 않은 경우예요. 그 업체의 커스텀 DKIM이나 도메인 인증 기능을 켜세요. ### 1~7일 차: 모르는 발신원 찾기 `source_ip`, `envelope_from`, DKIM의 `domain`과 `selector` 조합으로 묶고, `count` 순으로 정렬한 다음, 다음과 같이 분류하세요. | 보고서의 패턴 | 예상 원인 | 조치 | |---|---|---| | 정렬된 DKIM 또는 SPF 통과 | 올바르게 설정됨 | 없음 | | 업체 도메인으로 DKIM과 SPF 통과 | SaaS 도구가 자체 식별 정보 사용 | 커스텀 DKIM 켜기 | | 정렬된 DKIM 통과, SPF 실패, 메일 서비스 제공업체나 메일링 리스트의 IP | 전달 또는 메일링 리스트 | 대개 없음. 정렬된 DKIM은 전달돼도 유지됨 | | DKIM 없음, SPF 실패, 출처를 알 수 없는 IP | 스푸핑 | 없음. `p=reject`가 막는 대상 | IP의 출처를 확인하려면 `dig -x 192.0.2.123 +short` 명령을 실행하고 셀렉터를 확인하세요. 셀렉터에 업체 이름이 들어 있는 경우가 많아요. 그런 다음 재무팀, 고객 지원팀, 영업팀에 회사 이름으로 메일을 보내는 것이 무엇인지 물어보세요. 결제 시스템, 헬프데스크, 캘린더 초대, 사무실 스캐너 같은 것들이요. 전달된 메일과 메일링 리스트 메일은 고칠 수 없는 방식으로 실패해요. Google의 [발신자 FAQ](https://support.google.com/mail/answer/14229414)도 이런 메일에는 정렬을 요구하지 않으니, 이 문제가 해결되길 기다리지 마세요. ### 8~14일 차: 정상 발신원 모두 고치기 `count`가 가장 큰 발신원부터 차례로 처리하세요. 1. **업무용 메일**(Google Workspace, Microsoft 365). 관리 콘솔에서 DKIM을 켜고, 지원한다면 2048비트 키를 쓰세요. SPF에 해당 서비스의 include가 들어 있는지도 확인하세요. 2. **ESP와 마케팅 도구.** 내 `d=`로 서명하도록 도메인 인증을 설정하고, 지원한다면 커스텀 반송 경로도 설정하세요. 3. **헬프데스크, 결제, CRM.** ESP와 같은 방식으로 처리하세요. 내 도메인으로 서명할 수 없는 도구라면, 그 도구가 서명할 수 있는 하위 도메인이나 도구 자체의 도메인을 쓰세요. 4. **쓰지 않는 도구.** include와 셀렉터를 삭제하세요. 그런 다음 SPF 조회 횟수를 다시 세세요. ### 15일 차: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` 격리(quarantine)는 보통 스팸함으로 간다는 뜻이에요. `disposition`이 `quarantine`으로 나온 정상 발신원이 있는지 지켜보세요. 미리 연습해 보고 싶다면 `p=quarantine; t=y`를 쓰세요. RFC 9989를 따르는 수신 측에 `none`을 적용하라고 요청하는 설정이에요. 다만 RFC가 나온 지 몇 달밖에 되지 않아, 아직 모든 수신 측이 `t`를 따르지는 않아요. ### 22일 차: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` `p=reject`를 따르는 수신 측은 실패한 메일을 SMTP 세션에서 거부해요. 다만 RFC 9989는 정책이 유일한 근거일 때는 격리하라고 안내하므로, 일부는 스팸함으로 가요. 같은 RFC는 `p=reject`인 도메인이 “SPF에만 의존해서는 안 되며(MUST NOT)” DKIM으로 서명해야 한다고 해요. 전달 과정에서 SPF는 깨지지만 DKIM은 깨지지 않기 때문이에요. 먼저 모든 발신원에서 정렬된 DKIM을 확인하세요. `rua`는 계속 유지하세요. 다음 분기에 새로 들인 도구는 고객 지원 문의보다 보고서에 먼저 나타날 거예요. ### 계획을 늘려야 할 때 RFC 9989의 7.4절은 사용자가 메일링 리스트에 글을 올리는 도메인은 `p=reject`를 게시하지 “않아야 한다(SHOULD NOT)”고 하고, 그래도 게시한다면 먼저 `p=none`에서 “최소 한 달”, `p=quarantine`에서 “그만큼의 기간”을 보내야 한다고 해요. 대부분의 회사 루트 도메인이 여기에 해당하므로, 루트 도메인에서는 처음 두 단계를 각각 한 달씩 유지하세요. ESP만 쓰는 하위 도메인에는 메일링 리스트 트래픽이 없으니 30일 일정을 그대로 따라도 돼요. ### 하위 도메인 정책: sp=와 np= `p`는 도메인과 그 하위 도메인에 적용돼요. `sp`는 존재하는 하위 도메인에, `np`는 존재하지 않는 하위 도메인에 대해 `p`를 덮어써요. 자체 레코드가 있는 하위 도메인은 그 레코드를 따르고, RFC 9989에 따라 이때는 `sp`가 무시돼요. SPF와 DKIM이 인증된 ESP 한 곳만 쓰는 `mail.example.com` 같은 전용 발신 하위 도메인은 첫날부터 `p=reject`를 게시해도 돼요. 루트 도메인에 `p=none; sp=reject`를 두면 루트 도메인 작업을 마치는 동안 하위 도메인을 보호할 수 있지만, BIMI는 쓸 수 없어요. 메일을 보내지 않는 파킹 도메인은 Microsoft의 SPF 가이드에 따라 `v=spf1 -all` 레코드를 게시하고, `_dmarc`에도 `v=DMARC1; p=reject;` 레코드를 게시하세요. ## 30일 차 이후: BIMI BIMI를 지원하는 받은편지함에서는 인증된 메일 옆에 브랜드 로고가 표시돼요. 요건은 다음과 같아요. | 요건 | 세부 내용 | 출처 | |---|---|---| | DMARC 정책 | 조직 도메인과 From 도메인 모두 `p=quarantine` 또는 `p=reject` | BIMI 초안 | | 하위 도메인 정책 | `sp`를 게시했다면 `none`이 아닐 것 | BIMI 초안 | | 비율 | quarantine일 때 `pct`가 100 미만이면 안 됨 | BIMI 초안 | | 로고 | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, `` 포함, 스크립트나 외부 참조 없음, 루트 요소에 `x=`나 `y=` 없음 | BIMI Group | | 인증서 | Gmail은 VMC(등록 상표 필요, 체크 표시 있음) 또는 CMC(상표 불필요, 체크 표시 없음) 필요 | Google | [BIMI 초안](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/)은 14번째 개정판(2026년 5월)까지 나왔지만, 여전히 RFC 7489를 기준으로 쓴 인터넷 드래프트(Internet-Draft)라서 `pct`가 등장해요. `pct`는 빼고, `t=y`도 설정하지 마세요. 조직 도메인 규칙은 하위 도메인으로 보내는 발신자의 발목을 잡아요. `mail.example.com`이 `p=reject`여도 `example.com`이 `p=none`이면 수신 측은 로고를 표시하면 안 되므로, 루트 도메인도 계획을 끝까지 마쳐야 해요. [BIMI Group의 SVG 가이드](https://bimigroup.org/creating-bimi-svg-logo-files/)는 단색 배경 가운데에 놓인 정사각형 로고를 32 KB 미만으로 만들라고 권장해요. Google은 [2024년 9월에 CMC 지원을 추가했어요](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). [BIMI Group 구현 가이드](https://bimigroup.org/implementation-guide/)에 따른 레코드는 다음과 같아요. ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` 상표 등록에는 몇 달이 걸리니, VMC가 필요하다면 지금 바로 준비를 시작하세요. ## Gmail, Yahoo, Microsoft의 요건 세 곳 중 정책 적용을 요구하는 곳은 없고, DMARC 레코드와 정렬만 요구해요. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | 기준 | 기본 도메인별로 개인 Gmail 계정에 하루 5,000통 가까이, 한 번 도달하면 계속 적용 | 대량 발신자, 수치 없음 | From 도메인별로 outlook.com, hotmail.com, live.com에 하루 5,000통 초과 | | SPF와 DKIM | 둘 다 | 둘 다 | 둘 다 통과해야 함 | | DMARC | 레코드 필수, `p=none` 허용 | 최소 `p=none`, `rua` 적극 권장 | 최소 `p=none` | | 정렬 | SPF 또는 DKIM | SPF 또는 DKIM, 완화 모드도 가능 | SPF 또는 DKIM | | 미준수 시 | 2025년 11월부터 일시적 거부와 영구적 거부 | 명시 안 됨 | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | 출처: [Google 발신자 가이드라인](https://support.google.com/mail/answer/81126)과 [FAQ](https://support.google.com/mail/answer/14229414), [Yahoo 발신자 모범 사례](https://senders.yahooinc.com/best-practices/), Microsoft의 [2025년 4월 공지](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730)와 [5.7.515 지원 페이지](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). Microsoft는 4월 29일 업데이트에서 조치를 정크 메일함 이동에서 거부로 바꾼 뒤, 2025년 5월 5일부터 적용을 시작했어요. Google FAQ는 SPF와 DKIM을 모두 정렬하는 것이 “언젠가는 발신자 요건이 될 것”이라고 하니, 2주 차에 둘 다 정렬해 두세요. 수신 거부와 스팸률에 대해서는 [에이전트가 이메일을 보낼 때도 여전히 적용되는 원칙](/ko/blog/agent-email-deliverability)과 저희 [전달성 가이드](/ko/blog/email-deliverability)를 참고하세요. ## Brew 발신 도메인의 DMARC Brew의 [도메인 설정](https://docs.brew.new/get-started/verify-your-sending-domain)에서는 다음 레코드를 요청해요. - **DKIM**: 발신 도메인 아래 `._domainkey` 셀렉터에 두는 TXT 레코드. 필수예요. - **SPF**: Brew의 반송 경로인 `send.<your sending domain>`에 두는 MX 레코드와 TXT 레코드. 필수예요. - **DMARC**: `_dmarc.<your sending domain>`에 두는 TXT 레코드. 선택 사항이지만 권장해요. - 클릭 추적용 **CNAME**: 커스텀 추적 하위 도메인을 쓸 때만 필요해요. SPF와 DKIM이 인증되면 그 도메인으로 발송할 수 있고, Brew가 도메인에 맞는 DMARC 값을 제안해요. ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` 전용 하위 도메인에는 `p=reject`를 제안해요. Brew의 SPF와 DKIM이 인증되기 전에는 그 도메인으로 아무것도 발송되지 않기 때문이에요. 루트 도메인에는 `p=none`을 제안해요. 다른 도구도 그 도메인으로 발송하고 있을 가능성이 높으니, 위의 계획을 따르세요. `send.<domain>` 반송 경로는 완화 모드에서만 정렬되므로 정렬은 완화 모드로 유지해요. Brew는 도메인을 추가하거나 인증할 때, 그리고 다시 확인할 때마다 현재 게시된 `_dmarc.<sending domain>` 레코드를 읽어요. 결과는 **도메인**에서 볼 수 있고, MCP의 `get_domain_health` 도구와 `GET /v1/domains/{domainId}/health` 엔드포인트로도 확인할 수 있어요. - **`dmarc_missing`**: 추가해야 할 정확한 레코드를 알려 주는 경고. - **`dmarc_invalid`**: 같은 이름에 DMARC 레코드가 두 개 있거나, 버전이나 정책이 잘못됐거나, 태그가 중복된 경우. 삭제할 레코드를 알려 줘요. - **인증됨**: 유효한 레코드를 정확히 하나 찾았을 때. 자동 DNS 설정은 DMARC 레코드가 없을 때만 레코드를 작성하므로, 레코드가 중복으로 생기지 않아요. 확인은 상위 도메인이 아니라 발신 도메인에서 이뤄지므로, 발신용 하위 도메인마다 레코드를 따로 두세요. 문서의 권장대로 마케팅 메일과 [트랜잭션 메일](/ko/blog/transactional-emails)을 분리한다면 트랜잭션용 하위 도메인에도 레코드가 필요해요. 보고서를 읽고 reject로 넘어갈 시점을 정하는 곳은 `rua` 보고서 처리 서비스예요. ## 자주 묻는 질문 ### quarantine으로 넘어가기 전에 p=none을 얼마나 유지해야 하나요? 모든 정상 발신원이 정렬된 SPF 또는 DKIM을 통과한다는 것이 꼬박 한 주 동안의 보고서로 확인될 때까지예요. 발신용 하위 도메인이라면 보통 1~2주 걸려요. 직원들이 일상 업무 메일에 쓰는 도메인이라면 RFC 9989는 최소 한 달을 요구해요. 아무도 보고서를 읽지 않는다면 `p=none`을 2년 동안 유지해도 아무 의미가 없어요. ### DMARC pct 태그는 폐지됐나요? 네. RFC 9989는 `pct`를 “historic”(폐지)으로 분류하고, 확실하게 동작하던 두 값만 `t` 태그로 대체해요. `t=y`는 `pct=0`처럼, `t=n`은 `pct=100`처럼 동작해요. 구형 수신 측은 아직 `pct`를 읽을 수 있지만 중간값을 일관되게 적용한 적이 없으니, 정책은 중간값 없이 한 단계씩 온전히 넘어가세요. ### p=reject로 바꾸면 전달된 이메일이 차단되나요? 단순 전달은 보통 SPF는 깨뜨리지만 DKIM은 깨뜨리지 않으므로, 정렬된 DKIM은 여전히 통과해요. 제목이나 푸터를 수정하는 메일링 리스트는 DKIM을 깨뜨리고, 일부는 이를 보완하려고 From 헤더를 다시 써요. 모든 발신원에 정렬된 DKIM을 적용하는 것이 가장 좋은 대비책이에요. ### Gmail과 Yahoo는 p=reject를 요구하나요? 아니요. 두 곳 모두 대량 발신자에게 DMARC 게시를 요구하지만 `p=none`도 허용해요. Outlook.com으로 하루 5,000통 넘게 보내는 발신자에 대한 Microsoft의 기준도 마찬가지예요. 정책 적용은 스푸핑을 막아 주고 BIMI에도 필요하지만, 세 곳 중 정책 적용을 요구하는 곳은 없어요. ### BIMI를 쓰려면 VMC가 필요한가요? Gmail에서는 VMC나 CMC가 필요해요. VMC는 등록 상표가 있어야 하고 체크 표시가 함께 나오며, CMC는 체크 표시 없이 로고를 보여 줘요. [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/)에 따르면 Yahoo와 Fastmail을 비롯한 몇몇 메일 서비스 제공업체는 인증서 없이 자체 선언한 로고도 보여 줘요.