メール認証アナライザー
受信したメッセージのソース全体をヘッダーごと貼り付けると、受信側のサーバーがそのメッセージをどう判定するかを確認できます。SPF が送信サーバーを許可しているか、各 DKIM 署名の検証に成功するか、アライメントの取れた識別子で DMARC が pass するか、ARC チェーンが壊れていないか、BIMI ロゴが表示されるか、送信者のドメインが MTA-STS で TLS を強制しているかがわかります。
このサイトの他のツールとは異なり、このツールはデータをサーバーに送信します。同意してボタンを押すと、メッセージ全体が解析のために ecdsa.com に送られます。メッセージはメモリ上でチェックされ、ログへの記録、保存、キャッシュは一切行われません。同意しない限り何も送信されません。DKIM デバッガーなら、ブラウザー内で署名をチェックできます。
この解析は ecdsa.com のサーバーで実行されます
SPF、DMARC、ARC、BIMI、MTA-STS のチェックには、ブラウザーでは実行できないリアルタイムの DNS ルックアップとダウンロードが必要なため、メッセージ全体（ヘッダーと本文）が ecdsa.com に送信されます。メッセージはメモリ上で解析され、結果を返すと同時に破棄されます。ログへの記録、保存、キャッシュは一切行われず、内容が誰かと共有されることもありません。第三者との共有が許可されていないメッセージは送信しないでください。
Six checks, one verdict
Email has no built-in sender authentication: anyone can write any address into the From: field. What receivers rely on instead is a stack of DNS-published policies and cryptographic signatures, each answering a narrower question than people expect. This analyzer runs all of them on a message the way a receiving server does, with mailauth — the library many mail systems use — and explains each result.
SPF (RFC 7208) asks whether the server that connected is allowed to send mail for the domain in the envelope sender (MAIL FROM, which ends up in Return-Path) — not the From: address a reader sees. The domain lists its servers in a TXT record; -all makes everything else fail, ~all only softfails. A record may trigger at most ten further DNS lookups through include, a, mx and redirects; past that it is a permanent error. SPF needs the connecting IP address, which is not in the message itself — the analyzer reads it from the topmost Received header that records a connection, or takes it from you.
DKIM (RFC 6376) is a signature over selected header fields and the body, made by the domain in the signature's d= tag with a key published at <selector>._domainkey.<domain>. It survives forwarding as long as nobody changes the signed parts, and fails when a mailing list adds a footer or rewrites the subject. Keys shorter than 1024 bits and rsa-sha1 are no longer accepted (RFC 8301).
DMARC (RFC 7489) ties the two to what the reader sees. A message passes when SPF or DKIM passes for a domain aligned with the From: domain — the same domain, or under relaxed alignment the same organizational domain. The domain's _dmarc record then tells receivers what to do with mail that fails: nothing (p=none), quarantine it, or reject it. Most of the confusing results of email authentication come from alignment: SPF can pass for a bulk mailer's bounce domain and DKIM can pass for its signing domain, and DMARC still fails because neither is the sender's own domain.
ARC (RFC 8617) lets intermediaries that break SPF and DKIM — mailing lists, forwarding services — record what they saw before changing the message, and seal that record. A receiver that trusts the intermediary can then accept a message whose own DMARC result failed in transit. The analyzer checks that the chain of ARC sets is complete and that every seal and message signature verifies.
BIMI (draft-brand-indicators-for-message-identification) only starts once DMARC passed with an enforcing policy. It looks up the From: domain's logo record and, when the record names one, downloads the Verified or Common Mark Certificate and the logo and checks that they belong together; the BIMI and VMC decoder explains every part of that check.
MTA-STS (RFC 8461) is about the next message rather than this one: it lets the sender's domain require that mail sent to it travels over TLS with a valid certificate, to MX hosts listed in a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. The analyzer fetches the policy and checks the domain's MX records against it.
The output also includes the Authentication-Results header a receiver would add (RFC 8601), which is the format to compare with the header your own mail server wrote.
Why this tool sends the message to our server
Every other tool on this site works in your browser. This one cannot: SPF needs DNS records of types a web page cannot query, MTA-STS policy files and BIMI certificates sit on servers that send no CORS headers, and the whole evaluation takes dozens of lookups that have to follow the same rules a mail server follows. So the analysis needs the whole message on our server — and the page sends it only after you tick the box that says so.
On the server, the message lives in memory for the length of the request and is dropped with the answer: it is not logged, not stored, and the answer is marked uncacheable. DNS goes over DNS-over-HTTPS with a budget of 60 queries and five seconds per query; every download goes through the guarded path that screens addresses, pins connections and caps sizes; the whole analysis stops after 25 seconds. A message of more than 1 MB, or one that contains a private key, is refused before it is analysed.
If you would rather not send a message anywhere, the DKIM debugger verifies its DKIM signatures in your browser, fetching only the public keys. SPF and DMARC need the server-side view; the debugger tells you which parts it could not check.