이메일 주소 확인: 실제로 존재하는지 검증

아무것도 보내지 않고 이메일 주소가 실제로 있는지 확인하세요. 저희가 메일 서버에 물어보고 그 대화를 그대로 보여 드립니다. 또는 직접 쓰는 이메일을 테스트 주소로 보내 전달 가능성 보고서를 받을 수도 있습니다.

출처: DNS(MX, SPF, DMARC) · 저희 서버의 실시간 SMTP 확인(DATA 직전에 중지) · 테스트 메일용 자체 메일 서버(백업은 Cloudflare Email Routing) · SpamAssassin 4

메일을 보내지 않고 이메일 주소를 확인하는 방법

메일 서버는 메시지를 보내기 전에 그 주소를 아는지 알려 줍니다. 저희는 그 질문을 하고 연결을 끊습니다.

이메일 발송은 서버 두 대 사이의 짧은 대화입니다. 발신 측이 인사(EHLO)를 하고, 반송 주소(MAIL FROM)와 수신자(RCPT TO)를 알린 다음에야 메시지(DATA)를 보냅니다. 수신 서버는 각 줄에 세 자리 코드로 답합니다(RFC 5321).

저희는 RCPT TO까지만 대화하고 그 답을 읽습니다. 그다음 초기화(RSET)하고, 같은 도메인의 가짜 주소(대조군)에 대해 한 번 더 묻고, QUIT 명령으로 작별 인사를 합니다. DATA는 보내지 않으므로 누구의 받은편지함에도 아무것도 도착하지 않고, 발신자가 비어 있어서 반송될 일도 없습니다.

probe.dnsrobot.net저희 확인 서버 · 뭄바이 · 198.51.100.25mx-in.g.apple.com도메인의 메일 서버 · Apple · 203.0.113.17
  1. 220 hfd-mx01.apple.com -- Server ESMTP (Oracle Communications Messaging Server 8.1.0.28.20250821 64bit (built Aug 21 2025))295 ms
  2. EHLO probe.dnsrobot.net
  3. 250 hfd-mx01.apple.com · 8BITMIME · PIPELINING · CHUNKING …140 ms
  4. MAIL FROM: <>빈 발신자: 반송될 수 없습니다
  5. 250 2.5.0 Address Ok157 ms
  6. RCPT TO: <postmaster@apple.com>1
  7. 250 2.1.5 postmaster@apple.com Ok1200 ms
  8. RSET · MAIL FROM:<> · RCPT TO: <5b1c71ed2e78ecf2@apple.com>2같은 도메인의 가짜 주소
  9. 550 5.1.1 unknown or illegal alias: 5b1c71ed2e78ecf2@apple.com2145 ms
  10. DATA 보내지 않음: 메시지 직전에 멈춥니다
  11. QUIT
  1. 구문1 ms
  2. 도메인과 MX181 ms
  3. 목록< 1 ms
  4. 메일 서버1.5 s
postmaster@apple.com의 실제 확인입니다. 이 주소는 모든 메일 도메인이 갖춰야 하는 역할별 주소입니다(RFC 2142). 뭄바이의 저희 서버에서 확인했으며, 응답 7개를 받는 데 1.5 s 걸렸습니다. 서버는 가짜 주소를 거부하고(550 5.1.1), 그래서 실제 주소에 대한 '예'를 믿을 수 있습니다.
postmaster@apple.com의 이메일 주소 확인 결과: 전달 가능, SMTP 대화와 가짜 대조군 주소 포함postmaster@apple.com의 이메일 주소 확인 결과: 전달 가능, SMTP 대화와 가짜 대조군 주소 포함판정전달 가능, 전달 불가, 전체 수신, 위험, 알 수 없음 중 하나를, 결정한 응답 코드와 이유를 설명하는 한 문장과 함께 보여 줍니다.네 단계구문, 도메인의 메일 서버, 일회용과 역할별 목록, 그리고 메일 서버 자체를 각각의 소요 시간과 함께 보여 줍니다.결정한 답이 주소와 같은 도메인의 가짜 주소: 앞의 것에는 '예', 뒤의 것에는 '아니요'라고 답하면 그 '예'를 믿을 수 있습니다.대화저희 서버가 보낸 모든 명령과 메일 서버가 준 모든 응답을, 일어난 그대로 각 응답의 코드와 시간과 함께 보여 줍니다.아무것도 보내지 않음DATA는 절대 보내지 않습니다: 메시지가 만들어지기 전에 대화를 멈추므로, 받은편지함에는 아무것도 도착하지 않고 반송될 것도 없습니다.
postmaster@apple.com의 실제 확인입니다. 이 주소는 모든 메일 도메인이 갖춰야 하는 역할별 주소입니다: 판정, 네 단계, 결정을 내린 두 가지 답, 그리고 DATA 직전에 멈춘 SMTP 대화 전체를 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 알 수 있습니다.

이메일 확인 결과 읽는 법

다섯 가지 결과는 각각 그것을 만든 응답과 연결되어 있습니다.

전달 가능에는 두 가지가 필요합니다: 해당 주소에는 '예', 같은 도메인의 가짜 주소에는 '아니요'라는 답(또는 모든 주소를 확인하는 것으로 측정된 제공업체)입니다. 두 번째 답이 없다면 '예'는 누구에게나 '예'라고 답할지 모르는 서버의 '예'일 뿐입니다.

알 수 없음은 실패가 아니라 솔직한 결과입니다: 서버가 저희 확인 서버와의 대화를 거부했거나, 기다리라고 했거나, 답하지 않은 경우입니다. 주소에 대해서는 아무것도 말해 주지 않으므로, 저희는 이를 '유효하지 않음'으로 바꾸지 않습니다.

  • 전달 가능
    이 주소
    250
    가짜 주소
    550

    서버가 이 주소를 알고 있고, 같은 도메인의 낯선 주소는 거부합니다.

    보내세요.
  • 전달 불가
    이 주소
    550 5.1.1
    또는 도메인
    null MX없는 도메인

    서버가 메일함이 없다고 답하거나, 도메인이 메일을 전혀 받지 않습니다.

    보내지 마세요: 반송됩니다.
  • 전체 수신
    이 주소
    250
    가짜 주소
    250

    서버가 무엇에든 '예'라고 답하므로, 그 '예'는 아무것도 증명하지 못합니다.

    상대방에게 직접 받은 주소일 때만 보내세요.
  • 위험
    도메인
    일회용 목록
    또는 메일함
    552가득 참

    존재하지만 오래가지 않거나, 지금은 메일을 받을 수 없습니다.

    나중에 필요한 용도로는 피하세요.
  • 알 수 없음
    이 주소
    451554응답 없음
    또는 DNS
    SERVFAIL

    서버가 답하지 않았거나 나중에 다시 오라고 했습니다. '아니요'가 아닙니다.

    나중에 다시 확인하거나 그냥 보내세요.
모든 결과는 응답 코드(RFC 5321) 또는 도메인에 관한 사실에서 나오며, 추측이 아닙니다. 역할별, 무료, 별칭, 구형 통신사 주소는 결과 옆에 붙는 표시일 뿐 결과 자체가 아닙니다.

확인할 수 있는 이메일 제공업체

확인으로 알 수 있는 것은 제공업체마다 다릅니다. 저희 서버에서 제공업체 53곳이 운영하는 메일 도메인 65개를 측정했습니다.

대부분의 개인용 제공업체는 모르는 주소를 RCPT에서 거부하므로, 그곳의 확인은 믿을 수 있습니다. 모든 주소를 받고 나중에 분류하는 곳도 있고, Outlook.com은 주소 수집을 막으려고 한 번 '예'라고 답하기도 하며, 몇몇은 모르는 서버를 거부합니다.

일부 확인 도구처럼 비밀번호 찾기나 가입 페이지로 주소를 시험하는 일은 절대 하지 않습니다: 제공업체의 약관을 어기는 일이고, 공격자가 계정을 찾는 바로 그 방식이기 때문입니다.

저희 서버에서 측정2026년 10월 22일 · 도메인 65개, 그중 10개는 기업
모든 주소를 확인도메인 42개모르는 주소는 RCPT에서 5xx를 받으므로, '예'는 진짜 '예'입니다.
  • 163.com
  • au.com
  • biglobe.ne.jp
  • comcast.net
  • daum.net
  • docomo.ne.jp
  • ezweb.ne.jp
  • freenet.de
  • gmail.com
  • gmx.com
  • gmx.de
  • hanmail.net
  • hey.com
  • i.softbank.jp
  • icloud.com
  • kakao.com
  • laposte.net
  • libero.it
  • mail.com
  • mailbox.org
  • naver.com
  • o2.pl
  • ocn.ne.jp
  • orange.fr
  • posteo.de
  • proton.me
  • qq.com
  • rambler.ru
  • rediffmail.com
  • seznam.cz
  • sfr.fr
  • softbank.ne.jp
  • terra.com.br
  • tuta.io
  • uol.com.br
  • web.de
  • wp.pl
  • yandex.ru
  • zoho.com
  • apple.com
  • microsoft.com
  • salesforce.com
일부 가짜 주소에 '예'라고 답함도메인 2개Outlook.com: 가짜 주소 12개 중 2개가 한 번 250을 받았습니다. 저희는 두 번 묻습니다.
  • hotmail.com
  • outlook.com
모든 주소를 수신도메인 9개여기서 '예'는 증거가 되지 않습니다: 이 서버들은 먼저 받고 나중에 메일을 분류합니다.
  • mail.ru
  • yahoo.co.jp
  • amazon.com
  • github.com
  • google.com
  • netflix.com
  • shopify.com
  • spotify.com
  • stripe.com
당분간 저희 서버를 거부도메인 8개저희 서버의 역방향 DNS가 정방향과 역방향 모두 일치하기를 요구합니다. Yahoo 자체 오류 목록에도 존재하지 않는 계정으로 보낸 메일이 발송 후에 반송되었다고 나와 있습니다.
  • aol.com
  • att.net
  • bol.com.br
  • cox.net
  • free.fr
  • nifty.com
  • verizon.net
  • yahoo.com
그레이리스팅 또는 보류도메인 3개4xx입니다. Fastmail은 그레이리스팅을 합니다: 1분 뒤에 같은 질문을 하면 답을 줍니다. onet.pl과 interia.pl은 종료일이 정해진 규칙이나 전달 한도로 보류하는데, 기다려도 달라지지 않습니다.
  • fastmail.com
  • interia.pl
  • onet.pl
확인하지 말 것을 요청도메인 1개Deutsche Telekom: 아예 접속하지 않습니다.
  • t-online.de
기업은 해당 메일 플랫폼의 마크(Microsoft 365, Google Workspace, Proofpoint, iCloud)를 표시합니다. 기업의 답은 그 기업 자신의 설정이지 플랫폼의 규칙이 아닙니다: microsoft.com은 모든 주소를 확인하지만, 같은 플랫폼의 github.com은 아무 주소나 받습니다.

캐치올, 그레이리스팅, 거부: 주소를 확인할 수 없을 때

메일 서버가 답을 피하는 세 가지 방식과, 각각이 결과에 어떻게 나타나는지 설명합니다.

전체 수신(캐치올) 서버는 실제로 있든 없든 모든 주소에 250이라고 답합니다. 많은 Microsoft 365 회사가 모르는 채로 이렇게 운영됩니다: Directory-Based Edge Blocking은 도메인이 '신뢰할 수 있음'으로 설정된 경우에만 없는 주소를 거부합니다.

그레이리스팅은 처음 보는 발신자에게 451로 답하고, 1분 뒤의 같은 질문은 받아 줍니다(RFC 6647). 거부는 RCPT까지 어느 단계에서든 나올 수 있지만(bol.com.br은 RCPT 자체에서 거부했습니다), 겨냥하는 것은 주소가 아니라 저희 서버이므로 결과는 '알 수 없음'이며, '아니요'가 아닙니다.

전체 수신
  • sam.example@example.org250
  • 9e2b7c41d0a8f365@example.org250

둘 다 '예'를 받았습니다: 서버가 둘을 구분하지 못하므로, 저희도 구분할 수 없습니다.

다음으로 설정된 Microsoft 365 도메인내부 릴레이250아무 주소나신뢰할 수 있음(Directory-Based Edge Blocking)550 5.4.1모르는 주소
그레이리스팅
0초451 4.7.1“Recipient address rejected: Temporary deferral, try again soon”
최소 1분은 기다리세요: 같은 서버, 같은 발신자, 같은 주소로(RFC 6647)
60+초250550진짜 답

Fastmail이 저희에게 이렇게 했습니다. 결과에는 1분 뒤에 다시 확인할 수 있는 버튼을 제공하며, 짧은 간격으로 반복하지는 않습니다. (onet.pl과 interia.pl도 450으로 답했지만, 종료일이 정해진 규칙과 전달 한도 때문이며 사실상 거부여서 기다리라는 선택지는 제공하지 않습니다.)

거부: 각 서버가 막은 지점
접속인사EHLOMAILRCPT
nifty.com554
FCrDNS check failed: reverse DNS does not match the connecting IP
free.fr421
Refused. Your reverse DNS entry does not resolve to an IP.
t-online.de554
None/bad reputation … (NOWL)
yahoo.com550 5.7.25
Forward-confirmed reverse DNS failed
bol.com.br450 4.7.25
Client host rejected: cannot find your hostname

거부는 어디서 일어나든 주소가 아니라 저희 서버를 겨냥한 것입니다(bol.com.br은 RCPT에서 거부했습니다). 그래서 결과는 알 수 없음이며, '유효하지 않음'이 아닙니다.

2026년 10월 22일에 서버가 저희 확인 서버에 보낸 코드와 문구 그대로입니다. 거부 다섯 건 중 네 건은 역방향 DNS(정방향 확인된 PTR)에 관한 것이며, 저희 서버의 PTR 레코드가 일치하게 되면 없어집니다.

일회용, 역할별, 무료, 별칭 이메일 주소

표시는 주소를 설명할 뿐이며, 그것만으로 결과를 정하지는 않습니다.

역할별 주소(support@, sales@)는 실제로 있지만 공유됩니다. 무료 주소는 개인에게는 흔합니다. 별칭은 누군가의 실제 받은편지함으로 전달하고, 일회용 주소는 몇 시간 안에 사라지는 공개 받은편지함입니다.

일본의 통신사에는 점이 두 개 연속되거나 @ 바로 앞에 점이 있는 주소가 아직 남아 있습니다. RFC를 어기지만 메일은 받으므로, 저희는 메일 서버에 입력한 그대로 묻습니다.

support역할별 메일함(RFC 2142)+orders서브주소(RFC 5233)@example.com도메인이 결정합니다: 무료, 일회용, 별칭
  • 역할별 주소postmaster@support@sales@

    팀 받은편지함: 실제로 있고 자주 읽지만 누군가의 개인 주소는 아닙니다. RFC 2142에 도메인이 갖춰야 할 것들이 정해져 있습니다.

  • 무료 서비스

    누구나 가입할 수 있습니다. 개인에게는 흔하지만, 회사 직원 본인의 주소로는 드뭅니다.

  • 일회용@mailinator.com약 9,900개 도메인

    몇 시간 안에 사라지는 공개 받은편지함입니다. disposable-email-domains 목록(CC0)에서 등록 가능한 도메인 단위로 대조합니다.

  • 별칭 서비스

    본인이 비공개로 두는 실제 받은편지함으로 전달합니다. 일회용이 아닙니다: 회신은 본인에게 갑니다.

  • 구형 통신사 주소taro..yamada@docomo.ne.jp

    RFC상 유효하지 않지만 여전히 쓰입니다: docomo와 au는 '..'나 '.@'가 들어간 예전 주소를 그대로 쓰게 해 줍니다. 서버에는 입력한 그대로 묻습니다.

표시만으로 결과가 정해지지는 않습니다: 역할별 주소도 전달 가능일 수 있고, 별칭이 전체 수신일 수도 있습니다.

이메일 전달 가능성 테스트의 작동 방식: 무료 메일 테스트

실제 이메일 한 통을 일회용 주소로 보내면, 확인이 끝나는 항목부터 보고서가 만들어집니다.

테스트 주소는 2시간 동안 메일 한 통을 받습니다. 저희 자체 메일 서버가 mailtest.dnsrobot.net 앞으로 온 메일을 TLS로 받고, SMTP 세션을 직접 지켜봅니다: TLS 버전, 인사, 발신 서버가 대화하는 방식 등입니다. Cloudflare Email Routing은 백업 경로입니다.

모든 확인은 실제로 도착한 것을 바탕으로 합니다: 접속한 주소, 이메일 서비스가 붙인 헤더, 독자가 받게 될 HTML입니다. 그런 다음 SPF, DKIM, DMARC, ARC, 형식, 내용, 구독 취소 헤더, SpamAssassin, 받은편지함 제공업체의 규칙을 확인합니다.

  1. 메일 앱보내기를 누릅니다14:02:10
  2. 발신 서버이메일 서비스SendGrid · 198.51.100.24
    역방향 DNS(PTR)HELO 이름차단 목록
  3. 저희 메일 서버TLS로 수신mailprobe.dnsrobot.net · TLSv1.3
    SMTP 세션TLS 버전EHLO와 파이프라이닝줄바꿈
    메시지SPFDKIMDMARCARC형식내용구독 취소
  4. 보고서확인이 끝난 항목부터 표시14:02:24
    SpamAssassinGmail · Yahoo · Outlook.com 규칙점수
백업: Cloudflare Email Routingroute1–3.mx.cloudflare.net저희 서버가 중단되었을 때 메일을 받습니다. TLS 세부 정보는 전달하지 않습니다
메시지가 어떻게 되는가
0 s저희 메일 서버에 도착11 s분석 완료: 본문과 첨부 파일 삭제7일헤더, 링크, 미리보기 삭제('보고서 삭제'를 누르면 더 일찍)
이 페이지의 예시: SendGrid로 보낸 뉴스레터입니다. 각 확인은 이뤄지는 위치에서 켜집니다: 발신 서버의 신원, 저희 서버가 본 SMTP 세션, 메시지의 서명과 내용, 그다음 SpamAssassin과 받은편지함 제공업체의 규칙입니다.

스팸 검사기가 메시지에 점수를 매기는 방법

10점에서, 각각 규칙을 밝히는 감점을 뺍니다. 확인하지 못한 것은 점수를 깎지 않습니다.

점수는 어떻게 만들어졌는지 볼 수 있어야 쓸모가 있습니다. 그래서 표 전체를 여기에 실었고, 메시지에 점수를 매기는 것과 같은 코드로 생성합니다. 각 감점은 RFC, 메일함 제공업체 자체의 페이지, 또는 SpamAssassin 규칙에 근거합니다.

원클릭 구독 취소 같은 대량 메일 전용 규칙은 메시지가 대량 메일로 보일 때만 감점합니다. 메일 한 통으로는 알 수 없는 것(신고율, 발송량)은 '판단 불가'이며 점수를 깎지 않습니다.

가상의 보고서7.8

10 − 1.5 − 0.7 = 7.8

  1. 1작동하는 원클릭 구독 취소가 없는 대량 메일(RFC 8058: 두 헤더 모두 DKIM으로 서명)
  2. 2SpamAssassin 3.4
확인한 내용감점항목
SPF가 통과하지 않고 검증되는 DKIM 서명도 없음−3SPF
DMARC 실패: 일치하는 SPF나 DKIM 통과가 없고, From 도메인이 정책을 게시함−2.5DMARC
From 헤더에 DMARC를 적용할 단일 도메인이 없음−2DMARC
From 도메인이 DMARC 레코드를 게시하지 않음대량 메일에만 해당−1DMARC
SPF fail: 레코드가 이 서버의 발송을 허용하지 않음−1SPF
SPF softfail 또는 neutral−0.5SPF
MAIL FROM(또는 HELO) 도메인에 SPF 레코드가 없음−1SPF
SPF permerror: 잘못된 레코드 또는 DNS 조회 10회 초과−1SPF
메시지에 DKIM 서명이 없음대량 메일에만 해당−1DKIM
DKIM 서명은 있지만 모두 실패(서명 없음으로 취급)대량 메일에만 해당−1DKIM
서명이 1,024비트 미만의 RSA 키를 사용함−1DKIM
DKIM은 통과하지만 통과한 서명이 From 도메인과 일치하지 않음−0.5DKIM
발신 주소가 주요 차단 목록에 있음−3발신 서버
발신 주소가 소규모 차단 목록에 있음−1발신 서버
발신 주소에 역방향 DNS(PTR)가 없음−2.5발신 서버
PTR 이름이 발신 주소로 정방향 확인되지 않음−1.5발신 서버
HELO가 완전한 도메인 이름(FQDN)이 아님−0.5발신 서버
서버가 TLS 없이 발송함−1.5SMTP 세션
메시지에 CR 없는 LF 또는 LF 없는 CR 줄바꿈이 있음0경고이며 점수에는 포함하지 않음(출처가 제시되면 −0.5)SMTP 세션
From이 없거나, 중복되었거나, 읽을 수 없거나, Sender 없이 여러 메일함이 나열됨−2형식
Date가 없거나 읽을 수 없음−1형식
Message-ID가 없거나 형식이 잘못됨−1형식
Date가 도착 시각과 하루 넘게 어긋남0경고이며 점수에는 포함하지 않음(출처가 제시되면 −0.5)형식
한 번만 나타나야 하는 필드가 두 번 나타남−0.5형식
998자를 넘는 줄이 있음−0.25형식
텍스트가 거의 없는 이미지0경고이며 점수에는 포함하지 않음(출처가 제시되면 −1)내용
텍스트 버전이 없는 HTML−0.5내용
HTML이 약 102 KB 초과: Gmail에서 잘릴 수 있음0경고이며 점수에는 포함하지 않음(출처가 제시되면 −0.5)내용
URL 단축 서비스를 거치는 링크0경고이며 점수에는 포함하지 않음(출처가 제시되면 −1)내용
IP 주소로 바로 가는 링크0경고이며 점수에는 포함하지 않음(출처가 제시되면 −1)내용
다른 도메인을 흉내 낸 도메인으로 가는 링크0경고이며 점수에는 포함하지 않음(출처가 제시되면 −2)내용
javascript:, data:, file: 링크0경고이며 점수에는 포함하지 않음(출처가 제시되면 −2)내용
링크 텍스트는 한 도메인을 보여 주는데 실제 링크는 다른 도메인으로 감0경고이며 점수에는 포함하지 않음(출처가 제시되면 −0.5)내용
Gmail이 차단하는 유형의 첨부 파일0경고이며 점수에는 포함하지 않음(출처가 제시되면 −2)내용
Cloudflare 보안 리졸버가 차단하는 호스트로 가는 링크(악성코드 또는 피싱)0경고이며 점수에는 포함하지 않음(출처가 제시되면 −2)내용
HTML 안의 스크립트, iframe, 양식, 삽입 객체−1내용
1작동하는 원클릭 구독 취소가 없는 대량 메일(RFC 8058: 두 헤더 모두 DKIM으로 서명)−1.5구독 취소
2SpamAssassin 점수 중 2.0점 초과분2.0점 초과분의 절반, 최대 3SpamAssassin
SpamAssassin 점수가 스팸 기준에 도달함−2SpamAssassin
확인하지 않았거나, 메일 한 통으로는 알 수 없음0–
점수에 쓰는 표입니다(버전 2026-10-31.1): 10점에서 해당하는 행을 모두 빼며, 0 아래로는 내려가지 않습니다. 확인하지 못한 항목은 감점하지 않고, 대량 메일 행은 대량 메일에서만 점수가 깎이며, 0점인 행은 표시는 하지만 점수에 포함하지 않는 경고입니다.

SPF, DKIM, DMARC 도메인 일치(정렬)를 한 장의 그림으로

DMARC는 SPF 또는 DKIM이, 사람들에게 보이는 From 주소와 일치하는 도메인에서 통과할 때 통과합니다.

이메일에는 발신자가 둘 있습니다: 반송이 가는 보이지 않는 엔벨로프 발신자와, 사람들이 읽는 From 주소입니다. SPF는 앞의 것을, DKIM은 서명을 확인하고, DMARC는 둘 중 하나를 뒤의 것에 연결합니다(RFC 9989).

이메일 서비스는 보통 DKIM으로 DMARC를 통과합니다: 사용자의 도메인으로 서명하고(사용자가 추가하는 레코드), 반송은 서비스 자체의 하위 도메인으로 가게 합니다.

Return-Path: bounces+48213-9f1c@em.example.org엔벨로프 발신자(MAIL FROM): SPF가 확인하는 쪽
DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; …From 도메인의 서명
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; …이메일 서비스 자체의 서명
From: Example Weekly <news@example.org>읽는 사람에게 보이는 발신자: DMARC가 보호하는 쪽
  1. SPF 통과198.51.100.24은(는) em.example.org 명의로 발송할 수 있음일치: em.example.org은(는) example.org에 속함
  2. DKIM 통과example.org의 서명이 검증됨일치: 같은 도메인
  3. DKIM 통과sendgrid.info의 서명이 검증됨불일치: 다른 도메인(문제 없음)
  4. DMARC 통과From example.org: 적어도 하나의 통과가 일치함정책 p=none · relaxed 방식 일치
SPF는 보이지 않는 엔벨로프 발신자를, DKIM은 서명을 확인하고, DMARC는 둘 중 하나가 사람들에게 보이는 From 도메인에 속하는지 묻습니다. relaxed 방식은 조직 도메인끼리 비교하고(em.example.org와 example.org는 일치), strict 방식은 이름 자체를 비교합니다.

Gmail, Yahoo, Outlook.com 발신자 요건

2024년부터 주요 받은편지함 제공업체가 요구 사항을 공개했습니다. 여기서 나란히 볼 수 있습니다.

모든 발신자에게는 SPF 또는 DKIM, 제대로 작동하는 역방향 DNS, 올바른 형식의 메시지가 필요합니다. 대량 발신자에게는 추가로 SPF와 DKIM 둘 다, From 주소와 일치하는 DMARC 레코드, 원클릭 구독 취소, 낮은 신고율이 필요합니다.

저희 보고서는 메일 한 통으로 알 수 있는 규칙을 모두 확인하고, 나머지는 '판단 불가'라고 알려 줍니다: 신고율은 Google Postmaster Tools와 Yahoo의 Sender Hub에서 볼 수 있습니다.

GmailYahooOutlook.com
모든 발신자대량 발신자하루 5,000통 이상모든 발신자대량 발신자기준 수치 없음대량 발신자하루 5,000통 이상
SPF 또는 DKIM 통과4.7.27 · 4.7.30–––
SPF와 DKIM 모두 통과4.7.27 · 4.7.30–––
SPF 통과––––1
DKIM 통과––––1
DMARC 레코드(p=none 이상)4.7.40 · 5.7.40–––
From이 SPF 또는 DKIM과 일치(DMARC 통과)4.7.32 · 5.7.32––1
정방향 및 역방향 DNS(PTR)4.7.23–––
연결에 TLS 사용4.7.29––––
RFC 5322 메시지 형식2–––
다른 곳에서의 Gmail From: 사칭 없음––––
올바른 From 또는 Reply-To 주소––––
원클릭 구독 취소(RFC 8058)–––
List-Unsubscribe(mailto 또는 https)––––
본문의 눈에 보이는 구독 취소 링크––
스팸 신고율 0.3% 미만–––

필수권장– 해당 제공업체의 규칙에 없음4.7.23누락되었을 때 Gmail이 응답하는 코드메일 한 통으로는 알 수 없습니다: '판단 불가'라고 표시합니다

1 550 5.7.5152 Gmail은 From에 주소 하나만 둘 것도 요청합니다.

Gmail과 Yahoo는 2024년 2월부터(Gmail은 2025년 11월부터 더 엄격하게 적용), Outlook.com은 2025년 5월 5일부터 적용하며 550 5.7.515로 거부합니다. 보고서는 메일 한 통으로 알 수 있는 행을 모두 확인합니다.

개인정보: 저희가 보관하는 것과 메일 서버가 보는 것

확인한 주소는 보관하지 않습니다. 그 답은 주소 없이 키 해시로만 최대 하루 동안 보관합니다. 테스트 메시지의 본문은 분석 직후 삭제합니다.

주소를 확인할 때 메일 서버에는 짧은 명령 몇 개만 보냅니다: EHLO, MAIL FROM:<>, 해당 주소와 가짜 주소 하나에 대한 RCPT TO(Outlook.com은 한 번 더), RSET, QUIT. 서버가 보는 것은 저희 서버의 이름, 빈 발신자, 물어본 주소이며, 사용자도 메시지도 보이지 않습니다.

테스트 보고서에는 메시지의 헤더, 링크, 140자 미리보기를 확인 결과와 함께 7일간 보관해 링크를 공유할 수 있게 합니다. 본문 전체와 첨부 파일은 분석 직후 삭제합니다. 보고서는 보고서 페이지에서 언제든 삭제할 수 있습니다.

주소 확인
  1. 입력HTTPS로 저희 서버에 전송되며, 요청 안에만 있습니다.
  2. 메일 서버가 보는 것EHLO probe.dnsrobot.net · MAIL FROM:<> · RCPT TO:<…> · RSET · MAIL FROM:<> · RCPT TO:<…> · QUIT아주 적은 명령뿐입니다: 저희 서버의 이름, 빈 발신자, 해당 주소와 가짜 주소 하나에 대한 RCPT TO(Outlook.com은 한 번 더). 메시지도, 이름도, 사용자에 관한 정보도 없습니다.
  3. 저희가 보관하는 것주소는 보관하지 않습니다. 로그에는 도메인과 응답 코드가 남고, 확정된 답은 주소 없이 키 해시로만 최대 하루 동안 보관합니다.
이메일 테스트
  1. 메시지 자체본문과 첨부 파일은 분석 직후 삭제합니다. SpamAssassin은 저희 메일 서버의 메모리에서만 읽으며, 아무것도 기록하지 않습니다.
  2. 보고서헤더, 메시지가 링크하는 도메인(각각 예시 링크 하나 포함), 140자 미리보기: 7일, 또는 '보고서 삭제'를 누를 때까지. 링크를 가진 사람은 누구나 열 수 있습니다.
  3. 하지 않는 일전달하거나, 회신하거나, 사람이 직접 읽지 않습니다.
주소를 확인하는 일은 아무것도 저장하지 않더라도 GDPR상 개인정보 처리에 해당하므로, 최소한만 보관합니다. Spamhaus는 확인 도구가 목록 정리를 제공하지 말 것을 요청하며, 일괄 목록에는 메일함 확인을 하지 않습니다.

자주 묻는 질문

이 이메일 주소 확인 도구는 무료인가요?

네, 가입은 필요 없습니다. 주소 하나씩 확인(1분에 몇 개), 최대 100개 목록 확인, 이메일 전달 가능성 테스트를 할 수 있습니다. 제한이 있는 이유는 모든 확인이 실제 메일 서버에 닿기 때문입니다. 너무 자주 묻는 확인 도구는 서버가 차단하며, 그러면 모두가 이 도구를 쓸 수 없게 됩니다.

메일을 보내지 않고 이메일 주소를 확인하려면 어떻게 하나요?

위에 입력하세요. 도메인의 메일 서버를 조회하고, 첫 번째 서버에 접속해 그 주소로 오는 메일을 받아 줄지(RCPT TO) 묻습니다. 그다음 같은 도메인의 가짜 주소에 대해서도 물어 서버가 둘을 구분하는지 알아내고, 메시지를 보내기 전에 연결을 끊습니다.

이메일 확인은 얼마나 정확한가요? 유효한 주소도 반송될 수 있나요?

메일 제공업체가 허용하는 만큼 정확합니다. Gmail, iCloud 등 대부분의 개인용 제공업체는 분명하게 답합니다. 전체 수신 도메인이나 확인을 거부하는 제공업체는 누구도 확인할 수 없습니다. 메일함이 가득 찼거나 확인 후 상태가 바뀌면 유효한 주소도 반송될 수 있습니다. 저희는 근거 없는 확률 대신 어떤 경우인지를 보여 드립니다.

제가 이메일 주소를 확인한 것을 상대방이 알게 되나요?

아니요. 메시지를 보내기 전에 대화를 멈추므로 상대방의 받은편지함에는 아무것도 도착하지 않습니다. 상대방 제공업체의 서버에는 저희 확인 서버의 접속이 기록되지만, 이는 접속하는 모든 발신자에게 하는 기록과 같고 메일함 주인에게 알리지 않으며, 상대방이 볼 수 있는 것은 아무것도 보내지 않습니다.

Gmail, Yahoo, Outlook.com 주소는 왜 이런 결과가 나오나요?

Gmail은 모든 주소를 확인하므로 답을 믿을 수 있습니다. Outlook.com은 가짜 주소에 한 번 '예'라고 답하기도 해서, 두 번 묻고 일치하는 답만 믿습니다. Yahoo는 역방향 DNS가 일치하지 않는 서버를 돌려보내며 현재는 저희 서버도 포함되어, Yahoo 주소는 '알 수 없음'으로 나옵니다. Yahoo 자체 오류 목록에도 존재하지 않는 계정으로 보낸 메일이 발송 후에 반송되었다고 나와 있습니다.

캐치올(전체 수신) 이메일 주소란 무엇인가요?

메일 서버가 있든 없든 모든 주소로 오는 메일을 받아 주고 나중에 분류하는 도메인의 주소입니다. 확인으로는 그곳에서 실제 메일함과 가짜 메일함을 구분할 수 없으므로 결과는 전체 수신입니다. 상대방에게 직접 받은 주소일 때만 보내고, 반송을 살펴보세요.

이메일 확인 결과가 왜 알 수 없음으로 나오나요?

메일 서버가 그 주소에 대해 답하지 않았기 때문입니다. 저희 확인 서버를 그레이리스팅했거나(1분 뒤에 다시 시도하세요), 서버에 관한 규칙으로 거부했거나, 제때 응답하지 않았거나, 확인받지 않기를 요청하는 제공업체의 주소일 수 있습니다. 알 수 없음은 '아니요'가 아닙니다. 직접 받은 주소라면 대체로 괜찮습니다.

이메일의 전달 가능성과 스팸 점수는 어떻게 테스트하나요?

위의 '이메일 테스트'를 열고 일회용 주소를 복사하세요. 평소에 쓰는 같은 계정과 서비스에서 실제 메시지를 그 주소로 보내세요. 확인이 끝나는 항목부터 보고서가 만들어집니다: 발신 서버, SPF, DKIM, DMARC, 내용, 구독 취소 헤더, SpamAssassin, Gmail, Yahoo, Outlook.com의 규칙이며 10점 만점 점수가 나옵니다.

메일 테스트에서 10점 만점이 나오면 받은편지함에 도착하나요?

어떤 테스트도 그것을 약속할 수 없습니다. 받은편지함 도달은 발송 이력과 사람들이 스팸으로 신고하는 빈도에도 달려 있고, 이는 메일함 제공업체만 볼 수 있습니다. 10점 만점은 메일 한 통으로 확인할 수 있는 것 중 잘못된 것이 없다는 뜻입니다. 저희에게는 시드 메일함이 없으므로, 받은편지함 도달을 측정한다고 말하지 않습니다.

확인한 주소나 보낸 이메일을 저장하나요?

주소는 저장하지 않습니다. 로그에는 도메인과 메일 서버의 응답 코드가 남고, 확정된 답은 주소 없이 키 해시로만 최대 하루 동안 보관합니다. 테스트 메시지의 본문 전체와 첨부 파일은 분석 직후 삭제합니다. 보고서에는 헤더, 링크, 140자 미리보기를 7일간, 또는 '보고서 삭제'를 누를 때까지 보관합니다.

'이메일 주소 확인'은 검증(validation)과 무엇이 다른가요?

검증은 주소의 형식과 도메인을 확인합니다: 구문, 그리고 도메인에 메일 서버가 있는지입니다. 확인(verification)은 여기에 더해 메일 서버에 메일함 자체를 묻습니다. 이 이메일 확인 도구는 주소 하나에는 둘 다 합니다. 일괄 모드는 모든 행을 검증하고, 필요한 행의 메일함은 나중에 확인할 수 있게 해 줍니다.

이메일 주소 목록을 한꺼번에 확인할 수 있나요?

네, 한 번에 100개까지 붙여 넣거나 CSV 파일로 확인할 수 있고, 결과는 CSV로 내려받을 수 있습니다. 모든 행에서 구문, 도메인, 메일 서버, 목록을 확인합니다. 메일함은 선택할 때 하나씩 확인합니다. 메일 서버 100곳에 한꺼번에 묻는 것은 목록 정리에 해당하며, 메일 서버가 차단하기 때문입니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기