
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Fri, 17 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/dmarc/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-17-dmarcbis-rfc-9989-what-actually-changed</guid>
    <title>DMARC가 11년 만에 표준이 되다 — RFC 9989의 트리 워크, pct 폐지, 그리고 p=reject 경고</title>
    <link>https://www.youngju.dev/blog/2026-07-17-dmarcbis-rfc-9989-what-actually-changed</link>
    <description>2015년 3월부터 이메일 인증의 사실상 표준이었던 DMARC(RFC 7489)는 사실 IETF 합의를 거치지 않은 Informational 문서였습니다. 2026년 5월 IETF가 이를 RFC 9989(본체), RFC 9990(집계 리포트), RFC 9991(실패 리포트) 세 개의 Standards Track 문서로 교체하면서, DMARC는 11년 만에 정식 인터넷 표준이 됐습니다. 조직 도메인 판별이 Public Suffix List에서 DNS 트리 워크(최대 8쿼리)로 바뀌었고, pct 태그가 폐지되고 t·np·psd 태그가 들어왔으며, p=reject 도메인의 SPF 단독 의존이 금지되고 DKIM 서명이 의무가 됐습니다. 반면 v=DMARC1 버전 문자열과 기존 레코드는 그대로 유효해서 당장 고쳐야 할 것은 거의 없습니다. 이 글은 바뀐 것과 안 바뀐 것, 전환기의 상호운용성 리스크(PSL 수신자와 트리 워크 수신자의 불일치), 그리고 RFC가 스스로 인정한 한계 — 여전히 못 푼 메일링 리스트 문제와 아직도 Experimental인 ARC — 를 RFC 원문 기준으로 정리합니다.</description>
    <pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>email</category><category>dmarc</category><category>dns</category><category>security</category><category>rfc</category>
  </item>

    </channel>
  </rss>
