Japan Server Error Fix Lab

홈 / Mail / Mail

Mail DMARC 프록시와 원본 서버 차이

Mail에서 DMARC가 발생했을 때 프록시와 원본 서버 차이 기준으로 원인, 출력 예시, 분기 조치, 금지 조치를 정리합니다.

highDMARC7 분 읽기
첫 확인 명령
grep -R "DMARC" ./logs
먼저 볼 증거

DMARC 대응은 먼저 "프록시와 원본 서버 차이" 관점에서 봅니다. 첫 증거는 whether the edge/proxy or the origin server creates the failure 입니다.

검색 쿼리
Mail DMARCMail error DMARCMail DMARC 프록시와 원본 서버 차이

이런 상황에서 발생합니다

A CDN, load balancer, reverse proxy, or WAF sits in front of the service. 이 경우 화면 문구보다 먼저 whether the edge/proxy or the origin server creates the failure를 확인하고, 정상 출력과 실패 출력을 비교합니다.

증상 체크

  • DMARC가 Mail 화면이나 로그에 반복됩니다.
  • SPF, DKIM, DMARC, MX, raw bounce 값이 정상 요청과 실패 요청에서 다릅니다.
  • sender auth failure from receiver blocking를 분리했을 때만 문제가 보입니다.
  • 배포, 권한, 설정, 데이터 갱신 직후에 자주 발생합니다.

가능성이 높은 원인

  • mail delivery failure caused by SPF/DKIM/DMARC alignment, MX routing, SMTP authentication, bounce policy, or blacklist reputation.
  • 프록시와 원본 서버 차이 케이스에서는 whether the edge/proxy or the origin server creates the failure가 첫 번째 단서가 됩니다.
  • 정상 케이스와 실패 케이스를 비교하지 않으면 원인 후보가 너무 넓어집니다.
  • 캐시, 권한, 네트워크, 프록시 상태가 일부 사용자에게만 다르게 보일 수 있습니다.

1분 먼저 확인

  1. 최초 발생 시각, 최근 변경, 영향받는 사용자, URL, 객체 ID를 적습니다.
  2. 정상/실패 케이스에서 SPF, DKIM, DMARC, MX, raw bounce를 같은 시간대에 비교합니다.
  3. 가설을 확인합니다: mail delivery failure caused by SPF/DKIM/DMARC alignment, MX routing, SMTP authentication, bounce policy, or blacklist reputation.
  4. 프록시와 원본 서버 차이 여부를 판단합니다: whether the edge/proxy or the origin server creates the failure.
  5. 설정을 바꾸기 전에 현재 값을 캡처합니다.

먼저 볼 증거

DMARC 대응은 먼저 "프록시와 원본 서버 차이" 관점에서 봅니다. 첫 증거는 whether the edge/proxy or the origin server creates the failure 입니다.

출력 예시

정상 출력

Direct origin and routed proxy return equivalent status and headers.

실패 출력

Origin succeeds but proxy fails, or proxy succeeds while direct origin exposes the real backend error.

출력별 판단

  • A CDN, load balancer, reverse proxy, or WAF sits in front of the service.
    Test direct origin and routed traffic separately, then change only the layer that differs.
  • 정상 케이스와 실패 케이스의 출력이 다릅니다.
    차이가 난 레이어에서 먼저 조치합니다: For DMARC, apply the fix only after reproducing the same condition and saving the before/after evidence for this exact code.
  • 명령어 출력은 정상인데 사용자 화면만 실패합니다.
    브라우저 캐시, 쿠키, 권한, 네트워크 위치를 분리해서 확인합니다.

하지 말아야 할 조치

  • Do not assume the CDN error code is the application root cause.
  • 원인 레이어를 확인하기 전 여러 설정을 동시에 바꾸지 마세요.
  • 운영 데이터 삭제, 전체 권한 부여, 전체 보안 해제는 첫 대응으로 하지 마세요.

검증 상태

자동 생성 초안: 코드별 원인, 명령어, 출력 분기, 금지 조치를 포함했습니다. 공식 문서 링크와 실제 운영 검증은 계속 보강 대상입니다.

먼저 실행할 명령어

grep -R "DMARC" ./logs
dig example.com MX +short
dig example.com TXT +short
openssl s_client -starttls smtp -connect mail.example.com:587
grep -R "DMARC" /var/log/mail*
dig TXT example.com +short
dig MX example.com +short
grep -R "spf\|dkim\|dmarc\|550\|554\|bounce" ./mail-logs ./logs
curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP

해결 순서

  1. DMARC 전체 메시지, 실패 URL, 사용자, 객체 ID, 최근 변경을 기록합니다.
  2. mail delivery failure caused by SPF/DKIM/DMARC alignment, MX routing, SMTP authentication, bounce policy, or blacklist reputation에 맞는 증거를 먼저 수집합니다.
  3. 실패 케이스와 정상 케이스를 같은 명령어로 비교합니다.
  4. 프록시와 원본 서버 차이 분기라면 Test direct origin and routed traffic separately, then change only the layer that differs.
  5. 같은 URL과 같은 명령어로 재검증하고 정상 출력을 기록합니다.

원인별 조치

  • For DMARC, apply the fix only after reproducing the same condition and saving the before/after evidence for this exact code.
  • Check SPF, DKIM, and DMARC results from the receiver's headers.
  • Publish the exact DKIM selector used by the sending service.
  • Align envelope, header From, and signing domains.
  • Confirm MX and SMTP credentials belong to the active mail provider.
  • Handle 550/554 bounce codes by policy reason, not by retrying blindly.
  • "프록시와 원본 서버 차이" 분기에서는 Test direct origin and routed traffic separately, then change only the layer that differs.

검증 메타

  • operator-draft
  • official-reference-linked
  • 2026-07-23

업데이트 큐

  • 갱신 주기
    weekly-source-review
  • 다음 보강
    Add one official-source check and one real output example for Mail DMARC.

환경별 확인 포인트

  • 공유 호스팅, 프록시, VPN, CDN은 sender auth failure from receiver blocking 결과를 다르게 만들 수 있습니다.
  • Mail 관리 화면만 믿지 말고 명령어 출력과 비교합니다.
  • 일본 호스팅 패널은 완료로 보여도 DNS/SSL 반영이 늦을 수 있습니다.
  • 사내망과 외부망에서 모두 확인합니다.

다시 발생하지 않게 하기

  • SPF, DKIM, DMARC, MX, raw bounce의 정상 출력 예시를 저장합니다.
  • SPF include, DKIM selector, DMARC policy, reverse DNS를 배포 체크리스트에 추가합니다.
  • 반복되는 에러는 같은 형식의 대응 노트로 남깁니다.
  • 오류율, 지연, 인증서, 디스크, 권한 변경 알림을 나눕니다.