Outlook.com, DMARC 레코드가 없는 도메인의 메일 거부: 실제 변경 사항은 무엇인가?

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

이 한 줄의 메시지가 전체 이야기이며, 이제는 평생 대량 메일 규칙을 다뤄본 적 없는 소규모 비즈니스의 로그에 나타나고 있습니다. 2026년 11월 5일부터 마이크로소프트(Microsoft)의 소비자 메일 서비스인 outlook.com, hotmail.com, live.com 및 msn.com은 DMARC 레코드를 게시하지 않은 모든 발신 도메인의 메시지를 반송하고 있습니다. 대량 발송자에게만 국한되지 않습니다. 마케터들에게만 국한되지도 않습니다. 두 명으로 구성된 사무실에서 온 한 줄짜리 답장 메일이 반송될 수 있는 반면, 같은 사서함에서 오는 다음 메일은 문제없이 전달됩니다. 아무도 이 사실을 발표하지 않았으며, 해결책은 단 하나의 DNS TXT 레코드입니다. 본 글에서는 이 변경 사항에 대해 실제로 알려진 바가 무엇인지, 마이크로소프트가 발표했던 규칙과 어떻게 다른지, 1분 안에 자신의 도메인을 확인하는 방법, 그리고 아무것도 망가뜨리지 않으면서 이 구멍을 막는 방법을 안내합니다.

아무도 발표하지 않은 메일 반송

첫 공개 내용은 이메일 필터링 회사인 MailRoute에서 11월 6일에 작성되었습니다. 그들의 엔지니어들은 11월 5일에 자체 발신 로그에서 거부 메시지를 발견했고, 다른 관리자들 역시 같은 날 동일한 행동을 보고하고 있음을 확인했습니다. 이후 올라온 Hacker News 스레드에서, Hetzner에 작은 서버를 운영하는 한 관리자는 11월 1일경부터 이미 같은 거부 메시지를 보았다고 보고했으며, Intercom의 발신자는 자신들의 트래픽 전반에 걸쳐 반송이 눈에 띄었음을 확인했습니다. 반송 메시지 끝에 붙은 대괄호 안의 코드는 메시지마다 다릅니다—MailRoute의 로그에서는 AS9031519였고, 다른 관리자들의 보고서에서는 AS9712514 등 다른 값이었습니다—이는 단일 문서화된 규칙이라기보다는 여러 다른 수신 필터 전반에 걸쳐 검사가 이루어지고 있음을 시사합니다.

이 거부 메시지는 일반적인 스팸 차단과 다른 세 가지 특징을 가지고 있습니다. 첫째, 부분적입니다. Hotmail 주소로 보내는 메시지 중 일부는 통과하고, 다음 메시지는 반송되며, 재전송은 성공할 수 있습니다. 둘째, 수신 측에서는 조용합니다. outlook.com 주소의 고객은 메시지가 전송되었다는 사실을 전혀 알지 못합니다. 셋째, 문구 자체가 정보 제공 없이 경고적입니다. “SPF/DKIM/DMARC 인증 기록 부족(lacks SPF/DKIM/DMARC Auth Records)”이라는 문구는 전체적인 인증 실패처럼 들리지만, 실제로 반송된 대부분의 도메인은 작동하는 SPF를 가지고 있었고 많은 경우 DKIM도 사용하고 있었습니다. 이들이 놓치고 있던 것은 해당 메커니즘들을 From 주소에 연결해 주는 DMARC 기록이었습니다.

MailRoute가 11월 6일에 게시한 시점까지, Microsoft는 이 변경 사항에 대해 아무것도 발표하지 않았습니다. 포스트마스터 공지(postmaster notice)도 없고, 블로그 글도 없으며, 서비스 상태 메시지도 없었습니다. 그리고 두 번째 반전이 있습니다. 11월 9일과 10일에 테스트를 진행한 관리자들은 거부 메시지가 점차 사라지는 것을 보고했습니다. 한 사용자가 기록(recordless)이 없는 도메인에서 hotmail.com 주소로 메시지를 보내고 그것이 도착하는 것을 지켜보았습니다. 이러한 패턴은 운영 환경에서 조정되는 단계적 배포(staged rollout)를 시사하거나, 롤백(rollback)이 진행 중임을 나타냅니다. 어느 쪽이든, 이를 일회성 결함으로 간주하는 것은 잘못된 해석입니다. 이는 리허설로 받아들여야 합니다.

마이크로소프트가 실제로 발표한 규칙

Microsoft는 문서화된 발신자 요구 사항을 가지고 있으며, 새로운 반송 메시지는 그 어떤 것도 명확하게 일치하지 않습니다. 2025년 4월에 이 회사는 Outlook.com으로 하루 5,000개 이상의 메시지를 보내는 도메인은 SPF, DKIM, DMARC를 통과해야 하며, 시행은 2025년 5월 5일부터 시작한다고 발표했습니다. 해당 규칙의 문서화된 비전달 응답(non-delivery reply) 코드는 완전히 다른 코드입니다:

550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level

이 요구 사항은 명시적으로 대량 발신자(high-volume senders)에게만 적용되었으며, 중소기업들은 이것이 자신들에게는 적용되지 않을 것이라고 합리적으로 가정했습니다. 11월의 거부 메일은 규모에 관계없이 모든 발신자에게 도달하며, 문서화된 5.7.515 대신 일반적인 5.7.1 오류 코드로 도착합니다. 이와 같은 계열에는 더 오래된 문서화된 동작 방식이 하나 있습니다: 2023년 7월부터 소비자 서비스는 발신자가 DMARC 정책을 게시했을 경우, 해당 도메인이 p=reject를 게시하면 유효성 검사에 실패한 메일을 거부하며 NDR 코드 5.7.509로 처리해 왔습니다. 하지만 이 메커니즘은 애초에 DMARC 레코드가 존재해야 작동합니다. 새로운 동작 방식은 아예 기록이 없는 도메인을 목표로 하며, 이는 게시된 규칙들이 한 번도 건드리지 않았던 집단입니다.

적어도 업계의 방향성은 놀랍지 않습니다. Google과 Yahoo는 2024년 2월부터 대량 발신자에게 DMARC를 요구하기 시작했으며, Microsoft의 2025년 4월 게시물도 같은 흐름을 따랐습니다. 새로운 점은 기준선이 떨어지고 있다는 것입니다: 인증(authentication)이 무거운 발신자들의 요구 사항에서 모든 사람의 요구 사항으로 이동하고 있으며, 이는 문서화보다 시행(enforcement)을 통해 일어나고 있습니다.

하나의 레코드에 담긴 DMARC

DMARC — Domain-based Message Authentication, Reporting and Conformance(도메인 기반 메시지 인증, 보고 및 준수)는 RFC 7489에서 지정되었으며, 도메인의 예측 가능한 이름 아래 _dmarc라는 단일 TXT 레코드입니다. 11월 10일의 실제 조회 기록들은 게시된 규칙이 어떤 범위를 가지는지 보여줍니다:

_dmarc.google.com       "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.microsoft.com    "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
_dmarc.soup.place       "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected];"

태그들은 간단합니다. v=DMARC1은 버전을 선언합니다. p=는 수신자가 유효성 검사에 실패한 메일에 적용해야 할 정책을 명시하며, 그 옵션은 none (아무것도 하지 않고 보고만 함), quarantine(격리), 또는 reject(거부)입니다. sp=는 서브도메인에 대해 동일하게 작동하며, pct=는 트래픽의 일정 비율로 시행을 제한하고, rua/ruf는 집계 및 포렌식 보고서용 주소를 나열합니다. adkim과 aspf 태그는 정렬(alignment) 엄격성을 설정하는데, 둘 다 기본값이 relaxed이므로 대부분의 레코드에서 이들을 생략합니다. Microsoft 자체 레코드는 모든 메커니즘이 실패했을 때가 아니라 단 하나의 메커니즘이라도 실패할 경우에 보고를 요청하는 fo=1을 추가합니다.

30초 만에 도메인 확인하기

이 거부(rejection)가 목표로 하는 검사는 하나의 명령어로 수행됩니다. 터미널에서 임의의 도메인을 본인의 도메인으로 대체하여 실행해 보세요:

dig +short TXT _dmarc.example.com
snlookup -type=TXT _dmarc.example.com 8.8.8.8

v=DMARC1로 시작하는 라인은 레코드가 있다는 의미입니다. 출력이 비어 있거나 도메인 자체가 존재하지 않는 답변은 레코드가 없다는 뜻이며, 이것이 바로 새로운 거부 정책의 대상이 되는 정확한 집단입니다. 2026년 11월 10일의 실시간 검사 결과는 두 가지 결과를 모두 보여줍니다: _dmarc.pigshell.com과 _dmarc.foldableflight.com은 현재 아무것도 반환하지 않지만, _dmarc.soup.place는 위에서 보여준 격리(quarantine) 레코드를 반환합니다. 참고로 IANA 문서화 도메인인 example.com조차도 오늘 엄격한 레코드(v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s)를 게시하고 있다는 점은 기준선이 얼마나 많이 이동했는지에 대한 공정한 척도가 됩니다.

여러 도메인에 걸쳐 반복 가능한 감사를 수행하려면 짧은 스크립트가 수동 조회를 능가합니다. 이 스크립트는 DMARC 레코드를 확인하고, 정책을 추출하며, 최상위(apex)에 SPF 레코드가 존재하는지 검증합니다:

import dns.resolver

def txt_records(name):
...

이 스크립트는 pip install dnspython으로 설치할 수 있는 dnspython을 사용합니다. 조직에서 메일을 발송하는 모든 도메인, From 헤더에 여전히 나타나는 주차된 도메인을 포함하여 실행해 보세요.

'일부 메일이 통과한다'가 함정인 이유

새로운 거부(rejection)의 불일치성이 비용을 발생시키는 원인입니다. 발신자는 약어들로 가득 찬 반송 메일을 보고 재전송하며, 재전송이 성공하는 것을 확인하고 일시적인 오류였다고 결론 내립니다. 한편, 청구서, 예약 확인서, 답장 등은 공허함 속으로 사라지고 있으며, Microsoft 주소의 담당자들은 이 어떤 것도 볼 수 없습니다. MailRoute의 경고는 단호합니다. 만약 귀하의 비즈니스가 환자, 주택 소유주, 지원자, 부모, 회원과 같은 개인 주소에 도달하는 것에 의존한다면, 이러한 실패 모드의 비용은 조용하고 아무도 불평하지 않는 사이에 축적됩니다.

엔지니어링 관점에서는 부분적인 시행(partial enforcement)이 거의 확실하게 고의적이거나 적어도 부하를 지탱하기 위한 것이라고 봅니다. Outlook.com과 같은 규모의 서비스에 단계적 샘플링 없이 검사를 적용하는 것은 직무 유기입니다. 그리고 다양한 AS 코드와 11월 9일자 감소된 거부 보고서는 조정 중인 시스템을 보여줍니다. 실질적인 결과는 변하지 않습니다. “내 테스트 메시지가 도착했다”는 것이 귀하의 도메인 상태에 대해 아무것도 증명해주지 못하기 때문입니다. 현재 도착과 거부가 동일한 설정에서 공존하고 있기 때문입니다.

단계적 해결책 (The fix, staged)

즉각적인 해결책은 바로 하나의 DNS 레코드입니다. DNS 호스트에서 _dmarc라는 이름의 TXT 레코드를 모니터링 단계 값으로 생성해야 합니다:

Name:   _dmarc
Value:  v=DMARC1; p=none; rua=mailto:[email protected]

p=none 정책은 안전한 시작점입니다. 이 정책은 귀하의 도메인이 DMARC에 참여함을 선언하고 수신자들에게 집계 보고서(aggregate reports)를 보내달라고 요청하지만, 실패 시 어떠한 조치도 취하지 않도록 지시합니다. Gmail, Yahoo 또는 다른 사람이 귀하의 메일을 어떻게 처리하는지에 대해서는 아무것도 변하지 않습니다. 유일한 전제 조건은 정렬(alignment)입니다. From 주소에 있는 도메인에 대해 SPF 또는 DKIM 중 적어도 하나가 통과해야 하며, 그렇지 않으면 이 레코드만으로는 도움이 되지 않습니다. Microsoft 자체 가이드라인은 정확히 이러한 단계적 경로를 권장합니다: 먼저 none을 사용하고, 그다음 quarantine(격리), 그리고 reject(거부)로 이동하며, 보고서가 귀하의 합법적인 출처들이 정렬되었음을 보여줄 때만 진행해야 합니다. Google은 오늘 p=reject를 발표했지만, 이는 과정의 최종 상태일 뿐 진입 티켓이 아닙니다.

두 가지 운영 참고 사항입니다. rua는 실제로 읽을 수 있는 메일박스나 보고서 처리기로 지정해야 합니다. 왜냐하면 집계 XML 보고서는 누가 당신을 대신하여 전송하는 제3자 서비스들을 발견할 수 있는 유일한 방법이기 때문입니다. 그리고 발신 벤더를 감사하세요: 도메인을 From 헤더에 포함시키는 모든 서비스는 자체 SPF include 또는 DKIM 서명 정렬(signing aligned)이 필요합니다. 그렇지 않으면 'none'보다 더 엄격하게 정책을 강화하는 날 DMARC에 실패할 것입니다.

이번 주 할 일

절차는 간단합니다. 소유한 모든 도메인에 대해 조회(lookup)를 실행하세요. 레코드가 누락된 경우, v=DMARC1; p=none; rua=...를 게시하고 두 개의 다른 리졸버에서 해결되는지 확인하십시오. 이미 레코드가 존재하는 경우, 해당 정책이 상속된 것이 아니라 의도적인 것인지, 그리고 가장 큰 발신 스트림들이 정렬(alignment)을 통과하는지 확인하세요. 수신하는 모든 메시지의 Authentication-Results 헤더는 어떤 메커니즘이 어떤 도메인 하에서 통과했는지 알려줍니다. 그런 다음 격리(quarantine)를 고려하기 전에 몇 주 동안 보고서를 모니터링하십시오.

더 광범위한 교훈은 지난 10년간 이메일 관리자들이 반복적으로 배운 것입니다: 인증 기준선(authentication floor)은 공지 없이 상승하고 있으며, 그 아래에 머무르는 비용은 아무도 누락되었다는 것을 모르는 메시지로 지불됩니다. 2026년 11월에 DMARC 레코드가 없는 도메인은 10년 전 SPF 레코드조차 없었던 도메인과 같은 위치에 있습니다. 기술적으로는 허용되지만, 실질적으로는 위험합니다(doomed). 레코드는 게시하는 데 10분이 걸립니다. 반송 메시지(bounce)를 알아차리는 것은 대부분의 기업이 감당할 수 있는 시간보다 더 오래 걸립니다.

본래 게시된 곳: Dispatch.