Vérification DNS e-mail
Tout ce que le DNS dit sur l’endroit où un domaine reçoit ses e-mails et sur qui peut envoyer en son nom. Lu uniquement dans le DNS public ; aucun serveur de messagerie n’est contacté.
Les clés DKIM sont publiées sous un sélecteur choisi par l’expéditeur ; il figure en s= dans l’en-tête DKIM-Signature d’un message.
Exemples:u.aetdra.gov.aeexample.com
Constats
- iLe domaine n’a aucun enregistrement MX.
- ?Aucun enregistrement SPF n’est publié.
- ?Aucun enregistrement DMARC n’est publié.
Serveurs de messagerie (MX)
Aucun enregistrement MX. Les e-mails sont alors livrés à l’adresse A/AAAA du domaine lui-même, s’il en a une.
Politique d’expéditeur (SPF)
Aucun enregistrement SPF. Les destinataires ne peuvent pas savoir quels serveurs ont le droit d’envoyer pour ce domaine.
Politique DMARC
Aucun enregistrement DMARC à _dmarc.u.ae. Les destinataires jugent par eux-mêmes les e-mails qui échouent à SPF et DKIM.
Sécurité du transport
- MTA-STS
- non publié
- Rapports TLS
- non publié
Interrogé via notre résolveur le 30 oct. 2026, 20:43. Les réponses sont mises en cache une minute.
Ce texte n’est pas encore disponible en français. Il est affiché en anglais en attendant une traduction.
Whether mail for a domain arrives, and whether mail claiming to come from it is believed, is decided almost entirely by a handful of DNS records. This tool reads all of them in one go.
MX records name the servers that receive mail for the domain, in order of preference (lower numbers first). Each MX host must itself have an A or AAAA record; the tool resolves the first five. A single MX of 0 . is a null MX (RFC 7505): the domain says it accepts no mail at all.
SPF (RFC 7208) is a TXT record starting with v=spf1 that lists the servers allowed to send as the domain: address ranges (ip4:, ip6:), other domains’ lists (include:) and a final rule for everything else, normally -all (fail) or ~all (softfail). A domain may publish only one SPF record, and evaluating it may take at most ten DNS lookups, counting every include, a, mx, ptr, exists and redirect — including the ones inside included records. Past ten, receivers return a permanent error, which is how large lists of cloud senders quietly break SPF.
DMARC (RFC 7489), at _dmarc.<domain>, tells receivers what to do with mail that fails both SPF and DKIM alignment — nothing (p=none), spam folder (quarantine) or refuse (reject) — and where to send aggregate reports (rua=). Starting with p=none and reading the reports before tightening is the usual path.
MTA-STS (RFC 8461) and TLS reporting (RFC 8460) ask sending servers to require TLS and to report failures. The DNS record only announces that a policy exists; the policy itself is a file on mta-sts.<domain> that this tool does not fetch.
DKIM keys sit at <selector>._domainkey.<domain>. The selector is chosen by whoever signs the mail, so it cannot be discovered from DNS: find it as s= in a received message’s DKIM-Signature header and enter it above.
Everything here comes from public DNS through our resolver. No connection is made to the domain’s mail servers.
Questions fréquentes
Why does the tool not find my DKIM key?
DKIM keys are looked up by selector, and selectors can't be listed from DNS. Copy the s= value from the DKIM-Signature header of a message the domain sent and enter it as the selector.
Is ~all or -all better?
-all tells receivers to reject mail from unlisted servers; ~all marks it as suspicious. Once DMARC is enforcing, receivers act on the DMARC policy anyway, so many domains keep ~all to avoid losing forwarded mail.
Does a good result mean my mail will be delivered?
No. These records are necessary, not sufficient: delivery also depends on the sending server's reputation, reverse DNS, content and the recipient's own filters.
Can I check an .ae domain?
Yes. The records are ordinary DNS and work the same under .ae, .co.ae or any other domain.