2026 독립몰 주문 메일이 스팸함으로 갈 때, SPF와 DKIM 중 무엇부터 확인할까요?

RFC 9989는 2026년에 발행되어 기존 DMARC 표준 문서인 RFC 7489와 RFC 9091을 대체했습니다 (RFC 9989 표준 정보). 그렇다고 주문 메일 설정을 곧바로 바꿔야 하는 것은 아닙니다. 먼저 발신 서비스 로그에서 메일이 실제로 전송됐는지 확인하고, 전송됐다면 해당 서비스의 SPF·DKIM 설정과 From 도메인 정렬을 살핀 다음 DMARC 정책을 검토하세요. 인증 통과가 받은편지함 도착을 보장하지는 않습니다.

적합한 독자: 고객이 주문 확인이나 배송 알림을 못 받았다고 하는 독립몰 운영자에게 맞습니다.
적합한 독자: 발신 서비스를 바꾸거나 DNS를 수정한 뒤 인증 결과를 확인하려는 기술 담당자에게도 유용합니다.
다른 문제라면: 서버 자체의 이전이나 운영 환경을 점검하려는 경우에는 메일 인증 문제와 서버 설정 문제를 먼저 분리하세요.

먼저 확인할 것은 SPF가 아니라 발신 기록입니다

독립몰 주문 메일이 스팸함에 들어간 것처럼 보여도, 애플리케이션이 메일을 만들지 않았거나 발신 서비스까지 요청을 전달하지 못했을 수 있습니다. 쇼핑몰 플랫폼의 공식 메일 문제 해결 안내도 메일 생성, 서버의 발송 처리, 최종 전달과 스팸 필터링을 구분해 다룹니다.

주문 상태가 완료됐다는 사실만으로 메일이 전송됐다고 판단하지 마세요. 알림 설정이 꺼져 있거나, 주문 상태에 따라 해당 알림이 실행되지 않았을 수 있습니다. 애플리케이션 로그와 제3자 메일 서비스 로그를 함께 확인해야 어느 구간에서 멈췄는지 좁힐 수 있습니다.

제3자 메일 서비스의 SPF 설정과 실제 발신 경로

제3자 메일 서비스를 연결했더라도 SPF 설정이 자동으로 완성되는 것은 아닙니다. 발신 도메인의 DNS에 해당 서비스가 안내한 승인 항목이 반영됐는지 확인하세요. 여러 서비스에서 같은 도메인을 사용한다면, 현재 실제로 발송하는 모든 출처가 고려됐는지도 점검해야 합니다. 다른 서비스의 설정값을 그대로 복사하지 말고, 메일 서비스 연결 안내와 현재 서비스의 도메인 설정 설명을 기준으로 삼으세요.

SPF는 DNS에 게시된 정책으로 발신 서버의 허용 여부를 검사합니다. RFC 7208에 따르면 한 도메인에서 여러 SPF 레코드가 발견되면 평가에 문제가 생길 수 있으므로, 레코드가 중복됐는지 확인하세요 (SPF 표준의 DNS 레코드 처리 규정). 그렇다고 기존 레코드를 지우고 새 서비스의 값만 넣으면 안 됩니다. 다른 업무에서 쓰는 발신 경로까지 끊길 수 있기 때문입니다.

터미널에서 DNS 응답을 확인할 수 있습니다.

dig TXT example.com

출력에서 v=spf1로 시작하는 레코드를 찾아 서비스 안내와 비교합니다. example.com은 확인하려는 발신 도메인으로 바꾸세요. 조회 결과만으로 수신함 도착 여부가 판정되는 것은 아니며, 실제 테스트 메일의 인증 결과와 함께 봐야 합니다. 메일 서비스의 인증 안내도 사용하는 발신 서비스에 맞춰 설정을 확인하도록 설명합니다.

DKIM 통과와 From 도메인 정렬은 별개입니다

DKIM은 메일에 서명을 붙여 서명된 내용과 도메인을 확인하는 방식입니다. 하지만 DKIM 결과가 통과했다고 해서 수신자가 보는 From 주소의 도메인과 서명 도메인이 DMARC 기준에 맞게 정렬됐다고 단정할 수는 없습니다. DKIM 표준과 DMARC의 판정은 각각 확인해야 합니다.

테스트 메일의 원본 헤더에서 Authentication-Results, DKIM-Signature 항목을 찾으세요. DKIM 결과가 통과했는지, 서명 도메인(d=)이 무엇인지 확인한 뒤, 수신자가 보는 From 주소의 도메인과 비교합니다. 서비스별 서명 도메인과 From 주소가 다르다면, 인증 통과와 DMARC 정렬이 모두 성공했는지 추가로 검사해야 합니다.

특정 수신 서비스의 발신자 정책을 모든 메일 서비스에 그대로 적용해서는 안 됩니다. 공식 발신자 안내는 일반 발신자와 특정 기준을 넘는 대량 발신자를 구분하며, 일일 5,000통 초과 발신자에 적용되는 요구 사항도 별도로 설명합니다 (발신자별 인증 및 정렬 안내). 이 기준은 해당 안내의 적용 대상과 조건에 따라 해석해야 하며, 모든 수신 플랫폼의 통일된 규칙으로 확대할 수 없습니다.

DMARC 정책은 발신 출처를 파악한 뒤 조정합니다

DMARC는 SPF 또는 DKIM 인증 결과와 From 도메인의 정렬을 함께 평가합니다. 정책을 강하게 바꾸기 전에 주문 알림 외에 비밀번호 재설정, 배송 알림, 영수증 등 도메인 이름으로 발송되는 업무가 무엇인지 먼저 확인하세요. 누락된 발신 출처가 있으면 정상 메일까지 격리되거나 거부될 수 있습니다.

DNS에서 정책 레코드를 조회하려면 다음처럼 확인할 수 있습니다.

dig TXT _dmarc.example.com

도메인 이름을 바꿔 실행하고, 조회된 정책과 서비스별 인증 결과를 대조하세요. 보고서가 있다면 정상 발신과 실패한 발신을 나눠 살핀 뒤 정책 변경 여부를 결정합니다. RFC 9989는 DMARC 표준 문서의 갱신이지, 기존 독립몰이 자동으로 자체 메일 서버를 도입하거나 설정을 바꿔야 한다는 뜻은 아닙니다 (갱신된 DMARC 표준).

인증 통과 후에도 스팸함에 있다면

SPF, DKIM, DMARC가 통과했는데 메일이 보이지 않는다면 인증만 반복해서 고치지 마세요. 수신 서비스의 스팸함이나 격리 내역, 발신 서비스의 거부·지연 응답, 제목과 본문, 첨부 파일, 수신자 측의 신고나 필터 설정을 확인합니다. 인증은 발신 도메인에 관한 정보를 검증하지만 받은편지함 배치를 보장하지는 않습니다.

테스트 주문을 만들어 서로 다른 수신 환경에서 확인하고, 결과를 기록하세요. 기록에는 테스트 시각, 주문 상태, 애플리케이션 로그, 발신 서비스의 응답, 메일 헤더의 인증 결과를 포함합니다. 이 자료가 있어야 수신 측 문제인지, 발신 서비스가 거부했는지, 도메인 설정이 잘못됐는지 구분하기 쉽습니다.

증거에 따라 고칠 곳을 정하는 조건

다음 조건으로 조치를 선택하세요.

• 애플리케이션과 발신 서비스 모두 전송 기록이 없다면: DNS를 먼저 바꾸지 말고 주문 상태, 알림 설정, 애플리케이션 오류를 확인합니다.
• 서비스 기록은 있지만 SPF 또는 DKIM이 실패한다면: 실제 발신 서비스가 안내한 설정과 DNS 응답을 대조하고, 메일 헤더의 결과까지 확인합니다.
• DKIM은 통과하지만 DMARC 정렬이 실패한다면: 서명 도메인과 From 도메인의 관계를 확인하고, 발신 서비스에서 지원하는 정렬 설정을 검토합니다.
• 인증이 통과했지만 거부되거나 격리된다면: 수신 측 안내와 서비스 응답 코드를 모아 발신 서비스에 문의합니다. 정책을 더 강하게 바꾸는 것은 원인 확인 뒤에 결정합니다.

서버를 옮기거나 운영 환경을 바꾸는 중이라면 메일 전송 문제와 서버 접근 문제를 한 원인으로 묶지 마세요. 서버 서비스 범위 안내를 확인하고, 이전 전후에는 주문 생성부터 메일 수신까지 거래 흐름을 따로 검증해야 합니다. 운영 환경에 접속해 로그를 확인해야 한다면 서버 접속 방식 안내에서 접근 경계를 확인할 수 있습니다.

서버 임대와 메일 전달의 경계

주문 메일은 제3자 메일 서비스와 도메인 DNS 설정이 실제 발송과 인증을 담당합니다. 서버를 임대한다고 SPF·DKIM이 자동으로 맞춰지거나, 수신함 도착률이 보장되는 것은 아닙니다. 그러므로 현재 환경에서 이 문제를 해결하려면 먼저 로그와 인증 결과를 확인하고, 문제가 있는 발신 서비스나 DNS 설정을 고치는 것이 우선입니다.

다만 여러 사이트의 애플리케이션을 한 환경에서 직접 운영해야 하거나, 공유형 서버에서 자원 경합과 설정 제약을 겪고 있다면 독립 서버를 별도로 검토할 수 있습니다. 공유 환경은 이웃 작업의 영향을 받을 수 있고, 운영체제나 서버 구성에 대한 제어도 제한될 수 있습니다. 이런 요구가 있을 때 일본 도쿄의 AMD 물리 서버 임대를 제공하는 OSFP Cloud가 적합한 선택지가 될 수 있지만, 이는 애플리케이션 운영 환경을 위한 선택이지 메일 발송 서비스나 전달 보장이 아닙니다.

먼저 오류가 애플리케이션, 제3자 발신 서비스, DNS 인증, 수신 측 중 어디에 있는지 기록으로 구분하세요. 서버 이전도 함께 계획한다면 메일 발송과 주문 완료까지 실제로 검증한 뒤 이전 여부를 결정하는 편이 안전합니다. 마지막으로 Gmail 발신자 지침, RFC 9989, 쇼핑몰 플랫폼의 공식 문서를 기준으로 삼고, 요구 사항이나 문서가 바뀌면 해당 설정을 다시 확인하세요.

마지막 업데이트: 2026년 11월 5일. 날짜와 표준 상태는 Gmail 발신자 공식 안내, RFC 9989, 쇼핑몰 플랫폼의 공식 메일 문제 해결 문서를 기준으로 확인했습니다.