How to Check Email Domain Records: MX, SPF, DKIM and DMARC Lookup

How to Check Email Domain Records: MX, SPF, DKIM and DMARC Lookup

When mail to or from a domain misbehaves, the first useful step is an email domain lookup: read the DNS records that decide where mail is delivered and which senders are trusted. Four record types do most of the work. MX says where incoming mail goes. SPF lists who may send for the domain. DKIM lets a receiver verify a signature. DMARC tells receivers what to do when SPF and DKIM do not line up with the visible From address.

This guide explains what each email domain record does, how to read a lookup result, and the mistakes that show up most often. Everything here is read-only: you are looking at public DNS, not changing anything.

The quick way to look

Enter the domain in the email and domain DNS checker to see MX, SPF, DMARC and the DKIM selectors you type in (up to three, for example selector1 and selector2) in one place. The lookup goes from your browser to Cloudflare's public resolver only when you click. For detail on a single record, use the SPF record inspector, the DKIM record inspector or the DMARC record inspector. The email DNS guide explains the wider picture. You can also query from a terminal, for example nslookup -type=TXT example.com on Windows, or Resolve-DnsName in PowerShell.

MX records: where mail is delivered

An MX record names the mail servers that accept mail for the domain, each with a priority number. Lower numbers are tried first. For a domain on Microsoft 365, the MX normally points to a host under mail.protection.outlook.com; the exact hostname is shown in the admin center for your domain, so copy it from there.

What to check:

• The MX hosts match the service you actually use. An old MX left from a previous provider sends mail to the wrong place.
• The hostnames resolve to addresses. An MX pointing at a name that does not exist causes bounces.
• If a filtering gateway sits in front of your mailbox service, the MX will point to the gateway, which is expected. It does affect some reporting, though.

SPF: who may send

SPF is a TXT record at the domain itself that begins v=spf1. A typical Microsoft 365 record is:

v=spf1 include:spf.protection.outlook.com -all

Each include: pulls in another sender's list, and -all at the end says everything else is not authorised. Microsoft's guidance for Microsoft 365 domains is to use -all, because DKIM and DMARC are expected alongside it. ~all is a soft fail and ?all is neutral.

Common mistakes:

• Two SPF records. A domain may publish only one. Two v=spf1 TXT records on the same name cause a permanent error, so merge them into one.
• More than 10 DNS lookups. SPF evaluation fails if it needs more than 10 lookups. Each include:, a, mx, exists and redirect counts, and nested includes add more. ip4: and ip6: entries do not count. Every extra marketing, CRM or ticketing service you add with an include: uses up part of that budget. Microsoft suggests moving other senders to subdomains, which each have their own SPF record and budget, or replacing stable vendors with IP ranges.
• +all. This authorises the entire internet to send as your domain. It is occasionally typed by mistake or left from testing, and it makes the record meaningless. An absent qualifier means the same thing as plus, so v=spf1 all is equally bad.
• Typing errors. A trailing dot after the domain, an equals sign instead of a colon after include, or a space after the colon all break the record.
• Forgetting subdomains. The SPF record for example.com does not cover mail.example.com. Each sending subdomain needs its own.

DKIM: a signature the receiver can check

With DKIM, your mail system signs each outgoing message with a private key. The receiver finds the matching public key in DNS at selector._domainkey.yourdomain. The selector is a label chosen by the sender, and it is stated in the s= part of the message's DKIM-Signature header. That is why a DKIM lookup needs both the domain and the selector: there is no way to list all selectors from the outside.

For a custom domain on Microsoft 365, DKIM uses two CNAME records, with the hostnames selector1._domainkey and selector2._domainkey. Their targets are specific to your tenant and domain. Microsoft documents two formats, and the older one looks like selector1-contoso-com._domainkey.contoso.onmicrosoft.com, whereas newer values end in dkim.mail.microsoft. Do not guess them. Read the exact values with Get-DkimSigningConfig in Exchange Online PowerShell or from the Defender portal, then publish the CNAMEs and enable signing for the domain. Two selectors exist so keys can be rotated without a gap.

Common mistakes:

• The CNAMEs are published, but signing was never switched on for the domain.
• The target was copied wrongly, or a DNS host appended the domain name to it automatically.
• A DKIM key published as a TXT record for a service that actually expects a CNAME, or the reverse.
• An outside service signs with its own domain. DKIM passes, but it does not align with your From address, so it does not help DMARC.

DMARC: what to do when checks fail

DMARC is a TXT record at _dmarc.yourdomain, for example:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A message passes DMARC if SPF or DKIM passes and the domain that passed aligns with the visible From domain. p= is the policy: none asks for no action and is used for monitoring, quarantine asks receivers to treat failures as suspicious and reject asks them to refuse. rua= is where aggregate reports go, and these reports are how you discover forgotten senders before they start failing.

Microsoft recommends a gradual rollout: start at p=none, review reports, move to quarantine, then reject, and use the pct= tag to apply the policy to a share of failing mail while you gain confidence. Do not jump to reject on a domain whose senders you have not inventoried.

Common mistakes: no DMARC record at all; the record placed at the root instead of _dmarc; more than one DMARC record; a report address with a typo; and leaving p=none indefinitely when the reports are clean.

Reading a result: a short order of checks

1. MX: does it point where your mailboxes live?
2. SPF: one record, correct includes, under 10 lookups, ending in -all or ~all by deliberate choice, never +all.
3. DKIM: the selectors you expect exist and signing is enabled.
4. DMARC: a record exists, the policy matches your rollout stage and reports reach someone who reads them.
5. Send a real test message and read the Authentication-Results header to confirm SPF, DKIM and DMARC all pass for the From domain.

A DNS lookup shows what is published, not whether a particular message passed. DNS changes can also take time to be seen everywhere, depending on the TTL. For step-by-step bounce diagnosis in Microsoft 365, see our mail flow troubleshooting guide.

Microsoft's own references are Set up SPF, Set up DKIM and Set up DMARC.