Microsoft 365 (mail)

An MX record whose host matches Microsoft's mail hosts, read from public DNS.

An SPF record including Microsoft's sender policy counts as evidence when no MX points at Microsoft.

The provider is reported as a mail provider in the technology inventory.

The detection then decides which DKIM selectors are probed.

Microsoft's documentation explains that two key pairs are generated when DKIM signing is enabled for a custom domain, and that the private keys are inaccessible.

The public keys are reached through CNAME records whose host names are the same for every organisation: `selector1._domainkey` and `selector2._domainkey`.

Only one selector is active; the other is used after a key rotation.

A domain that only sends from its initial `onmicrosoft.com` domain is signed automatically and needs none of this — custom domains are the ones that need the CNAMEs.

The engine queries both selector names for a Microsoft 365 domain and follows the CNAME to the published key.

Microsoft's SPF guidance says most Microsoft 365 organisations require `include:spf.protection.outlook.com` in the domain's SPF record, with other services added as further includes.

Its DMARC guidance describes `p=none` for testing and tuning, and `p=reject` or `p=quarantine` for enforcement.

It also documents that outbound mail failing DMARC at the destination, from domains with a quarantine or reject policy, is routed through a high-risk delivery pool.

So a Microsoft 365 domain moving to enforcement with a broken DKIM setup pays twice: in rejections and in delivery reputation.

The DMARC guidance also states that `pct` defaults to 100 when absent, so every failing message gets the policy unless a lower percentage is set for testing.

It can read the MX, SPF, DKIM CNAMEs and DMARC records exactly as published.

It cannot tell which selector is currently active, since that is decided inside the tenant.

It cannot see transport rules, connectors or mailbox configuration.

It never sends mail.

`email.mx.present` and `email.mx_targets` report the MX records and where they point.

`email.spf.present`, `email.spf.single` and `email.spf.lookups` report the sender policy.

`email.dkim.selectors` reports both Microsoft selectors and whether a key was found behind each.

`email.dmarc.present`, `email.dmarc.policy` and `email.dmarc.alignment` report the DMARC record.

Microsoft's PowerShell reference for creating a DKIM signing configuration lists key sizes of 1024 or 2048 bits, with 1024 shown as the default for that command.

Other ways of enabling DKIM may choose differently, which is why the size of the published key is worth reading rather than assuming.

For SPF, Microsoft recommends ending the record with `-all`, a hard fail, for Microsoft 365 domains, because it also recommends DKIM and DMARC and relies on DMARC to decide what happens to failures.

The engine reports the size class of the key found behind each selector and the ending of the SPF record, which are the two values these recommendations turn on.