# How do you enable DMARC for Microsoft 365? > Enable DMARC for Microsoft 365 custom domains with the right SPF, DKIM, DNS record, rollout policy, and validation checks. To enable DMARC for Microsoft 365, publish a DMARC TXT record at `_dmarc.yourdomain.com` after SPF and DKIM are working for every Microsoft 365 custom domain or subdomain that sends mail. Microsoft recommends a gradual rollout: start with `p=none`, monitor reports, move to `p=quarantine`, then move to `p=reject` after legitimate mail is aligned. The change is made in DNS, not by flipping one Microsoft 365 tenant switch for an active custom domain. ## Quick takeaways - DMARC for an active Microsoft 365 custom domain is a DNS record at `_dmarc`, not a single Defender portal toggle. - Microsoft says to configure SPF and DKIM for all sending custom domains and subdomains before publishing or tightening DMARC. - Start active sending domains at `p=none` with aggregate reporting, then move gradually to `p=quarantine` and `p=reject`. - Microsoft 365 DKIM for custom domains requires two CNAME records and Defender portal or Exchange Online PowerShell verification. - Parked domains and `*.onmicrosoft.com` domains have separate guidance. Do not treat them like normal active custom domains. - Validate with DNS, Microsoft DKIM status, delivered-message headers, and DMARC aggregate reports before increasing enforcement. ![Microsoft 365 DMARC enablement flow from sender inventory through SPF, DKIM, DNS publication, monitoring, quarantine, reject, and validation](/images/editorial/how-do-you-enable-dmarc-for-microsoft-365/microsoft-365-dmarc-rollout.svg) *DMARC enforcement should follow evidence, not calendar pressure. [Open the full-size Microsoft 365 DMARC rollout map](/images/editorial/how-do-you-enable-dmarc-for-microsoft-365/microsoft-365-dmarc-rollout.svg).* ## Microsoft 365 DMARC starts with the sending domain Microsoft's current [DMARC setup guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) says custom domains and subdomains should have SPF TXT records and DKIM signing configured before DMARC is configured. That matters because DMARC only passes when a message has a passing SPF or DKIM identity that aligns with the visible From domain. Start by listing every domain and subdomain that appears in outbound From addresses: - employee mailbox domains, such as `example.com` - shared mailbox or application domains - marketing subdomains - transactional subdomains - legacy domains that still send through Microsoft 365 - domains that do not send and should be treated as parked Do not publish one aggressive parent-domain policy until you know how subdomains behave. Microsoft recommends starting with a lower-volume or less complex domain or subdomain, then saving the parent domain for last. The guide to [Microsoft's equivalent to Google Postmaster Tools](/learning/what-is-microsoft-s-equivalent-to-google-postmaster-tools) is useful if you are separating Microsoft consumer-mail telemetry from Microsoft 365 tenant administration. ## Prerequisites before you publish DMARC ### SPF covers Microsoft 365 and other real senders Microsoft's [SPF configuration guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) says SPF identifies valid email sources for a domain through a DNS TXT record. For a Microsoft 365-only custom domain in the worldwide cloud, Microsoft shows an SPF value with `v=spf1`, the include `spf.protection.outlook.com`, and an `-all` ending. That example is not enough if the same domain also sends through an on-premises server, CRM, help desk, marketing platform, or cloud application. Add only the sources that actually send for that domain. Microsoft also notes that each defined subdomain requires its own SPF record and that only one SPF record is allowed per domain or subdomain. If you are fixing a Gmail-specific SPF problem at the same time, use the [Gmail SPF error diagnostic guide](/learning/why-does-gmail-report-an-spf-error) to confirm the exact MAIL FROM domain and connecting IP before editing DNS. ### DKIM signs with the custom domain Microsoft's [DKIM guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) says custom domains do not automatically DKIM sign outbound mail in the same way the initial `*.onmicrosoft.com` domain does. For a custom domain, Microsoft 365 generates two selector CNAME records. You publish those records at the domain's DNS host, then enable DKIM signing in the Defender portal or Exchange Online PowerShell. Use the values Microsoft gives you for the specific domain. The DKIM article warns that example CNAME values are illustrative and that the correct values should come from the Defender portal or PowerShell. Microsoft also introduced an updated DKIM CNAME format for new custom domains in May 2025, so old examples are not a reliable source for a new tenant. For a custom domain in the Defender portal, Microsoft describes this path: - go to **Email & collaboration** > **Policies & rules** > **Threat policies** > **Email authentication settings** - select the **DKIM** tab - choose the custom domain or subdomain - copy the required CNAME records - publish both CNAMEs at the DNS host - return after DNS is detected and enable signing ### You have somewhere useful to send reports DMARC aggregate reports are XML files. Microsoft recommends designating specific people to monitor reports and using a specific mailbox or Microsoft 365 Group rather than delivering reports to an individual user's mailbox. For most teams, a dedicated report processor or DMARC monitoring platform is easier than a normal inbox. The important point is that someone must be able to read reports, identify legitimate sources, and decide when enforcement is safe. ## How do you publish the Microsoft 365 DMARC record? ### 1. Choose the starting policy For active sending domains, start with monitoring: Example value: - Version: `v=DMARC1` - Policy: `p=none` - Percent: `pct=100` - Aggregate reports: `rua=mailto:d@example.com` Microsoft's active-domain rollout example starts at `p=none` with reporting, then moves to `p=quarantine`, then `p=reject`. Use your own report address. If the report address is outside the domain, confirm any external-report authorization required by the reporting provider. ### 2. Add the TXT record at the DNS host Create one TXT record at the DMARC owner name: - Hostname: `_dmarc` - TXT value: your `v=DMARC1` policy - TTL: use the DNS host's normal value unless your change-control process requires a temporary lower TTL For `example.com`, the full owner name is `_dmarc.example.com`. For `marketing.example.com`, the full owner name is `_dmarc.marketing.example.com`. Do not create several DMARC TXT records at the same owner name. Publish one policy for that exact domain or subdomain. ### 3. Monitor reports before enforcement Microsoft says DMARC aggregate and forensic reports show numbers and sources of messages that pass and fail DMARC checks. Use the `p=none` phase to answer operational questions: - Which services send as this domain? - Which sources pass SPF or DKIM but fail alignment? - Which sources are unknown? - Which subdomains send mail unexpectedly? - Which sources only fail at some receivers? - Which legitimate senders need DKIM, SPF, or route changes before enforcement? Do not shorten this phase just because the DNS record is syntactically valid. A valid `p=none` record is a starting point, not proof that `p=reject` is safe. ### 4. Move to quarantine in controlled increments After legitimate traffic is passing aligned authentication, change the policy to quarantine: Example value: - Version: `v=DMARC1` - Policy: `p=quarantine` - Percent: `pct=100` - Aggregate reports: `rua=mailto:d@example.com` Microsoft notes that `pct=` can gradually affect more messages and gives example increments of `pct=10`, `pct=25`, `pct=50`, `pct=75`, and `pct=100`. Use partial enforcement when the domain is complex, the business impact is high, or a sender has just been repaired. ### 5. Move to reject when evidence supports it When quarantine reports and delivered-message checks show that legitimate mail is aligned, move to reject: Example value: - Version: `v=DMARC1` - Policy: `p=reject` - Percent: `pct=100` - Aggregate reports: `rua=mailto:d@example.com` Microsoft describes the goal as reaching `p=reject` for custom domains and subdomains, but it also warns that you need to test and verify along the way to prevent good mail from being rejected because of unintended DMARC failures. ## How do parked and onmicrosoft.com domains differ? For parked custom domains that should never send mail, Microsoft's DMARC guide recommends: ```txt v=DMARC1; p=reject; ``` Microsoft's SPF guide pairs parked domains with: ```txt v=spf1 -all ``` Microsoft also says DKIM CNAME records are not recommended for parked domains. That makes sense: a parked domain has no legitimate outbound signing route to enable. The `*.onmicrosoft.com` domain is different because Microsoft owns the domain. Microsoft says the initial `*.onmicrosoft.com` domain is already covered for SPF and automatically DKIM signs outbound messages. Microsoft now provides admin-center steps for adding a DMARC TXT record for `*.onmicrosoft.com` domains, with `_dmarc` as the TXT name and `v=DMARC1; p=reject` as the basic value. Do not copy a parked-domain policy onto an active custom domain that still has unverified senders. Use the active-domain rollout for domains that send real mail. ## Validate the setup ### 1. Check DNS for the exact domain Query `_dmarc.example.com` and confirm one TXT record begins with `v=DMARC1`. Also confirm SPF for each active domain or subdomain and the two DKIM selector CNAME records Microsoft provided. The free [DMARC checker](/tools/dmarc) can inspect the public DMARC record. Use the [SPF checker](/tools/spf) for SPF syntax and lookup risk. These checks prove public DNS visibility, not that a specific Microsoft 365 message is aligned. ### 2. Check Microsoft DKIM status In the Defender portal, confirm that the custom domain's DKIM status shows signing enabled. In Exchange Online PowerShell, Microsoft documents `Get-DkimSigningConfig` with fields such as `Name`, `Enabled`, `Status`, `Selector1CNAME`, and `Selector2CNAME` for reviewing DKIM configuration. Do not enable DMARC enforcement while the domain still shows missing CNAMEs or disabled DKIM unless you have another aligned authentication path and have verified it in delivered headers. ### 3. Send a real message through the same route Send from the exact Microsoft 365 mailbox, shared mailbox, application, or relay route that will use the domain. Inspect a delivered message at Gmail, Outlook.com, Yahoo, or another mailbox provider that exposes authentication results. Confirm: - SPF passes for the expected MAIL FROM domain where that route depends on SPF - DKIM passes with a `d=` domain aligned to the visible From domain - DMARC passes for the visible From domain - the message did not route through an unexpected gateway or third-party platform The article on [reading Authentication-Results in Gmail headers](/learning/how-do-you-read-authentication-results-in-gmail-headers) explains how to inspect those results on a delivered message. ### 4. Watch aggregate reports before tightening policy Wait for DMARC aggregate reports from normal production mail. Reporting volume depends on where your mail is received and whether receivers send reports. Microsoft notes that the amount and variety of DMARC reports varies with mail volume and recipient systems. Move policy only when the reports show legitimate sources are aligned and unknown sources are understood. If a new legitimate sender appears, fix the sender before increasing enforcement. ## Palisade helps with the report-analysis part Palisade does not publish DNS records, enable Microsoft 365 DKIM, change Defender settings, control recipient filtering, or guarantee inbox placement. Palisade can analyze DMARC aggregate reports for domains you control. That helps IT teams and MSPs identify Microsoft 365 and non-Microsoft senders, compare SPF and DKIM alignment, find unknown sources, and decide when a domain is ready for the next policy stage. Use the free [Email Security Score](/tools/email-security-score) to inspect public SPF and DMARC posture. If you need an ongoing workflow for sender inventory and staged DMARC enforcement across domains or clients, [start a Palisade account](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=microsoft_365_dmarc&utm_content=how_do_you_enable_dmarc_for_microsoft_365) after your first Microsoft 365 domain is reporting. ## Frequently asked questions ### Is there a Microsoft 365 switch that enables DMARC? Not for an active custom domain. You publish a DMARC TXT record in DNS. Microsoft 365 provides SPF, DKIM, and admin-center guidance, but the active custom-domain DMARC policy lives at `_dmarc.yourdomain.com`. ### Should I start Microsoft 365 DMARC at p=reject? No, not for an active sending domain unless you have already verified every legitimate source and alignment path. Microsoft recommends starting with `p=none`, monitoring, moving to `p=quarantine`, and then moving to `p=reject`. ### Do I need DKIM before DMARC in Microsoft 365? Usually yes. Microsoft says custom domains should have SPF and DKIM configured before DMARC. DKIM is especially important when forwarding, gateways, or third-party senders make SPF alignment fragile. ### What DMARC record should I use for a parked Microsoft 365 domain? For a parked domain that should not send mail, Microsoft recommends `v=DMARC1; p=reject;`. Pair it with an SPF record such as `v=spf1 -all`, and do not add DKIM CNAMEs for a domain that has no legitimate sending route. ### Does Microsoft 365 send DMARC reports for every message? No. DMARC reports depend on destination email systems and normal mail volume. Microsoft notes that the amount and variety of reports varies. Treat aggregate reports as operational evidence over time, not as a complete per-message log. ### Will DMARC improve Microsoft 365 deliverability? Stronger SPF, DKIM, and DMARC help receivers trust authorized domain use and reduce spoofing risk. They do not guarantee inbox placement. Microsoft says delivery is not guaranteed even when mail is authenticated.