# DMARC Microsoft 365 > DMARC Microsoft 365 setup requires verified Microsoft admin guidance, account-specific DNS values, and four-layer validation before publishing changes. DMARC for Microsoft 365 must be configured from current Microsoft documentation and the specific Microsoft 365 tenant that sends mail. The available Microsoft Learn landing page identifies Learn as Microsoft's official documentation platform, but it does not provide a Microsoft 365 DMARC procedure, current admin-center path, DNS records, or sender requirement. Do not publish a DMARC record or change Microsoft 365 authentication settings from an example. ## Quick takeaways - A Microsoft 365 DMARC configuration needs current Microsoft documentation for the tenant and sending path in scope. - DNS values for a sending domain must come from the account and domain being configured. - A public DNS result does not prove that Microsoft 365 signs or sends a delivered message as expected. - A vendor status indicator does not replace inspection of a newly delivered message. - DMARC reporting is separate evidence from DNS, vendor status, and message-header results. - Use the [DMARC learning hub](/learning/dmarc) for Palisade guidance on the wider DMARC policy workflow. ## What should I check before configuring Microsoft 365? First, establish which Microsoft 365 sending path is in scope. A domain can be used by employee mail, applications, relays, marketing platforms, or other services. Each path needs its own evidence before an authentication or DMARC policy change is accepted. Confirm that the person making the change has authority to access the Microsoft 365 tenant and the authoritative DNS zone for the visible From domain. Keep a change record with the domain, tenant, sending path, DNS owner, approver, test mailbox, and rollback owner. Microsoft's [Learn platform](https://learn.microsoft.com/) is the appropriate official documentation location to use when confirming the current Microsoft 365 process. Do not infer a current admin-center path or setting name from an old procedure, a search result, or another tenant. > Copy DNS values from the account and domain you are configuring. Do not publish selectors, targets, tokens, or hostnames from another account or from an online example. For broader vendor setup planning, see Palisade's [vendor email authentication guidance](/learning/vendor-email-authentication). It can help separate the sender that creates a message from the domain and DNS zone that must be validated. ## Which setup method should I use? Use the method documented by Microsoft for the exact Microsoft 365 sending path and tenant. The available official material does not establish whether Microsoft 365 provides an automatic DMARC setup method, a manual DNS workflow, a dedicated-IP option, or a current authentication screen for this task. Do not choose a method based on an account-generated value from another organization. A copied selector, CNAME target, token, hostname, or TXT value can point at the wrong tenant or fail to authenticate the intended sending path. ![Four evidence layers required before accepting a Microsoft 365 DMARC change](/images/editorial/dmarc-microsoft-365/dmarc-microsoft-365-validation-flow.webp "1200x829") *Source: Palisade.* ## How do I configure SPF and DKIM for Microsoft 365? A publishable Microsoft 365 procedure requires Microsoft's current official instructions for the tenant's sender configuration. The available material does not support a current UI path, an SPF value, DKIM selector names, DKIM CNAME targets, verification controls, or a Microsoft-specific test procedure. ### 1. Confirm the current Microsoft 365 documentation Open the current Microsoft documentation that applies to the Microsoft 365 service and sending path in scope. Record the page title, URL, checked date, required role, and the exact settings path before making a change. Do not treat a general documentation landing page as proof of a specific configuration path. The relevant Microsoft page must describe the actual setting and the tenant context where it applies. ### 2. Select the exact sending domain Confirm the visible From domain for the messages that need authentication. Keep mailbox-hosted mail, application mail, relay traffic, and third-party mail using the same domain separate until each route has been tested. The selected domain must match the DNS zone that the authorized administrator can edit. If another team owns the DNS zone, stop until the proposed records and rollback plan have been reviewed. ### 3. Copy the DNS records from the Microsoft 365 tenant Copy only the DNS records generated or documented for the selected tenant and domain. Do not use example records as production configuration. A structural record format is shown below for change-review purposes only. It is not a Microsoft 365 record and must not be published. **Record type:** `TXT` **Host (illustrative only):** ```text _dmarc.yourdomain.com ``` **Value (illustrative only):** ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com ``` > Do not publish this example as a Microsoft 365 configuration. Use the exact record and reporting destination approved for your domain, and obtain Microsoft-specific DKIM values from the current Microsoft 365 documentation or tenant interface. Before saving any DNS change, inspect existing records at the same owner name. A DNS provider may append the zone name to the host field, which can create a duplicated domain name if a fully qualified host is pasted into a relative-host field. Record the final fully qualified name that the provider will publish. Do not replace an existing SPF, DKIM, or DMARC record merely to match an example. The current Microsoft documentation and the domain's existing records must determine whether the change is additive, a replacement, or a staged migration. ### 4. Verify the configuration in Microsoft 365 Return to the tenant interface or documented Microsoft verification path after public DNS answers with the intended record. Record the exact status, timestamp, selected domain, and any error text without altering it. A positive Microsoft status is useful vendor evidence. It does not prove that a real message from every production route has the expected authentication result. ### 5. Send a real test message Send a new message through the exact production path after the configuration change. Deliver it to a mailbox where an authorized operator can inspect the raw source and preserve a redacted copy with the change record. Do not accept a test message sent before the change, a message from a different system, or a message whose route cannot be identified. A configuration can appear correct in DNS while a separate sending route continues to use different authentication behavior. ## How does this setup affect DMARC? DMARC depends on evidence from the actual sending path and the visible From domain. A published DMARC record is only public DNS evidence. It does not show which production sources use the domain, which messages authenticate, or how a receiving mailbox evaluates an individual message. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the public DMARC record for the sending domain after DNS changes. Compare that result with the exact delivered message and the Microsoft 365 tenant evidence. A record check cannot prove the production sending path, a receiver's private decision, future placement, or continuous authentication state. ## How do I validate the setup? ### Check public DNS Query the exact owner names authorized for the selected domain. Compare the authoritative DNS answer with at least one public resolver and retain the results with the change record. Use the [DMARC checker](/tools/dmarc) for a public record check, then compare it with the authoritative response for the exact domain. A public check is a point-in-time DNS observation. ```bash dig +short TXT _dmarc.yourdomain.com ``` ### Check the Microsoft 365 status Use the current Microsoft tenant interface or documented verification process for the selected domain. Record the current status and any exact error text. Do not treat a green status as delivered-message evidence. It only shows that the Microsoft process accepted the configuration state it evaluated. ### Inspect a delivered message Inspect raw source from a newly delivered message sent through the production path. Preserve a redacted copy of the message headers with the domain, route, timestamp, and test result. Compare the visible From domain with the authentication results added by the receiving mailbox. If the message does not contain enough trusted receiver-added evidence to establish the result, do not infer that the configuration works. ### Review DMARC reports Review DMARC aggregate-report data after reports accumulate for the sending domain. Separate Microsoft 365 traffic from other sources that use the same visible From domain. Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it. A human reviews the evidence and applies any DNS or DMARC policy change. ## Troubleshooting ### The current Microsoft 365 path cannot be confirmed Use the official Microsoft documentation for the tenant's exact service and sending path. Do not follow an unverified admin-center path or rely on a screen capture without a current official source. Capture the documentation URL, checked date, required role, and exact setting labels before proceeding. If those details cannot be confirmed, pause the change. ### DNS does not return the intended record Check whether the DNS interface expects a relative host name or a fully qualified name. A provider that appends the zone can publish a duplicated owner name when the full domain is entered in the host field. Compare the authoritative answer with the intended fully qualified owner name before editing the value again. ### Microsoft 365 status and DNS results disagree Record both results, including the selected domain and the exact DNS owner queried. Confirm that the tenant, domain, and sending path are the same in both checks. Do not replace records repeatedly while the evidence is inconsistent. Resolve the mismatch between the authoritative answer and the current Microsoft instructions first. ### The public DMARC record is present but the delivered message remains unclear A public record does not establish the result for a particular message. Send a new message through the exact path under review and inspect its raw source in a mailbox that exposes the needed header evidence. If another service also sends as the domain, test that service separately. One successful route cannot establish the behavior of the others. ## Check the DMARC record behind the Microsoft 365 change After you have identified the sending domain and published an approved DNS change, use Palisade's [DMARC checker](/tools/dmarc) to inspect the public DMARC record. Compare the result with authoritative DNS, Microsoft 365 status, and a new delivered message from the same sending path. A passing record check does not prove that Microsoft 365 is signing every route, repair a tenant configuration, monitor later DNS drift, or guarantee receiver acceptance. For teams that need to identify every sending source using a domain and work through authentication or alignment issues over time, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=dmarc-microsoft-365). Palisade analyzes DMARC aggregate-report data and proposes prioritized remediation work, while your team reviews the evidence and applies the changes. Signup and trial do not require a credit card. ## Sources and further reading - [Microsoft Learn official documentation platform](https://learn.microsoft.com/) - [Palisade DMARC learning hub](/learning/dmarc) - [Palisade vendor email authentication guidance](/learning/vendor-email-authentication) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### Does Microsoft 365 require DMARC? Microsoft does not publish a blanket DMARC requirement for sending from a Microsoft 365 tenant. The pressure usually comes from the other direction, because the mailbox providers you send to set their own bulk-sender rules and your own security policy may require it anyway. Check Microsoft's current sender-requirements documentation for the exact service you use before treating DMARC as a Microsoft 365 obligation. ### How do I set up DMARC in Microsoft 365? Publish a DMARC TXT record at `_dmarc.yourdomain.com` in the DNS zone for the domain in your From address, starting at `p=none` with a reporting address you control. DMARC is a DNS change rather than a Microsoft 365 setting, so the tenant work is making sure SPF and DKIM are configured there for that same domain. Take the DKIM values from Microsoft's current documentation and your own tenant, because they are generated per tenant and cannot be copied from an example. ### What is Microsoft DMARC? There is no separate Microsoft version of DMARC. DMARC is an open standard, and the phrase normally just means setting up DMARC for a domain that sends through Microsoft 365. What is Microsoft-specific is where you enable DKIM and how the tenant handles your domain, not the DMARC record itself. ### What are DKIM and DMARC in Office 365? DKIM adds a signature to outgoing messages so a receiver can confirm they were not altered and came from your domain. DMARC then reads the SPF and DKIM results, checks whether either aligns with your visible From domain, and tells receivers what to do when neither does. In Office 365 you enable DKIM inside the tenant, while the DMARC record is a DNS change you publish yourself. ### Can a DMARC checker prove Microsoft 365 is configured correctly? No, because a checker only reads the DMARC record your domain publishes. It cannot see how your tenant is configured, which route a real message takes, or whether a receiver will accept your next message. Confirm those with the Microsoft tenant status and the headers of a message you actually sent.