Microsoft 365 / 메일용 DNS 레코드와 SPF·DKIM·DMARC 확인 방법

Microsoft 365 메일 도메인에서는 MX가 수신 서버를 지정하고, SPF·DKIM·DMARC가 발신 메일의 인증과 처리 정책에 관여합니다. 이 레코드는 서로 대체되지 않습니다. 도메인 소유권 확인을 마친 뒤 실제 발송 경로를 조사하고, Microsoft 365와 외부 발송 서비스 모두를 반영해야 합니다.

네 가지 레코드의 역할

Microsoft의 메일 인증 배포 지침은 사용자 지정 도메인에 SPF, DKIM, DMARC를 설정하도록 안내합니다. DMARC는 SPF나 DKIM 중 하나만 성공했다고 항상 통과하는 것이 아니라 표시된 발신 도메인과의 정렬 조건도 봅니다.

SPF는 Sender Policy Framework로 발송 서버의 허용 범위를 선언하는 방식입니다. DKIM은 DomainKeys Identified Mail로 메일에 전자서명을 붙이는 방식이며, DMARC는 Domain-based Message Authentication, Reporting and Conformance로 표시된 발신 도메인과 인증 결과를 대조하고 실패 처리·보고 정책을 전달하는 방식입니다.

SPF가 확인하는 주소는 사용자가 읽는 From과 다른 MAIL FROM(서버 간 전송에 쓰는 봉투 발신 주소)일 수 있습니다. DKIM의 서명 도메인도 서비스 업체 도메인일 수 있습니다. 따라서 CRM이 자기 업체 도메인으로 SPF·DKIM을 통과했더라도 화면에 표시한 회사 도메인과 정렬되지 않으면 회사 도메인의 DMARC를 통과하지 못할 수 있습니다. 정렬된 SPF 또는 정렬된 DKIM 중 하나 이상이 통과해야 한다는 점이 핵심입니다.

설정 전에 발송 경로 조사하기

• 직원이 Exchange Online에서 보내는 메일
• 웹사이트 문의 양식, CRM, 마케팅 서비스, 복합기 등 외부 시스템이 보내는 메일
• 하위 도메인을 별도로 사용하는 발송 서비스
• 메일 보안 게이트웨이나 중계 서버를 거치는 경로

발송원을 빠뜨리면 SPF·DKIM·DMARC 강화 후 정상 메일이 거부될 수 있습니다. 사용하지 않는 발송원은 제거하고, 필요한 서비스는 해당 제공자의 공식 안내에 맞춰 인증합니다.

Microsoft 365에서 확인하는 순서

1. Microsoft 365 관리 센터의 [설정] → [도메인]에서 대상 도메인을 열고 DNS 설정 상태를 확인합니다. MX 값은 해당 도메인 마법사에 표시된 값을 사용합니다.

2. DNS 호스팅 업체에서 현재 SPF TXT 레코드를 확인합니다. Microsoft 365 외 발송원을 포함해야 한다면 기존 값을 통합해 설계합니다.
3. Microsoft Defender 포털의 메일 인증 설정에서 해당 사용자 지정 도메인의 DKIM 상태와 필요한 DNS 레코드를 확인합니다. 제시된 값을 DNS에 추가한 뒤 서명 활성화를 확인합니다.

4. DMARC를 단계적으로 도입합니다. 보고서를 통해 실제 발송원과 인증 실패를 분석한 뒤 정책 강화를 결정합니다. 정책 문구만 추가하고 보고서를 읽지 않으면 문제를 발견하기 어렵습니다.
5. 조직 외부 주소로 테스트 메일을 보내고 수신 측 헤더에서 SPF·DKIM·DMARC 결과와 정렬 여부를 확인합니다. DNS 상태가 정상이어도 실제 발송 경로를 시험해야 합니다.

SPF 예시를 그대로 써도 되는 조건

인터넷 DNS를 직접 관리하는 사용자 지정 도메인에서 Microsoft 365만 발송원으로 사용하는 경우에는 다음 TXT 값이 기본 예시가 됩니다. 웹사이트나 마케팅 서비스가 같은 도메인으로 직접 발송한다면 이 예시만으로 교체하지 마세요. 실제 마법사와 각 발송 서비스의 공식 설정을 대조해야 합니다.

v=spf1 include:spf.protection.outlook.com -all

include는 Microsoft 365 발송 범위를 참조하고 -all은 여기에 맞지 않는 발송원을 SPF 실패로 처리하도록 선언합니다. 같은 이름에 SPF TXT를 두 개 만들어 Microsoft 365와 외부 서비스를 따로 넣는 방식은 잘못된 구성입니다. 필요한 발송원을 하나의 SPF 정책으로 설계하고 불필요한 발송원을 정리하세요. SPF 이외의 소유권 확인 TXT는 목적이 다르므로 제거 대상이 아닙니다. Microsoft SPF 설정 지침의 발송 시나리오를 기준으로 선택합니다.

DKIM과 DMARC를 설정할 때 선택할 값

Defender 포털의 메일 및 공동 작업 → 정책 및 규칙 → 위협 정책 → 메일 인증 설정 → DKIM에서 사용자 지정 도메인을 엽니다. 필요한 경우 키 생성 과정을 진행하고 도메인 상세에 표시된 두 CNAME의 이름과 대상을 DNS 업체에 입력합니다. 선택기와 대상 이름은 현재 테넌트가 제시하는 값을 복사하며 예전 블로그의 문자열을 조합해 만들지 않습니다.

DNS 반영 후 도메인의 DKIM 서명 토글을 활성화하고 서명 중인지 확인합니다. CNAME 누락 상태라면 입력 이름, 실제 DNS 관리 업체와 감지 시각을 다시 확인하세요. 두 레코드를 저장한 것만으로 서명이 켜졌다고 판단하지 않습니다. DKIM 공식 설정 절차에서 현재 상태별 진행 방법을 확인할 수 있습니다.

DMARC의 시작 정책은 정상 발송원을 분석할 수 있는 보고 중심 구성으로 정할 수 있습니다. 아래는 example.com을 설명용 도메인으로 사용한 예시입니다. 실제 도메인의 _dmarc TXT에 넣을 값은 조직이 받을 수 있는 보고서 주소로 바꿉니다.

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

p=none은 DMARC 실패 자체에 대해 격리·거부를 요청하지 않는 시작 정책이며, 다른 스팸·보안 필터까지 해제하지는 않습니다. rua는 집계 보고서를 받을 주소입니다. 해당 주소를 실제로 수신·분석할 준비가 있어야 하고, 외부 보고 서비스 주소를 쓰면 추가 DNS 승인 조건도 확인해야 합니다. 정상 발송원의 정렬과 전달 경로를 확인한 뒤 quarantine, reject 단계로 강화합니다. 자세한 조건은 DMARC 도입 지침을 따릅니다.

DNS 통과와 실제 메일 인증을 함께 확인하기

직원 메일, 웹 문의 양식, CRM 등 발송 경로마다 외부 시험 주소로 새 메일을 보냅니다. 수신 측에서 메시지 원본·인터넷 헤더를 열어 Authentication-Results의 SPF·DKIM·DMARC 결과를 보고, DKIM의 서명 도메인과 표시 From도 대조합니다. “예전 메일은 정상”보다 변경 뒤 새로 보낸 메시지의 결과가 필요합니다.

DNS가 정상인데 특정 CRM만 실패한다면 그 경로의 발송 도메인·서명 설정부터 확인합니다. 전달 과정에서 서명된 본문이 바뀌거나 발송 서버가 달라지면 결과가 달라질 수도 있습니다. 인증 통과는 받은 편지함 배달을 보장하지 않으며 평판·스팸·콘텐츠 정책도 영향을 줍니다.

레코드 값은 도메인과 설정 시점에 따라 달라집니다. 이 글의 목적은 값을 외워 넣는 것이 아니라 관리 센터가 제시한 값, DNS의 실제 값, 수신 측 인증 결과를 서로 대조하는 것입니다. 메일 수신 또는 발신 문제가 발생하면 변경 전 DNS 기록을 기준으로 영향 범위를 파악하세요. 정상 메일이 영향을 받으면 직전 정책과 발송원 구성을 비교해 문제가 된 변경만 복구하고 다시 시험합니다. 원인을 모른 채 SPF·DKIM·DMARC 레코드를 모두 삭제하거나 강한 DMARC 정책을 계속 유지하지 않습니다. 보고서에서 정상 발송원의 실패와 의심스러운 위조 발송을 구분해 후속 조치를 정하세요.