MX, SPF, DKIM, DMARC 레코드는 어떻게 확인하나요?

MX 레코드는 어떻게 확인하나요?

도메인과 +short를 붙여 dig MX를 실행하고, 우선순위와 호스트 이름을 제공업체가 알려 준 값과 비교하세요. 응답은 레코드마다 한 줄씩, 우선순위, 공백, 호스트 순으로 출력됩니다. Proton Mail은 10 mail.protonmail.ch. 와 20 mailsec.protonmail.ch. 가, Fastmail은 10 in1-smtp.messagingengine.com. 와 20 in2-smtp.messagingengine.com. 가, Mailbox.org는 mxext 호스트 네 개가 나와야 합니다.

여기서 두 가지 문제가 나타납니다. 이전 제공업체의 레코드가 목록에 남아 있으면 배달이 예측 불가능해지므로 삭제하세요. 그리고 응답이 비어 있으면 MX가 없는 것이며, 이 경우 발신자는 RFC 5321에 설명된 대로 도메인의 주소 레코드로 대체합니다. 각 줄의 의미는 MX 레코드란에서 설명합니다.

SPF 레코드는 어떻게 확인하나요?

도메인 루트의 TXT 레코드를 조회하고 v=spf1 로 시작하는 줄이 정확히 하나인지 확인하세요. 루트에는 이메일 제공업체의 소유권 증명 같은 다른 TXT 레코드도 있으므로 전체 목록을 읽으세요. v=spf1 로 시작하는 줄이 두 개이면 오류입니다. RFC 7208은 도메인에 SPF 레코드가 둘 이상이면 영구 오류를 반환합니다.

그다음 조회 횟수를 세세요. include, a, mx, ptr, exists와 redirect 수정자는 각각 한도 10에 포함되며, include는 그 안에 중첩된 것도 함께 셉니다. 한도를 넘는 레코드는 모든 발신자에서 실패합니다. 레코드 작성은 SPF 레코드 만드는 방법에 자세히 나와 있습니다.

셀렉터를 모를 때 DKIM은 어떻게 확인하나요?

제공업체의 셀렉터를 사용하세요. DNS에서는 셀렉터를 나열할 수 없으므로 제공업체의 DKIM 화면에서 가져와야 합니다. DNS는 _domainkey 아래 이름의 목록 조회를 허용하지 않습니다. 셀렉터는 Proton Mail은 protonmail, protonmail2, protonmail3, Fastmail은 fm1, fm2, fm3, Mailbox.org는 MBO0001부터 MBO0004까지입니다.

조회 이름은 selector._domainkey.yourdomain 입니다. 이 세 곳처럼 CNAME 레코드를 쓰는 제공업체는 자체 호스트로의 CNAME으로 응답합니다. 키를 직접 게시하는 제공업체는 v=DKIM1 과 공개 키가 이어지는 p= 가 담긴 TXT 레코드로 응답합니다. p= 가 비어 있으면 키가 폐기된 것입니다. 가장 확실한 테스트는 실제 메시지입니다. 존재하는 레코드도 사용되지 않을 수 있으므로, 다른 제공업체로 메일을 보내 전체 헤더에서 dkim=pass 를 확인하세요.

DMARC 레코드는 어떻게 확인하나요?

_dmarc.yourdomain의 TXT 레코드를 조회하고 v=DMARC1 로 시작하며 p= 정책이 있는 줄이 하나인지 확인하세요. p가 없으면 수신 측은 정책을 none으로 취급합니다. rua가 없으면 집계 보고서가 생성되지 않으며 DMARC 단계별 도입의 모니터링 단계에서 아무 정보도 얻지 못합니다. 이전 방식으로 작성된 레코드에는 RFC 9989가 제거한 pct 태그가 남아 있을 수 있습니다.

자체 레코드가 없는 서브도메인은 DNS 트리 탐색을 통해 최대 8번의 쿼리로 상위 도메인의 정책을 따릅니다. 레코드가 없는 이름을 조회하면 아무것도 반환되지 않으며, 이는 DMARC가 없는 것과 같습니다.

조회하면 왜 아직도 이전 값이 보이나요?

캐시는 TTL이 끝날 때까지 이전 응답을 유지하며, 레코드가 없다는 응답도 캐시될 수 있습니다. 변경이 퍼지는 데 걸리는 시간은 변경 시점에 레코드에 설정되어 있던 이전 TTL 정도입니다. 업체 안내는 일반적인 MX 변경을 1~4시간, 최악의 경우 24~48시간으로 봅니다. RFC 2308은 부정 응답이 영역의 SOA 레코드의 TTL로 캐시되므로, 방금 만든 레코드가 일부 리졸버에서는 없는 것처럼 보일 수 있다고 덧붙입니다.

캐시를 건너뛰려면 권한 있는 네임서버에 직접 물어보세요. dig NS로 찾은 뒤, 위 코드 블록처럼 @와 그 이름을 붙여 쿼리를 반복합니다. 권한 있는 서버에 새 값이 보이는데 리졸버에는 보이지 않는다면 기다리세요. 둘 다 보이지 않으면 레코드가 저장되지 않았거나 호스트 이름이 잘못된 것이며, 가장 흔한 원인은 DNS 편집기가 도메인을 두 번 덧붙인 경우입니다.

레코드가 맞아 보이는데도 메일이 도착하지 않는다면 맞춤 도메인에 이메일이 도착하지 않는 이유로 이동하세요.

이메일 레코드를 확인할 수 있는 온라인 도구는 무엇인가요?

공개 DNS를 조회하는 온라인 DNS 조회 도구나 메일 인증 검사기는 dig와 같은 응답을 더 보기 좋게 표시해 줍니다. 레코드 원문을 보여 주는 도구를 사용하여 제공업체의 값과 글자 단위로 비교할 수 있게 하세요. 개인 데이터를 붙여넣지 마세요. 필요한 것은 도메인 이름뿐입니다.

2026년 11월 12일 Postelva의 집계에 따르면 Proton Mail 전체 설정에는 레코드 8개(확인용 TXT 1, MX 2, SPF 1, DKIM 3, DMARC 1)와 조회 6번이 필요합니다. 두 MX 레코드가 하나의 쿼리를 공유하고, 확인용 레코드와 SPF 레코드가 루트 TXT 쿼리를 공유하기 때문입니다. 여섯 개의 명령을 한 번 저장해 두고 변경할 때마다 다시 실행하세요. 같은 레코드는 SPF vs DKIM vs DMARC에서 비교합니다.

인용할 수 있는 규칙: DNS를 변경할 때마다 네 가지 레코드 유형을 조회하고 테스트 메시지를 보내세요. 조회 결과와 메시지가 일치할 때만 레코드가 올바른 것입니다.