DMARC Creator for Microsoft 365 — Secure Your Organization's Email
Set up DMARC for Microsoft 365 and Exchange Online. Generate a valid DMARC record, understand M365 defaults, and protect your domain from spoofing.
Last updated: 2026-01-28
Your organization relies on Microsoft 365 for email, calendars, and collaboration. Exchange Online handles the heavy lifting: routing, filtering, compliance. But Microsoft does not publish a DMARC record for your custom domain. That is on you.
Without DMARC, anyone can send email that appears to come from your domain. Your clients receive phishing messages that look like they are from your finance team. Your partners get spoofed invoices. And your legitimate emails have a harder time reaching inboxes because receiving servers have no way to verify your domain's authenticity. DMARC Creator helps Microsoft 365 admins generate the right record and get it published quickly.
What Microsoft 365 Configures by Default
Microsoft 365 provides some email authentication out of the box, but not all of it. Knowing what is already in place helps you understand what you still need to set up.
SPF is typically configured during onboarding. When you add a custom domain to Microsoft 365, the setup wizard asks you to publish an SPF record. The standard record for M365-only domains looks like this:
v=spf1 include:spf.protection.outlook.com -all
This tells receiving servers that Microsoft's Exchange Online servers are authorized to send email for your domain. If you also use other services that send email as your domain, those need to be included too. You can build a complete SPF record at spfcreator.com.
DKIM requires manual setup. Microsoft 365 supports DKIM signing for custom domains, but it is not automatically enabled. You need to go into the Microsoft 365 Defender portal (or the Exchange admin center), navigate to Email authentication, then DKIM, select your domain, and enable DKIM signing. Microsoft will ask you to publish two CNAME records in your DNS that point to Microsoft-hosted DKIM keys. Once those records are in place and verified, Exchange Online begins signing outgoing messages. You can generate DKIM records for other sending services at dkimcreator.com.
DMARC is not created for you. Microsoft does not publish a DMARC record for your custom domain. You need to generate one and add it to your DNS yourself. Our step-by-step DMARC setup guide covers the full process. This is the step most M365 admins miss, and it is the step that DMARC Creator makes easy.
Microsoft 365 uses its own domain (onmicrosoft.com) for the default DKIM signature if you have not enabled DKIM for your custom domain. This means DKIM alignment with your custom domain will fail, and your DMARC results will depend entirely on SPF. For a detailed explanation of how alignment works, see our guide on DMARC alignment explained. Enable DKIM signing for your custom domain before publishing a DMARC record.
Why Microsoft 365 Organizations Need DMARC
If your email runs through Microsoft 365, DMARC is the final piece that completes your authentication stack and gives you control over your domain's reputation.
Protect against business email compromise
BEC attacks are one of the most costly forms of cybercrime, and they often start with a spoofed email from a trusted domain. DMARC with a reject policy prevents attackers from sending emails that impersonate your executives, finance team, or HR department.
Improve inbox placement
Gmail, Yahoo, and other major providers factor DMARC into their delivery decisions. A valid DMARC record with proper SPF and DKIM alignment helps your team's emails land in the inbox rather than the spam folder, especially when reaching contacts outside your organization.
Satisfy security and compliance requirements
Microsoft 365 is popular in industries with strict compliance needs: healthcare, finance, legal, government contracting. SOC 2 audits, HIPAA assessments, and vendor security questionnaires increasingly require a published DMARC policy with enforcement. Having DMARC in place before the audit saves time and demonstrates mature security practices.
Gain visibility into unauthorized senders
DMARC aggregate reports reveal every server that attempts to send email using your domain. For M365 admins, this often uncovers forgotten services, shadow IT tools, or active spoofing campaigns that would otherwise go unnoticed.
Setting Up DMARC for Microsoft 365
Here is the process for Microsoft 365 admins, from prerequisites to a published DMARC record.
Confirm your SPF record includes Microsoft 365
Verify that your domain's SPF record contains include:spf.protection.outlook.com. If your organization also sends email through other platforms (marketing tools, CRM systems, helpdesk software), each one needs its own include entry. Build or update your record at spfcreator.com.
Enable DKIM signing for your custom domain
In the Microsoft 365 Defender portal, go to Email and collaboration, then Policies and rules, then Threat policies, then Email authentication settings, then DKIM. Select your domain and enable DKIM signing. Publish the two CNAME records Microsoft provides in your DNS, then confirm they are detected.
Generate your DMARC record
Use the generator below to create your DMARC record. Start with a p=none policy and specify a reporting email address. The tool produces a correctly formatted record ready for your DNS.
Publish the TXT record in your DNS
Add a TXT record at _dmarc.yourdomain.com with the value from the generator. If you manage DNS through Azure DNS, Cloudflare, GoDaddy, or another provider, the process is the same: create a TXT record with the name _dmarc and your DMARC string as the value.
Verify your record is live
Check that the record is published correctly using dmarcrecordchecker.com. DNS propagation usually takes a few minutes, but can take up to 48 hours in some cases.
Moving to Enforcement on Microsoft 365
Publishing a DMARC record with p=none is the starting point, not the finish line. The real protection comes when you move to an enforcing policy. Here is the recommended progression for Microsoft 365 organizations.
Phase 1: Monitor with p=none. Keep this policy in place for at least two to four weeks. During this time, you receive aggregate reports from major mail providers showing how your domain's email is performing against SPF, DKIM, and DMARC checks. Review these reports to confirm all legitimate email sources are passing. For a deeper explanation of what each policy level means, see our guide to DMARC policy levels.
Phase 2: Quarantine gradually. Update your record to p=quarantine; pct=25;. This sends 25% of failing messages to the recipient's spam folder. Monitor for a week. If no legitimate email is affected, increase to pct=50, then pct=100. At each stage, check with your team to make sure no one is reporting missing messages.
Phase 3: Enforce with p=reject. Once quarantine at 100% has run cleanly for a week or two, move to p=reject. This is the strongest protection available. Receiving servers will drop any message from your domain that fails DMARC. Spoofed emails are blocked entirely, never reaching the inbox or even the spam folder.
Check your DMARC reports before each phase
Before tightening your policy, always review your most recent aggregate reports. Look for any legitimate sending sources that are failing DMARC. Common culprits in Microsoft 365 environments include third-party marketing platforms, ticketing systems, and automated notification tools that send email as your domain.
Microsoft 365 and DMARC Reporting
One of the benefits of DMARC is the reporting it provides. When you include a rua tag in your DMARC record, receiving mail servers send you aggregate reports detailing every email they received from your domain and whether it passed or failed authentication.
What to expect. Reports arrive as compressed XML files, usually once per day from each major mail provider (Google, Microsoft, Yahoo, Apple, and others). Each report contains the sending IP address, the authentication results for SPF and DKIM, and whether DMARC alignment passed.
Microsoft 365 as a report sender. Microsoft also sends DMARC aggregate reports to other domains. If you receive email at your M365 organization and the sender has a DMARC record with a rua address, Microsoft generates and sends those reports on your behalf. This is automatic and requires no configuration.
Reading the reports. Raw XML reports are not easy to read. For a practical introduction to interpreting this data, see our complete DMARC for Microsoft 365 resource guide. For organizations managing multiple domains or receiving high volumes of email, a monitoring tool that parses and visualizes the data is a significant time saver. The Email Deliverability Suite provides ongoing monitoring of your DMARC, SPF, DKIM, and MX records with alerts when something changes.
Simplify DMARC monitoring for your M365 organization
Track your email authentication records daily. Get alerts when a record changes or breaks.
Common Microsoft 365 DMARC Issues
DKIM not enabled for the custom domain. This is the most frequent problem. M365 signs messages with the default onmicrosoft.com domain unless you explicitly enable DKIM for your custom domain. Without custom DKIM, your DMARC alignment depends solely on SPF, which fails when email is forwarded. Our DKIM vs. DMARC comparison explains why both protocols are necessary.
Multiple domains in the same tenant. If your M365 tenant has multiple custom domains (common in organizations with subsidiary brands or regional domains), each domain needs its own SPF record, DKIM configuration, and DMARC record. A DMARC record on your primary domain does not cover your other domains.
Hybrid Exchange configurations. Organizations running a hybrid setup with on-premises Exchange and Exchange Online need to ensure both environments are included in their SPF record and both are signing with DKIM. A partial configuration means some messages pass DMARC and others fail, depending on which server sent them.
Third-party services sending as your domain. Just like with any email platform, services like Salesforce, HubSpot, Zendesk, or custom applications that send email as your M365 domain need their own SPF and DKIM entries. Check your DMARC reports for unknown sending sources before moving to enforcement.
Related Articles
Monitor Your DMARC Record
You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss a DMARC issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring