Microsoft DMARC Compliance Checker

Check public SPF, DMARC, and common DKIM selectors for Outlook.com. Confirm authentication with a real message test.

What does the Microsoft compliance checker verify?

This checker inspects public SPF and DMARC records and common DKIM selectors. Use it as a DNS baseline, then test a message from the affected platform for SPF, DKIM, and DMARC alignment. Published records alone cannot prove Outlook.com acceptance.

Requirements checked September 28, 2026 against Microsoft’s 550 5.7.515 guidance. For the message-level diagnosis, follow the 550 5.7.515 repair guide.

Can this checker prove Microsoft compliance?

The Microsoft compliance checker inspects public SPF and DMARC records and probes common DKIM selectors. It cannot establish whether a production message passes SPF, DKIM, or DMARC alignment. Test a message through the same sending platform and inspect its authentication results.

Who must meet Outlook.com's authentication requirements?

Microsoft documents 550 5.7.515 for domains sending 5,000 or more messages per day to its consumer services, including Outlook.com, Hotmail, Live.com, and MSN, using the same visible From domain. This is not a blanket diagnosis for Microsoft 365 tenant rejections.

Does SPF need an include mechanism?

No. An SPF record can authorize sending IP addresses directly. The relevant question is whether the message's actual source is authorized by its Return-Path domain, not whether the record contains include:.

Does an unconfirmed DKIM result mean signing is disabled?

No. This checker probes common selectors. A sending platform may use a different selector. Find the selector in the message's DKIM-Signature header or the provider's settings, then look up that exact selector and verify a newly sent message.

Must I change DMARC to p=reject?

Microsoft accepts a valid p=none, p=quarantine, or p=reject policy for this requirement. Both SPF and DKIM must pass on the message, and at least one passing identifier must align with the visible From domain so DMARC passes. Tightening policy alone does not repair authentication.

How can I investigate the results with Palisade MCP?

Copy the result's prepared MCP prompt and connect Palisade to your assistant. The prompt includes the checked domain and DNS findings. Palisade can inspect available reports and matching tasks, propose a fix for review, and verify DNS after approved publication. External DNS publishing uses approved provider access or Smart DNS Deployment in the app. Retest the actual sending stream afterward.

Microsoft's rules hinge on DMARC. Here are the DMARC record tags to know.

vVersion: The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
pDMARC policy: The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
ruaAggregate report destination: The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
rufForensic report destination: The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
spSubdomain policy: The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
adkimDKIM alignment: The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
aspfSPF alignment: This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
foForensic reporting options: The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
rfFailure report format: The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
pctPercentage (historic): The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
riReporting interval: The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.