Email Authentication Analyzer — анализатор аутентификации почты
Вставьте полный исходный текст полученного письма вместе с заголовком, чтобы узнать, какое решение примет о нём принимающий сервер: разрешает ли SPF отправку с сервера, который передал письмо, проходит ли проверку каждая подпись DKIM, проходит ли DMARC с выровненным идентификатором, цела ли цепочка ARC, будет ли показан логотип BIMI и требует ли домен отправителя обязательного TLS с помощью MTA-STS.
В отличие от всех остальных инструментов сайта, этот отправляет данные на наш сервер: когда вы даёте согласие и нажимаете кнопку, всё письмо уходит на ecdsa.com для анализа. Его проверяют в памяти и никогда не записывают в журналы, не сохраняют и не кешируют. Без вашего согласия ничего не отправляется — отладчик DKIM проверяет подписи прямо в вашем браузере.
Этот анализ выполняется на нашем сервере
Для 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.