Email Authentication Analyzer — analyseur d’authentification des e-mails
Collez la source complète d’un message reçu, en-têtes compris, pour voir ce qu’en décide un serveur destinataire : si SPF autorise le serveur expéditeur, si chaque signature DKIM est valide, si DMARC réussit avec une identité alignée, si une chaîne ARC est intacte, si un logo BIMI s’afficherait, et si le domaine de l’expéditeur impose TLS avec MTA-STS.
Contrairement à tous les autres outils de ce site, celui-ci envoie des données à notre serveur : lorsque vous donnez votre accord et appuyez sur le bouton, le message entier est transmis à ecdsa.com pour analyse. Il est vérifié en mémoire et n’est jamais journalisé, stocké ni mis en cache. Sans votre consentement, rien n’est envoyé ; le débogueur DKIM, lui, vérifie les signatures dans votre navigateur.
Cette analyse s’exécute sur notre serveur
SPF, DMARC, ARC, BIMI et MTA-STS nécessitent des requêtes DNS en direct et des téléchargements qu’un navigateur ne peut pas effectuer : le message entier, en-têtes et corps, est donc envoyé à ecdsa.com. Il est analysé en mémoire et supprimé dès l’envoi de la réponse : il n’est jamais journalisé, stocké ni mis en cache, et rien de son contenu n’est partagé avec qui que ce soit. N’envoyez pas de messages que vous n’êtes pas autorisé à partager avec un tiers.
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.