블로그로 돌아가기
엔지니어링 게시일 16.09.2026 1분 분량

문의 양식에는 “감사합니다”가 뜨는데 메일은 오지 않을 때

문의 양식은 아무 오류도 보이지 않은 채 고장 날 수 있습니다. 방문자는 친절한 확인 메시지를 보지만 운영자는 아무것도 받지 못합니다. 그 이유와 제때 알아채는 방법을 알아봅니다.

작은 물리치료원을 상상해 보십시오. 웹사이트에 문의 양식이 있고 잘 작동합니다. 적어도 그렇게 보입니다. 방문자는 양식을 작성하고 “보내기”를 누른 뒤 “감사합니다. 곧 연락드리겠습니다”라는 친절한 메시지를 봅니다. 아무도 모르는 사실은 메시지가 한동안 치료원의 받은편지함에 도착하지 않았다는 것입니다. 오류도, 누구의 받은편지함에도 반송 메일도, 경고등도 없습니다. 양식은 조용히 실패합니다.

아무도 알아채지 못하는 이유

양식의 “감사합니다” 페이지는 보통 한 가지만 의미합니다. 웹사이트가 메시지를 다음 단계로 넘겼다는 것입니다. 메일 서버가 수락하거나 스팸으로 분류하거나 도중에 거부하는 것은 나중에 양식이 볼 수 없는 곳에서 일어납니다. 예를 들어 PHP의 mail() 함수는 로컬 시스템이 발송할 메시지를 받아들이는 즉시 성공을 반환합니다. 누군가에게 도착했을 때가 아닙니다. 방문자는 확인 메시지를 보고 떠납니다. 한편 소유자는 빈 받은편지함을 보고 그저 한가한 달이라고 생각합니다. 문의 감소만으로는 좀처럼 경각심이 생기지 않습니다. 휴일, 날씨, 경기 등 “양식이 고장 났다”보다 그럴듯하게 들리는 설명은 늘 있습니다.

가상의 시간 흐름
  1. 0일째
    밤사이 정기 플러그인 업데이트가 실행됩니다. 사이트는 이전과 똑같아 보입니다.
  2. 1일째
    마지막 메시지가 도착합니다. 아무도 그것이 마지막이라는 사실을 모릅니다.
  3. 2~13일째
    방문자는 계속 양식을 제출하고 “감사합니다”를 봅니다. 받은편지함에는 아무것도 도착하지 않습니다.
  4. 14일째
    누군가 조금 불쾌한 목소리로 전화해 왜 문의에 아무도 답변하지 않았는지 묻습니다.
  5. 15일째
    한 시간 안에 원인을 찾습니다. 양식이 사본도 보관하지 않았다면 그 이 주 동안의 메시지는 사라진 상태입니다.
실제 사례는 아니지만 매우 전형적인 양상입니다.

흔한 원인

  • SMTP 비밀번호 또는 메일 제공업체가 변경되었습니다. 양식은 이전 자격 증명으로 계속 로그인하고 메일 서버는 거부합니다. 방문자에게는 조용히 실패하는 것으로만 보입니다.
  • 인증 없는 PHP mail(). 웹 서버가 정상적인 메일 서버에 로그인하지 않고 직접 메일을 발송합니다. 많은 수신 서버가 이런 메일을 의심하여 스팸으로 분류하거나 아예 거부합니다.
  • SPF, DKIM 및 DMARC가 일치하지 않습니다. 많은 양식이 방문자 주소를 From 필드에 넣습니다. 그러면 메시지는 예를 들어 gmail.com 주소에서 온다고 주장하지만 실제로는 웹 서버가 발송합니다. 바로 DMARC가 막으려는 상황입니다.
  • 플러그인 업데이트 또는 테마 변경으로 양식이나 CAPTCHA가 고장 났습니다. 변경된 템플릿에서 필드가 빠지거나, 스크립트가 더 이상 로드되지 않거나, CAPTCHA 위젯만 표시되고 스크립트가 없으면 모든 제출의 검증이 실패합니다.
  • 수신 메일함이 가득 찼습니다. 메일 서버가 새 메시지를 거부하고 반송 메일은 아무도 읽지 않는 주소로 갑니다.
  • 쿠키 배너가 양식 스크립트를 차단합니다. 동의 도구가 CAPTCHA 또는 양식 스크립트를 “마케팅”으로 분류하면 쿠키를 거부한 방문자는 제출할 수 없거나 토큰이 없어 제출이 거부되는 양식을 보게 될 수 있습니다.
  • TLS 인증서 또는 도메인이 만료되었습니다. 방문자가 브라우저 경고를 보고 떠나거나 메일 서버에 더 이상 안전하게 연결할 수 없습니다. 수신 메일함의 도메인이 만료되면 메일 수신이 그대로 중단됩니다.
  • 캐싱 계층이 오래된 페이지를 제공합니다. 전체 페이지 캐시는 보안 토큰(nonce 또는 CSRF 토큰)이 만료된 양식을 전달할 수 있습니다. 서버는 제출을 거부하고 설정에 따라 방문자는 명확한 오류를 보지 못합니다.

From 주소의 함정

세 번째 원인은 자세히 살펴볼 가치가 있습니다. 많은 양식 설정에 기본적으로 들어 있기 때문입니다. DMARC는 눈에 보이는 From 주소의 도메인이 SPF 또는 DKIM이 보증하는 도메인과 일치하는지 확인합니다. 양식이 방문자의 주소를 발신자로 사용하면 서버에는 그 도메인으로 발송할 권한이 없으므로 검증이 실패합니다. 방문자 도메인의 DMARC 정책과 자신의 메일 제공업체에 따라 스팸으로 분류되거나 거부됩니다. 해결책은 간단합니다. 자신의 도메인 주소를 발신자로 사용하고 방문자 주소는 Reply-To에 넣으십시오. “답장”을 누르면 여전히 방문자에게 전달됩니다.

같은 양식 메시지를 발송하는 두 가지 방식
불안정한 방식
  • From: 방문자의 주소
  • Reply-To 없음
  • 웹 서버에서 PHP mail()로 직접 발송
  • 발송 도메인에 SPF, DKIM 또는 DMARC가 없음
  • 메시지가 이메일로만 존재
견고한 방식
  • From: form@yourdomain 등 자신의 도메인 주소
  • Reply-To: 방문자의 주소
  • 인증된 SMTP 또는 발송 서비스
  • SPF, DKIM 및 DMARC를 설정하고 일치시킴
  • 데이터베이스에도 사본 저장
오른쪽 방식도 거의 추가 작업 없이 설정만으로 구현할 수 있습니다.

해야 할 일

  1. 1자신의 양식으로 정기적으로 테스트 메시지를 보내십시오. 최소 매달, 그리고 업데이트, 테마 변경 또는 메일 설정 변경 후에는 반드시 수행하십시오. 아무도 답변하지 않도록 테스트임을 명확히 표시하십시오.
  2. 2평소의 흐름을 파악하십시오. 보통 일주일에 몇 개의 메시지가 오는 양식이라면 이 주 동안의 침묵은 한가한 달이 아니라 점검할 이유입니다.
  3. 3PHP mail()에 의존하지 말고 메일 제공업체 또는 전용 발송 서비스를 통해 인증된 SMTP로 발송하십시오.
  4. 4From에는 자신의 도메인, Reply-To에는 방문자 주소를 사용하십시오. 그런 다음 해당 도메인의 SPF, DKIM 및 DMARC를 설정하여 메시지가 검증을 통과하도록 하십시오.
  5. 5모든 제출의 사본을 데이터베이스에 보관하십시오. 많은 양식 플러그인이 이 기능을 제공하며 때로는 추가 기능이 필요합니다. 메일이 실패해도 문의는 남습니다.
  6. 6플러그인 업데이트 후에는 매번 CAPTCHA를 포함하여 양식을 점검하고 쿠키를 거부한 상태에서도 확인하십시오.

이런 점검은 잊기 쉬우므로 자동화할 가치가 있습니다. 계정과 검증된 도메인이 있으면 formexposed가 테스트임을 명확히 표시한 제출을 보내 실제 도착 여부를 확인할 수 있습니다(전달 확인, 명시적으로 활성화한 경우에만). 평소 메시지를 받던 양식이 갑자기 아무것도 받지 않는 침묵도 감지하며, 알림 메일의 SPF, DKIM 및 DMARC와 TLS 인증서 및 도메인 만료를 확인합니다. 변경이 생길 때만 알림을 받습니다.

먼저 간단히 살펴보고 싶다면 formexposed.com의 무료 점검은 계정이 필요 없고 아무것도 제출하지 않습니다. 스크립트 없는 위젯, 공개 테스트 키, 브라우저 오류처럼 CAPTCHA가 존재하지만 고장 난 상태인지도 보여줍니다. 이는 양식이 조용히 작동을 멈추는 원인 중 하나입니다. 메시지의 실제 도착은 진짜 테스트 메시지로만 확인할 수 있으므로 오늘 하나 보내보십시오.