Find a domain's mail servers and provider, and check SPF, DKIM, DMARC, MTA-STS and BIMI against Gmail/Yahoo/Outlook rules.
Built & maintained by Pappu Venkata Subbi Reddy, founder of Clacify · Updated October 2026
MX Lookup shows which mail servers receive email for a domain and who runs them, then checks the rest of the domain's email setup in the same step. MX records are the part of DNS that tells the rest of the internet where to deliver mail for a domain, each with a priority that decides the order servers are tried in. Looking them up is the first step in diagnosing bounced mail, confirming a migration to Google Workspace or Microsoft 365, or finding out which provider a company or vendor uses. Because a working inbox is only half of email, the tool also checks the sending side: SPF, DKIM, DMARC, MTA-STS, TLS reporting and BIMI. It lays the results out against the sender requirements Gmail, Yahoo and Outlook enforce, and it is explicit about which of those can be confirmed from DNS and which can only be seen in a real message, so a green result here does not hide a gap.
All lookups go to public DNS over HTTPS, through Google Public DNS with Cloudflare as the fallback, and run in parallel. The MX query returns priority and host pairs, which are sorted with the lowest priority first, the order senders try them in under RFC 5321. The provider is identified by matching the mail server host names against the patterns each major provider uses, for example aspmx.l.google.com for Google Workspace, <tenant>.mail.protection.outlook.com for Microsoft 365, and pphosted.com for Proofpoint. A gateway such as Proofpoint or Mimecast in front of Microsoft 365 shows up as the gateway, because that is where mail is actually delivered. Two special cases are handled as the standards define them. A domain with no MX records is not necessarily unable to receive mail: RFC 5321 tells senders to fall back to the domain's A record, though in practice this usually means email was never set up. A domain that publishes a single MX of "0 ." is using the null MX of RFC 7505 to declare that it accepts no mail at all, so senders can fail immediately instead of retrying for days. The security checks reuse the engines of the dedicated tools: the full RFC 7208 SPF evaluation with lookup counting, RFC 9989 DMARC discovery, and DKIM probing of 35 common selectors with key-length measurement. MTA-STS (RFC 8461) is detected by its TXT record at _mta-sts.<domain>, TLS reporting (RFC 8460) by the record at _smtp._tls.<domain>, and BIMI by the record at default._bimi.<domain>.
| Requirement | Gmail / Yahoo, all senders | Bulk senders (5,000+ a day) | Checkable from DNS? |
|---|---|---|---|
| SPF or DKIM | Required | Both required | Yes |
| DKIM key 1024 bits or more | Required by Gmail | Required | Yes, if the selector is known |
| DMARC record | Recommended | Required (p=none minimum) | Yes |
| From domain aligned with SPF or DKIM | Recommended | Required | No: needs a real message |
| One-click unsubscribe (RFC 8058) | Not required | Required for marketing mail | No: needs a real message |
| Spam rate below 0.3% | Required | Required | No: Google Postmaster Tools |
Gmail and Yahoo since February 2024. Outlook.com applies SPF, DKIM and DMARC requirements to senders of more than 5,000 messages a day since May 5, 2025.
Lower numbers are tried first. Google Workspace domains set up before 2023 typically show five servers (aspmx.l.google.com at 1, two alt servers at 5 and two at 10), while newer setups use a single smtp.google.com. Both are correct. Microsoft 365 uses one host per tenant, ending in mail.protection.outlook.com, because Microsoft balances load behind that name. If you see servers from two different providers, check whether that is intentional: a forgotten backup MX at an old host is a common way for spam to bypass filtering, and after a migration a leftover record sends some of your mail to a mailbox nobody reads.
These three are optional, and most domains do not have them, which is why the tool shows them as "Not set" rather than as failures. MTA-STS closes a gap in ordinary email encryption: without it, a sending server that cannot set up TLS with you will usually fall back to sending in plain text, and an attacker who can interfere with the connection can force that. With MTA-STS, senders must use TLS with a valid certificate or not deliver at all. It needs both the TXT record checked here and a policy file at https://mta-sts.
DNS shows what a domain has published, not how its mail is actually sent. Alignment depends on which domain each sending service puts in the envelope and signs with, which only a delivered message reveals. Paste one into the Email Header Analyzer to see it. One-click unsubscribe is a header your marketing platform adds to each message. Spam complaint rate is measured by Gmail itself and reported only in Google Postmaster Tools, where Google advises keeping it below 0.1% and never reaching 0.3%. Tools that mark these items as passed from a DNS lookup alone are guessing, so this one marks them as unknown and tells you where to look.
An MX (mail exchanger) record tells other servers where to deliver email for a domain. Each has a priority number; lower numbers are tried first, and the others act as backups. If a domain has no MX records, senders fall back to its A record; a domain that wants no mail at all can publish a "null MX" (0 .) instead.
Since February 2024, Gmail requires every sender to set up SPF or DKIM, and those sending more than 5,000 messages a day to also have both, a DMARC record (p=none at minimum), alignment with the From domain, one-click unsubscribe for marketing mail and a spam rate under 0.3%. Yahoo has matching rules, and Outlook.com has rejected non-compliant bulk mail with error 550 5.7.515 since May 2025.
MTA-STS tells sending servers to deliver to you only over encrypted, verified connections. TLS reporting (TLS-RPT) sends you reports when that fails. BIMI lets supporting inboxes show your logo next to your messages, and requires DMARC at quarantine or reject. None is mandatory, but all strengthen a domain.
Lookups go live to public DNS each time, so changes appear as soon as they have propagated, usually within minutes and at most the record's TTL (often one hour).