A90/100

microsoft.com

Receivers are told to reject mail that fails authentication for this domain.

Enforced

Receivers are told to reject mail that fails authentication for this domain. Keep watching aggregate reports so a new sending service does not silently start failing.

Score held up: DMARC is enforcing at p=reject, so nobody else can send as this domain. That is the hard part, and it is done. What is left below is about your own mail arriving, not about anyone spoofing you.

137 DNS queries · 335 ms

Fix these first

1
Selector 'selector2' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
2
Selector 's1024' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
3
Selector 'm1' uses a 1024-bit RSA key
Rotate to 2048-bit at your next key rotation.
4
No CAA record
Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"

Identity ·Sending services detected

Read from your SPF includes and MX hosts, then checked for a published DKIM key.

Microsoft 365SPF include:spf.protection.outlook.com (nested) · MX microsoft-com.mail.protection.outlook.comkey published · selector2

Identity ·DMARC

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Policy: reject
Coverage: 100%
Alignment: dkim=r spf=r

Identity ·DKIM

111 selectors probed

selector2Microsoft 365RSA 1024

s1024Microsoft (legacy)RSA 1024

m1MarketoRSA 1024

Identity ·SPF

Worst-case evaluation across every include.

v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.msft.net include:_spf1-meo.microsoft.com -all

DNS lookup budget7 / 10

include:_spf-a.microsoft.com
include:spf.protection.outlook.com
include:_spf-b.microsoft.com
include:_spf-mdm.microsoft.com
include:_spf-c.microsoft.com
include:_spf-ssg-a.msft.net
include:_spf1-meo.microsoft.com

Findings (7)

MediumSelector 'selector2' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 's1024' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

MediumSelector 'm1' uses a 1024-bit RSA key›

1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.

What to do

Rotate to 2048-bit at your next key rotation.

RFC 8301

LowNo explicit subdomain policy (sp=)›

Subdomains inherit p=, which is usually what you want. Setting 'sp=reject' explicitly protects unused subdomains even while the parent is still at p=none.

What to do

Consider adding 'sp=reject' if no subdomain sends mail.

LowNo CAA record›

Any certificate authority in the world may issue a certificate for this domain. That matters here because your MTA-STS policy is trusted on the strength of a certificate: a mis-issued one lets an attacker serve a policy you did not write.

What to do

Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"

RFC 8659

InfoEligible for BIMI›

Your DMARC policy is already enforcing, which is the hard prerequisite for BIMI. Publishing a logo is now largely a branding exercise.

What to do

Publish an SVG Tiny PS logo plus a VMC, then add a default._bimi record.

InfoZone is not signed with DNSSEC›

This is the common case and not a misconfiguration -- most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.

What to do

If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.

RFC 4033

Show 8 passing checks

PassAggregate reporting is configured›

Aggregate reports are requested at: [email protected].

PassDMARC policy is p=reject›

Mail failing authentication is rejected outright. This is the correct end state.

PassSPF lookup count is healthy (7/10)›

Worst-case evaluation stays within the limit with headroom to spare.

PassSPF ends in '-all' (hard fail)›

Unauthorised hosts are explicitly rejected. This is the correct end state.

PassMicrosoft 365's DKIM key is published at selector2._domainkey›

Detected via SPF include:spf.protection.outlook.com (nested), MX microsoft-com.mail.protection.outlook.com. A valid public key for this service is published at selector2._domainkey.microsoft.com.

Pass3 DKIM key(s) published›

Found at: m1, s1024, selector2.

PassMTA-STS is in enforce mode and covers every MX host›

The policy at https://mta-sts.microsoft.com/.well-known/mta-sts.txt is in enforce mode and its mx patterns match all 1 MX host. A sender that implements MTA-STS delivers only over TLS, with a valid certificate, to a host the policy lists.

RFC 8461 s5

PassTLS reporting is configured›

A TLS-RPT record at _smtp._tls.microsoft.com asks sending servers that support TLS reporting to send reports on failed TLS connections to https://tlsrpt.azurewebsites.net/report.

Transport and zone

Where your mail lands, and whether the DNS carrying your records can be trusted.

MXmicrosoft-com.mail.protection.outlook.com

Reverse DNSforward-confirmed on every host

MTA-STSpublished · mode: enforceSenders that implement MTA-STS deliver only over TLS to the MX hosts it lists.

TLS-RPTconfigured

BIMInot published

DNSSECzone not signedCommon and not a misconfiguration.

CAAno record · any CA may issue

DANEno TLSA records

This is the configuration. It is not the whole picture.

A DNS scan cannot tell you whether microsoft.com’s mail actually aligns, because alignment is decided per message at the receiver. Collect DMARC aggregate reports to see every source sending as this domain.

Watch this domain, free Check another domain