What this configuration means
Each section below is shown because the observed records match its condition. The explanations are reviewed text selected by the data, not generated from it.
DMARC is in monitoring mode
The effective policy for live.com is p=none. Receivers evaluate alignment and send aggregate reports to the address in the record, yet they take no action on failures. Monitoring is the correct first stage; it becomes a gap when it lasts indefinitely, because spoofed mail is still delivered. Moving to quarantine and then reject, once reports show every legitimate sender aligns, is what turns the record into protection.
Subdomains carry a different policy
The record sets sp=quarantine while the organizational policy is p=none. Subdomains of live.com are therefore treated differently from the apex — a stricter policy that requires every sending subdomain to have its own aligned path.
SPF ends in soft fail
Unlisted sources produce softfail: receivers are asked to accept but mark the message. Under DMARC a softfail counts as an SPF failure, so the practical protection comes from DMARC policy rather than from ~all itself. Moving to -all is appropriate once the sender inventory is confirmed complete.
A single mail exchanger
Inbound mail depends on one published host, live-com.olc.protection.outlook.com. That host belongs to Microsoft 365, which provides its own redundancy behind the name. A single MX is normal for hosted mailbox providers and a risk for self-hosted ones.
DKIM selectors are published
One selector resolves under _domainkey.live.com: selector1. Selector names often identify the sending platform, and each represents a signing key that can produce an aligned DKIM path for DMARC — the path that survives forwarding.
MTA-STS is published
live.com declares a transport-security policy in enforce mode. Conforming senders refuse to deliver without authenticated TLS and refuse mail exchangers not listed in the policy — a strong posture that requires the policy to be updated whenever MX changes. TLS-RPT is also published, so transport failures are reported.
Sending platforms visible in DNS
Public records reference one platform: Microsoft 365. Each SPF include or DKIM selector is an authorization that someone must own. Platforms no longer in use remain authorized until the records are removed.
Change history
No change has been observed since the first snapshot on 2026-09-21. The domain is re-checked regularly and a new entry appears here when any record above changes.
How to read this report
The grade summarizes two records only: A means an enforcing DMARC policy with SPF hard fail; B enforcing DMARC with SPF; C monitoring-only DMARC or a weak SPF qualifier; D one of SPF or DMARC missing; F neither published. It is a prioritization aid for the public control plane, not a statement about deliverability, reputation or the security of the organization behind the domain.
DMARC policy is discovered with the RFC 9989 DNS tree walk, so a subdomain with no record of its own is reported with the organizational policy it inherits. DKIM selectors are discovered from common names only; a domain may sign with selectors this check does not try. Everything on this page comes from public DNS as observed on 2026-09-22; caches and split-horizon DNS can show different values elsewhere.
If you operate live.com and want a record corrected or the report removed, contact Mailybox.