Public email posture · checked 2026-09-27

cloud.microsoft: DMARC, SPF and MX report

What public DNS says about how cloud.microsoft authenticates and routes email — read the way a receiving mail server reads it, with every change recorded since 2026-09-26.

grade A · enforcing DMARC with SPF hard failTranco rank 411 snapshot
Observed configurationPublic DNS only. Nothing here required access to cloud.microsoft.
DMARCp=reject
SPF-all
SPF lookups0/10
MXnone
DKIM selectorswildcard
MTA-STSno
RecordValue
MX—
SPFv=spf1 -all
DMARCv=DMARC1;p=reject;sp=reject;pct=100;aspf=s;adkim=s;rua=mailto:rua@dmarc.microsoft;ruf=mailto:ruf@dmarc.microsoft
DKIM selectorswildcard record answers every selector
MTA-STS / TLS-RPT / BIMIno / no / no
Providersinbound: Undetermined
Nameserversns1-33.azure-dns.com, ns2-33.azure-dns.net, ns3-33.azure-dns.org, ns4-33.azure-dns.info
Run a live DMARC checkBuild the digital twinLive tools re-query DNS now; this report is the 2026-09-27 snapshot.

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 enforces rejection

cloud.microsoft publishes p=reject. Receivers that honour DMARC refuse mail using this domain in From unless SPF or DKIM aligns. This is the strongest published posture; it depends on every legitimate sender — including third-party platforms — having an aligned path, and on the aggregate reports the record requests to catch regressions.

Strict alignment is in force

Both DKIM and SPF alignment are set to strict, so an authenticated identity must match cloud.microsoft exactly rather than sharing its organizational domain. Subdomain senders and platform-signed mail fail unless configured for the exact domain. Strict mode is deliberate and rare; it signals a tightly controlled sending estate.

SPF declares the domain sends no mail

The record is exactly v=spf1 -all: no source is authorized and everything fails. This is the correct posture for a domain that never sends, and combined with an enforcing DMARC policy it closes the domain to spoofing.

No MX record

cloud.microsoft publishes no mail exchanger. Under RFC 5321 a sender may fall back to the domain’s A or AAAA address and attempt SMTP delivery there, which usually reaches a web server that does not speak SMTP. If the domain is not meant to receive mail, a Null MX record (RFC 7505) tells senders so immediately.

A wildcard answers every DKIM selector

A query for a selector name that cannot exist still returns a record, so *._domainkey.cloud.microsoft is a wildcard. Selector discovery is not meaningful here; every name appears published. Wildcards are typically a null key (p=) used to revoke all selectors, or an accident that masks the real configuration.

Change history

No change has been observed since the first snapshot on 2026-09-26. 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-27; caches and split-horizon DNS can show different values elsewhere.

If you operate cloud.microsoft and want a record corrected or the report removed, contact Mailybox.