E-posta DNS Kontrolü
Bir alan adının e-postayı nerede aldığı ve onun adına kimin gönderebileceği hakkında DNS'in söylediği her şey. Yalnızca genel DNS'ten okunur; hiçbir posta sunucusuyla bağlantı kurulmaz.
DKIM anahtarları gönderenin seçtiği bir seçici altında yayımlanır; bir iletinin DKIM-Signature başlığında s= olarak görünür.
Örnekler:u.aetdra.gov.aeexample.com
Biraz yavaşlayalım
Bu metin henüz Türkçe dilinde mevcut değil. Bir çeviri yayımlanana kadar İngilizce dilinde gösteriliyor.
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.
Sık sorulan sorular
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.