메일 안 보내는 도메인도 DMARC가 필요한 이유: 호스팅케이알에 넣어 봤다

메일을 보내지 않는 도메인에도 DMARC 레코드를 넣어 두는 게 좋습니다. 블로그용으로만 쓰는 도메인이라도 남이 그 주소를 사칭해 메일을 보낼 수 있기 때문입니다. 831223.com에 실제로 넣어 봤고, 그 과정과 막힌 부분을 정리했습니다. 아래 내용은 2026-11-09 기준입니다.

목차

1. 한눈에 보기
2. 메일을 안 보내는데 왜 넣나
3. NCSC가 권하는 레코드 4개
4. 직접 넣어 보니 (831223.com)
5. 확인하기
6. 정리
7. 참고 자료

시작은 메일 중계 업체 MailRoute의 블로그 글이었습니다. 2026-11-06에 올라온 글로, 2026-11-05부터 Outlook.com·Hotmail·Live·MSN이 DMARC 레코드가 없는 도메인의 메일 일부를 거부한다는 내용입니다. 반송 문구는 이렇다고 합니다.

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

첫날에는 괄호 안 코드 없이 왔다고 합니다. 소량 발송자도 걸렸다고 합니다. 일부만 반송되기 때문에 "내 메일은 잘 간다"가 안전하다는 뜻은 아니라는 지적도 있습니다.

다만 이건 한 메일 업체의 관찰입니다. 11월 6일 기준으로 마이크로소프트의 공지는 없었습니다. postmaster 공지, 블로그, 서비스 상태 어디에도 없었다고 MailRoute도 밝혔습니다. MailRoute는 메일 중계 업체라서 이 주제에 이해관계가 있다는 점도 감안해야 합니다.

마이크로소프트가 공식으로 밝힌 규칙은 따로 있습니다. 2025-04-02에 게시한 공지로, 대상은 Outlook.com 소비자 서비스(hotmail.com, live.com, outlook.com)입니다. 하루 5,000통 넘게 보내는 도메인은 SPF와 DKIM을 통과하고, DMARC를 최소 p=none으로 두고 정렬해야 합니다. 2025-05-05부터 적용됐습니다. 공지(2025-04-29 갱신)에 따르면 기준을 못 맞춘 메일은 아래 문구로 거부됩니다.

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

공식 FAQ는 5,000통 미만인 도메인도 이 설정을 갖추면 좋다고 답합니다.

한눈에 보기

• 일어난 일: MailRoute가 2026-11-05부터 아웃룩 계열이 DMARC 없는 도메인의 메일 일부를 거부한다고 관찰. 마이크로소프트 공지는 없음
• 공식 규칙: 하루 5,000통 넘게 보내는 도메인은 SPF·DKIM 통과, DMARC 최소 p=none (2025-05-05부터)
• 메일 안 보내는 도메인: 영국 NCSC는 레코드 4개를 권고. SPF -all, DMARC p=reject, Null MX, 빈 DKIM
• 831223.com 결과: SPF와 DMARC는 저장됨. Null MX는 호스팅케이알 관리 화면이 거부. 빈 DKIM은 이번에 넣지 않음
• 확인: 저장 후 몇 분 안에 8.8.8.8, 1.1.1.1, ns1.hosting.co.kr에서 SPF와 DMARC가 모두 조회됨

메일을 안 보내는데 왜 넣나

메일을 보내지 않는 도메인도 위장(스푸핑)과 피싱에 쓰일 수 있습니다. 내가 메일을 안 보낸다고 남도 내 도메인 이름으로 메일을 안 보내는 건 아닙니다.

영국 NCSC의 글 "Protecting parked domains for the UK public sector"가 이 문제를 다룹니다. 2019-06-26에 게시됐고 2025-03-05에 검토됐습니다. 요지는 "먼저 보호하라. 쉽고, 한 번 하면 관리가 필요 없다"입니다.

여기서 주의할 점이 있습니다. 메일을 보내는 도메인은 p=reject로 시작하면 안 됩니다. p=reject는 DMARC 검사에 실패한 메일을 거부하라는 뜻입니다. DMARC를 통과하려면 SPF나 DKIM이 From 도메인과 정렬된 채로 통과해야 하는데, 설정이 덜 된 상태라면 내가 보낸 정상 메일까지 거부될 수 있습니다. 그래서 MailRoute도 마이크로소프트도 p=none에서 시작하라고 하고, 마이크로소프트 FAQ는 none → quarantine → reject 순서로 올리라고 권합니다. 같은 FAQ에서 위장 방지에 가장 효과적인 값으로 꼽는 것이 p=reject입니다. 아래 값은 메일을 보내지 않는 도메인용이니, 회사 메일이나 뉴스레터를 보내는 도메인에 그대로 복사하지 마세요.

NCSC가 권하는 레코드 4개

NCSC는 아래 순서대로 넣으라고 안내합니다.

▲ 메일을 보내지 않는 도메인에 넣는 레코드 4개와 831223.com 적용 결과

1. SPF: 루트(@)에 TXT v=spf1 -all. 이 도메인에서 메일을 보내는 서버는 없다고 밝히는 값입니다.
2. DMARC: _dmarc에 TXT v=DMARC1; p=reject. 이 도메인을 쓴 메일이 인증에 실패하면 거부하라는 뜻입니다. 보고서를 받는 rua 항목은 선택입니다.
3. Null MX: A 레코드가 있는데 MX가 없으면 MX 0 .을 넣습니다. 이 도메인으로는 메일을 받지 않는다는 표시입니다.
4. 빈 DKIM: 와일드카드 *._domainkey에 TXT v=DKIM1; p=. 공개 키 자리가 비어 있는 DKIM 레코드입니다. NCSC도 필수는 아니라고 분류합니다.

Null MX가 왜 필요한지는 RFC 7505에 나옵니다. MX가 없으면 보내는 쪽은 A나 AAAA 레코드로 배달을 시도합니다. 거기에 메일을 받을 서버가 없으면 보통 일주일 동안 재시도합니다. Null MX가 있으면 배달 시도가 바로 실패합니다.

직접 넣어 보니 (831223.com)

831223.com은 티스토리 블로그 전용 도메인입니다. 메일을 보내지도 받지도 않습니다. 작업은 AI(Claude)가 관리 화면에서 실행했고, 넣을 값은 제가 확인하고 승인했습니다.

작업 전에 조회해 보니 _dmarc TXT, SPF, MX가 모두 없었습니다. 네임서버는 ns1~4.hosting.co.kr이고, 호스팅케이알 관리 화면에는 블로그 연결용 레코드가 있었습니다(블로그와 관계없는 서브도메인 레코드 하나는 생략).

• A @ 27.0.236.139
• CNAME www host.tistory.io

TTL은 둘 다 180입니다. A @가 있고 MX가 없으니 NCSC 기준으로 Null MX 대상입니다.

호스팅케이알에서 레코드 추가하는 경로

1. app.hosting.kr에 로그인합니다.
2. 나의 도메인 → 831223.com 상세로 들어갑니다.
3. 네임서버/DNS 탭 → DNS 레코드 관리 → + 새 레코드 추가를 누릅니다.
4. 유형(A, CNAME, MX, SRV, TXT 중 선택), 호스트 이름, 값, TTL을 입력합니다. 호스트 이름에는 도메인 이름을 빼고 적고, 루트는 @입니다. TTL 기본값은 180입니다.

MX를 고르면 값 칸이 "우선순위"와 "MX 서버" 두 칸으로 나뉩니다.

넣은 결과

1. TXT @ v=spf1 -all → 저장됐습니다. "요청이 완료되었습니다." 메시지가 떴습니다.
2. TXT _dmarc v=DMARC1; p=reject → 저장됐습니다.
3. MX @ 우선순위 0, MX 서버 . → 거부됐습니다. 입력 칸 아래에 "Only valid hostnames can be entered."라는 오류가 나왔습니다.
4. 와일드카드 빈 DKIM → 이번에는 넣지 않았습니다.

Null MX가 막힌 이유는 RFC 7505 원문에 그대로 있습니다. "'.'은 올바른 호스트 이름이 아니므로 일반 MX와 헷갈릴 일이 없다"(Since "." is not a valid host name ...)는 설명입니다. Null MX는 일부러 호스트 이름이 아닌 값을 쓰는 방식이고, 관리 화면은 MX 서버 칸에 올바른 호스트 이름만 받으니 검증에 걸린 겁니다.

가짜 호스트 이름을 넣어 우회하는 방법은 쓰지 않았습니다. 가짜 호스트를 넣으면 그건 Null MX가 아니라 일반 MX 레코드가 됩니다. NCSC도 "인터페이스에 따라 네 가지를 다 못 넣을 수 있다. 가능한 만큼 넣어라"고 적어 두었습니다. 그래서 SPF와 DMARC 두 개로 마무리했습니다.

작업 후에는 기존 레코드에 TXT 두 개(@의 SPF, _dmarc)가 더해졌습니다.

확인하기

윈도우에서는 PowerShell의 Resolve-DnsName으로 확인합니다. 저장 직후 몇 분 안에 조회했습니다.

Resolve-DnsName 831223.com -Type TXT -Server 8.8.8.8
Resolve-DnsName _dmarc.831223.com -Type TXT -Server 8.8.8.8
Resolve-DnsName 831223.com -Type MX -Server 8.8.8.8

▲ Resolve-DnsName으로 SPF, DMARC, MX를 조회한 결과

• 첫 번째 명령은 v=spf1 -all을 돌려줬습니다.
• 두 번째 명령은 v=DMARC1; p=reject를 돌려줬습니다.
• 세 번째 명령은 MX 응답 없이 SOA만 돌려줬습니다. Null MX를 못 넣었으니 MX가 없는 상태 그대로입니다.

TXT 두 개는 -Server를 ns1.hosting.co.kr이나 1.1.1.1로 바꿔도 결과가 같았습니다.

macOS나 리눅스에서는 dig를 씁니다. example.com 자리에 내 도메인을 넣습니다.

dig +short TXT _dmarc.example.com

정리

메일을 보내지 않는 도메인이라면 SPF v=spf1 -all과 DMARC v=DMARC1; p=reject 두 줄은 지금 넣어 둘 만합니다. 한 번 넣으면 더 관리할 게 없습니다. Null MX는 관리 화면이 받아 주면 넣고, 호스팅케이알처럼 막히면 가짜 값으로 우회하지 말고 넘어갑니다. 메일을 보내는 도메인이라면 p=reject가 아니라 p=none부터 시작합니다.

아웃룩 반송 이야기는 아직 한 업체의 관찰이고, 마이크로소프트가 공지한 내용이 아닙니다.

참고 자료

• MailRoute: Outlook rejecting email without DMARC (2026-11-06)
• Microsoft Tech Community: 아웃룩 대량 발송자 요구 사항 (2025-04-02)
• NCSC: Protecting parked domains for the UK public sector
• RFC 7505 (Null MX) (2015-06)

---

이 글은 AI(Claude)가 자료를 확인해 초안을 쓰고, 호스팅케이알 DNS 작업도 AI가 실행했습니다. 저는 넣을 값을 확인해 승인하고, 원고를 처음부터 끝까지 읽고 확인했습니다. 글에 들어간 도식도 AI와 함께 만들었습니다.