Analisador de autenticação de e-mail (Email Authentication Analyzer)
Cole o código-fonte completo de uma mensagem recebida — com os cabeçalhos — para ver o que um servidor receptor decide sobre ela: se o SPF autoriza o servidor de envio, se cada assinatura DKIM passa na verificação, se o DMARC passa com uma identidade alinhada, se a cadeia ARC está intacta, se um logotipo BIMI seria exibido e se o domínio do remetente exige TLS com MTA-STS.
Ao contrário de todas as outras ferramentas deste site, esta envia dados ao nosso servidor: quando você concorda e clica no botão, a mensagem inteira vai para o ecdsa.com para análise. Ela é verificada em memória e nunca é registrada em log, armazenada nem colocada em cache. Sem o seu consentimento, nada é enviado — o depurador de DKIM verifica as assinaturas no seu navegador.
Esta análise é feita no nosso servidor
As verificações de SPF, DMARC, ARC, BIMI e MTA-STS exigem consultas DNS em tempo real e downloads que um navegador não consegue fazer, por isso a mensagem inteira — cabeçalhos e corpo — é enviada ao ecdsa.com. Ela é analisada em memória e descartada logo após a resposta: nunca é registrada em log, armazenada nem colocada em cache, e nada do conteúdo dela é compartilhado com ninguém. Não envie mensagens que você não tem permissão para compartilhar com terceiros.
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.