What the checker does
Microsoft 365 and Google Workspace each publish a list of DNS records your domain needs for email. Miss one and mail may not arrive, may fail authentication, or may land in spam. This checker reads your public DNS and compares it with what the platform's own documentation asks for:
- MX: does mail for your domain go to the platform?
- SPF: does your SPF record include the platform's servers?
- DKIM: are the platform's DKIM records published?
- DMARC: is there a DMARC policy?
- Autodiscover (Microsoft 365 only): can Outlook find mailbox settings automatically?
Choose your platform, or leave it on Detect platform: we work it out from your MX records, or from your SPF record when your MX points somewhere else. Each row shows what the platform expects, what we found and how to fix it. We only read public DNS; nothing is changed.
What Microsoft 365 expects
| Record | Name | Value | Notes |
|---|---|---|---|
| MX | @ |
Your tenant's host, <token>.mail.protection.outlook.com |
Copy it from the admin center. Microsoft says to give it the highest priority, typically 0 |
| TXT (SPF) | @ |
v=spf1 include:spf.protection.outlook.com -all |
Add the include to your existing record if you already have one |
| CNAME | autodiscover |
autodiscover.outlook.com |
Optional but, in Microsoft's words, highly recommended |
| CNAME | selector1._domainkey |
Value from the Defender portal | DKIM for your custom domain |
| CNAME | selector2._domainkey |
Value from the Defender portal | Used after a key rotation |
Sources: Add DNS records to connect your domain and External DNS records for Microsoft 365.
Two newer formats matter:
- DKIM: for new custom domains since May 2025, the CNAME targets look like
selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. Domains added earlier keep the older format,selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Microsoft notes that the two formats can't coexist for the same selector (Set up DKIM). The checker accepts both. - MX with DNSSEC: domains that turn on inbound SMTP DANE with DNSSEC move their MX to a host ending in
mx.microsoft, such ascontoso-com.o-v1.mx.microsoft, and remove the oldmail.protection.outlook.comrecord (How SMTP DANE works). The checker accepts both.
Microsoft 365 doesn't DKIM-sign mail from a custom domain until you publish the CNAME records and turn signing on, and without that DKIM can't pass DMARC for your From address. Our DKIM setup guide for Microsoft 365 and Google Workspace walks through it.
What Google Workspace expects
| Record | Name | Value | Notes |
|---|---|---|---|
| MX | @ |
smtp.google.com, priority 1 |
Accounts set up before 2023 may use the legacy aspmx.l.google.com set, which Google still supports |
| TXT (SPF) | @ |
v=spf1 include:_spf.google.com ~all |
Google's example when Google Workspace is your only sender |
| TXT (DKIM) | google._domainkey |
The key from the Admin console | google is the default prefix selector; you can choose another |
| TXT (DMARC) | _dmarc |
For example v=DMARC1; p=none; rua=mailto:… |
Start with monitoring |
Sources: Google Workspace Admin Help on MX records, SPF, DKIM and DMARC.
If you chose a DKIM prefix other than google, the checker can't find your key by name and says so; check the selector you chose with the DKIM Checker. After you publish the key, you still have to select Start authentication in the Admin console.
When your MX points to a filtering service
Many businesses put a filtering service or gateway in front of Microsoft 365 or Google Workspace. Then the MX points to the service, not to the platform, and the service delivers clean mail onward. That's a valid setup, so the checker reports it as information rather than a failure, and still checks SPF, DKIM, DMARC and autodiscover for mail the platform sends.
What the platform needs in that case is different:
- Microsoft 365: an inbound connector for the service, ideally with Enhanced Filtering for Connectors, so Microsoft sees the original sender's IP instead of the service's. Our guide on Microsoft 365 connectors explains the options.
- Google Workspace: the service's IP addresses set up as an inbound gateway in the Admin console.
If the platform's MX is listed but isn't the highest priority, the checker warns you: senders use the lowest preference number first, so the platform only gets mail when the first server is down.
How to read the results
| Status | Meaning |
|---|---|
| Pass | The record is published as the platform expects. |
| Warning | It works, but something is missing or unusual, such as only one of the two Microsoft DKIM records. |
| Fail | A required record is missing or wrong, such as SPF without the platform's include. |
| Info | Not a problem: for example, a filtering service in front of your platform. |
| Not tested | A lookup timed out. That says nothing about your records; check again. |
For the full picture of your domain's email security, including MTA-STS and TLS reporting, run the Email Health Check. Moving MX records? Follow how to change MX records without losing email first.
Limitations
- DNS only. We can't see your admin console, so we can't tell whether DKIM signing is turned on, whether your domain is verified, or how connectors are set up.
- Your exact values come from your tenant. Microsoft's MX token and DKIM targets are unique to each tenant. We check the format, not that the value is the one your admin center shows.
- Detection is a best guess. If your MX points to a filtering service and your SPF includes both platforms, or neither, choose the platform yourself.
- Domain verification records (such as Microsoft's
MS=ms…TXT record or Google's verification record) are part of adding the domain to the platform, and the checker doesn't look for them.
Sources
- Microsoft Learn: Add DNS records to connect your domain
- Microsoft Learn: External DNS records for Microsoft 365
- Microsoft Learn: Set up DKIM to sign mail from your Microsoft 365 domain
- Microsoft Learn: How SMTP DANE works
- Google Workspace Admin Help: Set up MX records for Google Workspace
- Google Workspace Admin Help: Set up SPF
- Google Workspace Admin Help: Set up DKIM
- Google Workspace Admin Help: Set up DMARC
Frequently asked questions
What DNS records does Microsoft 365 need for email?
An MX record pointing to your tenant's mail.protection.outlook.com host (or a mx.microsoft host if you use DNSSEC), an SPF record that includes spf.protection.outlook.com, an autodiscover CNAME to autodiscover.outlook.com, and two DKIM CNAME records for selector1 and selector2. Microsoft also recommends a DMARC record. The admin center shows your exact values.
What is the Google Workspace MX record?
smtp.google.com with priority 1, a single record. Domains that started using Google Workspace before 2023 may have the legacy set that starts with aspmx.l.google.com. Google says those values are still supported and any account can switch to smtp.google.com.
Why do my Microsoft 365 DKIM records end in dkim.mail.microsoft?
That's the newer DKIM CNAME format Microsoft introduced in May 2025 for new custom domains, for example selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. Domains set up before then keep the older format ending in onmicrosoft.com. Both are valid; copy the values the Defender portal shows.
My MX points to a spam filter, not Microsoft 365 or Google. Is that wrong?
No. With a filtering service in front of your mailboxes, your MX points to that service, and it passes clean mail on to Microsoft 365 or Google. The checker reports this as information, not a failure. Your platform still needs SPF, DKIM and DMARC for the mail it sends.
Can the checker tell whether DKIM signing is turned on?
Not completely. DNS shows whether the DKIM records are published, not whether signing is switched on in the Defender portal or the Google Admin console. To confirm, send a message to an outside mailbox and check that its DKIM-Signature uses your domain and passes.
Related guides
Email DNS records explained: which ones do you need?
Every DNS record email uses, in one place: MX, SPF, DKIM, DMARC, PTR, MTA-STS, TLS-RPT, BIMI and autodiscover, with example values and which ones you need.
11 min read SPF, DKIM & DMARCHow to set up DKIM in Microsoft 365 and Google Workspace
Step-by-step DKIM setup for Microsoft 365 (two CNAME selectors) and Google Workspace (one TXT key): 2048-bit keys, key rotation and how to verify it works.
9 min read Setup guidesHow do you set up email on a new business domain?
Setting up email on a new business domain? Follow this checklist: MX, SPF, DKIM, DMARC from p=none to enforcement, optional MTA-STS and BIMI, PTR and warm-up.
10 min read