Email Authentication
Look up and analyze SPF, DMARC, and DKIM records so mail policy problems show up before they become deliverability or spoofing incidents.
Shows mechanisms, DNS lookup count, and risky patterns such as +all.
Explains whether the domain is in monitoring, quarantine, or reject mode.
Looks up specific selectors and estimates public key strength when possible.
Examples
Selectors are optional. If you know your DKIM selector names, add them as comma-separated values.
Email authentication is where spoofing resistance, deliverability, and incident visibility all meet.
Teams often publish SPF and DKIM but leave DMARC at p=none for too long, which limits enforcement.
A single analyzer makes it easier to review mail posture during migrations, audits, and on-call debugging.
SPF, DKIM, and DMARC each solve a different part of the mail authentication problem.
_dmarc.domain and tells receivers what to do when SPF or DKIM alignment fails.selector._domainkey.domain.This analyzer does not recursively validate every external include chain, but it provides a strong first-pass operational review of what is visible in DNS.
For modern production mail, yes. SPF and DKIM provide signals, and DMARC tells receivers how to enforce them.
SPF evaluation is limited to 10 DNS lookups. Large include chains can break policy evaluation.
You can still analyze SPF and DMARC. DKIM needs one or more known selector names to query.
Not always. It is useful for staged rollout, but it should usually progress toward quarantine or reject once reporting is understood.