API

샌드박스에서 사용해 보기 → 모든 엔드포인트에 라이브 서비스에서 실행하는 버튼이 있습니다. 여기서는 키가 필요하지 않으므로 이 페이지에서 보내는 요청은 실제 요청입니다. 실제 주소를 예약하며 사용량에 포함됩니다.

절차

요청 두 번과 이메일 한 통입니다. 분석에 몇 초가 걸리기 때문에 세 번째 호출이 필요합니다.

1. 주소 예약

   받은편지함 엔드포인트에 POST합니다. 정확히 한 개의 메시지를 수신하고 한 시간 후 만료되는 주소와, 나머지 모든 항목의 키로 사용되는 슬러그를 받습니다.

2. 실제 메시지 전송

   캠페인을 전송할 플랫폼에서 SMTP를 통해 보냅니다. 검사 항목 중 절반은 전송 플랫폼이 추가하는 헤더를 확인하므로, 직접 작성한 메시지를 사용하면 잘못된 항목을 측정하게 됩니다.

3. 상태 폴링 후 보고서 확인

   상태 엔드포인트의 응답은 수백 바이트이며 전체 보고서를 가져올 준비가 되었는지 알려 줍니다. 보고서 자체는 수천 줄에 달합니다.

# 1. reserve a single-use address
curl -sX POST 'https://email-spam-tester.com/api/v1/inbox?lang=en'

{
  "address": "test-<slug>@t.email-spam-tester.com",
  "slug": "<slug>",
  "expires_at": "2026-01-01T12:00:00Z"
}

# 2. send your message to that address, then poll
curl -s 'https://email-spam-tester.com/api/v1/tests/<slug>/status'

{
  "slug": "<slug>",
  "analysis_status": "checks_ready",
  "ai_status": "running",
  "checks_done": 39,
  "checks_total": 39
}

# 3. read the report once analysis_status is checks_ready
curl -s 'https://email-spam-tester.com/api/v1/tests/<slug>'

{
  "report_url": "https://email-spam-tester.com/t/<slug>",
  "score_ours": 86.4,
  "score_compat": 9.2,
  "subscores": {"auth": 100.0, "infra_spam": 78.1, "content": 92.0, "compliance": 75.0},
  "complete": true,
  "checks": [
    {
      "id": "auth.dmarc",
      "status": "warn",
      "title": "DMARC result",
      "summary": "DMARC passes, but the policy is p=none.",
      "weight_ours": -4.0,
      "evidence": {"policy": "none", "aligned": "dkim"},
      "citations": {"standards": [{"title": "RFC 9989 §4.7", "quote": "..."}]}
    }
  ],
  "fixes": [
    {"id": "dmarc-enforce", "gain_ours": 4.0, "gain_compat": 0.0,
     "fix": {"title": "Move DMARC to quarantine", "severity": "medium"}}
  ]
}

인증

없습니다. 요청할 키도, 설정할 헤더도, 생성할 계정도 없습니다. 반환받는 슬러그 자체가 접근 권한입니다. 슬러그를 가진 사람은 누구나 해당 보고서를 읽을 수 있고, 그 외의 사람은 이를 추측할 수 없습니다.

엔드포인트

기본 주소는 https://email-spam-tester.com입니다. 모든 응답은 JSON입니다.

보고서 읽기

원하는 순서대로 답을 제공하는 필드입니다.

상태

검사 상태는 다섯 가지 중 하나이며, 그중 두 상태의 차이는 보기보다 더 중요합니다.

analysis_status는 received, analyzing, checks_ready, failed 순으로 진행됩니다. ai_status는 pending, running, ready, fallback, error 순으로 진행됩니다. 결정론적 보고서는 checks_ready에서 최종 확정되며, ai_status는 계획만 추가합니다.

반환될 수 있는 항목

알아둘 네 가지

머신용

• /api/openapi.json API를 제공하는 동일한 코드에서 생성된 OpenAPI 설명입니다.
• /llms.txt, /llms-full.txt 언어 모델을 위한 이 사이트의 간략한 맵으로, llms.txt 규칙을 따르며 전체 루프와 보고서 필드를 한 파일에 담은 더 긴 버전도 제공합니다.
• /mcp 동일한 기능과 블로킹 대기 기능을 제공하는 MCP 서버로, 모델 내부에서 폴링하는 것보다 효율적입니다.
• For agents 에이전트 페이지: 언제 이것을 사용해야 하는지, 건너뛴 검사를 통과한 검사와 비교해 해석하는 방법, 그리고 어떤 결과가 에이전트가 편집할 수 있는 텍스트가 아니라 사람이 변경해야 하는 DNS 레코드인지 설명합니다.