How to Set Up DMARC for Microsoft 365 Without Breaking Your Email

To set up DMARC for Microsoft 365 safely, add include:spf.protection.outlook.com to a single SPF record, enable custom DKIM for your domain in the Microsoft Defender portal by publishing the two CNAME records exactly as Microsoft shows them, then publish a DMARC record at p=none. Only move to quarantine and reject once reports prove every other sender is aligned.

Before you start: the onmicrosoft.com trap

Every Microsoft 365 tenant is created with a default domain ending in onmicrosoft.com, for example yourcompany.onmicrosoft.com. When you add your own domain, users can send as name@yourcompany.co.za straight away, and mail appears to work perfectly. That is exactly why so many tenants are left half-configured.

Here is what is happening underneath. Unless you enable DKIM for your custom domain, Microsoft 365 signs outbound mail using the onmicrosoft.com domain. The DKIM signature is valid, so a quick header check shows dkim=pass. But DMARC requires the signing domain to align with the visible From domain, and yourcompany.onmicrosoft.com does not align with yourcompany.co.za. In that state your DMARC result depends entirely on SPF, and SPF alignment is fragile: it breaks on many kinds of forwarding.

So the first rule of a Microsoft 365 DMARC project is simple: custom DKIM is not optional. If you want the background on why signatures survive where SPF does not, see DKIM explained.

Before changing anything, gather three things:

1. Access to the DNS for your domain (your registrar, hosting control panel or DNS provider).
2. An account with sufficient admin rights in Microsoft 365 to manage email authentication settings in the Defender portal.
3. A current snapshot of your existing SPF, DKIM and DMARC records. The DMARC checker gives you this in one pass.

Step 1: the SPF record

Microsoft 365 needs its sending infrastructure listed in your SPF record. The mechanism is:

include:spf.protection.outlook.com

A domain that sends only through Microsoft 365 would publish a TXT record at the root of the domain like this:

v=spf1 include:spf.protection.outlook.com -all

Three rules apply, and breaking any of them is common:

• One SPF record only. If your domain already has an SPF record (from your hosting provider, an old mail server or a marketing tool), merge the Microsoft include into it. Two separate v=spf1 records cause a permanent error and SPF fails for everything.
• Stay within 10 DNS lookups. Each include, a, mx, exists and redirect costs lookups, and nested includes count too. Microsoft’s include uses some of your budget on its own. If you are close to the limit, read how to fix the 10-lookup limit before adding more.
• Remove what no longer sends. Old hosting server IPs and includes for services you cancelled years ago waste lookups and widen the set of servers allowed to send as you.

Whether you end in ~all or -all matters less once DMARC is enforced, because DMARC makes the final decision. What matters is that the list is complete and accurate.

Step 2: enabling DKIM in the Microsoft Defender portal

Custom DKIM for Microsoft 365 is managed in the Microsoft Defender portal, under the email authentication settings within the threat policies area of Email and collaboration. Microsoft occasionally moves menu items, so if the path looks different, search the portal for “DKIM”.

The process is:

1. Open the DKIM settings and select your custom domain (not the onmicrosoft.com domain).
2. Microsoft displays two CNAME records, one for selector1._domainkey and one for selector2._domainkey on your domain. Copy the host names and target values exactly as Microsoft shows them for your tenant. Do not copy them from a blog post, a colleague’s tenant or an old document, because the target values are specific to your tenant and Microsoft has changed the format over time.
3. Publish both CNAMEs in your DNS. Some DNS panels append your domain automatically to the host field, so check you have not created selector1._domainkey.yourcompany.co.za.yourcompany.co.za.
4. Wait for DNS to propagate, then return to the portal and enable signing for the domain. If the portal reports that the CNAMEs cannot be found, wait longer and check the records with a DNS lookup tool rather than recreating them.

Two selectors exist so that Microsoft can rotate keys without breaking signing: one key is active while the other is prepared. Because they are CNAMEs pointing to Microsoft, rotation happens without further DNS changes on your side.

How to verify signing is working

Do not rely on the portal status alone. Send a message from a Microsoft 365 mailbox to an external account you control, such as a personal Gmail address, and open the full message headers (in Gmail, “Show original”). Look at the Authentication-Results line. You want to see dkim=pass with header.d=yourcompany.co.za, not your onmicrosoft.com domain. Once the DMARC record is published in the next step, the same line should also show dmarc=pass. Repeat this test for every custom domain in the tenant that sends mail, because each one is configured separately and it is easy to enable the primary domain and forget a secondary brand.

Step 3: publishing the DMARC record

With SPF corrected and DKIM signing as your domain, publish a TXT record at _dmarc.yourcompany.co.za:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.co.za

Start at p=none. This changes nothing about delivery, but receiving servers begin sending aggregate reports to the rua address. Use a dedicated mailbox or a reporting service, not a person’s inbox, because the volume of XML attachments can be considerable. If the reporting address is on a different domain, that domain must publish an authorisation record, or receivers will not send to it.

A note on the onmicrosoft.com domain itself: if any mail genuinely goes out from that address, Microsoft documents how to add a DMARC record for it through the Microsoft 365 admin centre, since you do not control its DNS directly. Most businesses should simply make sure nothing sends from it.

The other senders that break things

Microsoft 365 is rarely the only system sending as your domain. These are the usual suspects in a South African SME:

A full approach to inventorying these is in our article on the services that send as you. The key point for Microsoft 365 tenants is that the platform being correctly configured does not mean the domain is ready for enforcement.

Step 4: a staged rollout that does not block your own mail

With monitoring in place, the work becomes evidence-led. Use this sequence:

1. Observe for a full business cycle. At least one month, including month-end, so statements, payslips and debit order notifications appear in the data.
2. Confirm Microsoft 365 traffic passes with aligned DKIM. If you still see onmicrosoft.com as the DKIM domain, signing is not enabled correctly.
3. Fix or retire every other source in the reports. Unknown sources sending small volumes that fail are often spoofing attempts, which is precisely what enforcement will stop.
4. Move to p=quarantine, optionally with a reduced pct value first, and watch for complaints from staff and clients.
5. Move to p=reject once quarantine has run cleanly. Make the change early in the week, never on a Friday, and keep a note of the previous record so you can roll back quickly.

The broader reasoning behind each step is in our DMARC policy rollout guide.

A pre-enforcement checklist

• One SPF record, under 10 lookups, no stale entries.
• Custom DKIM enabled and signing for every custom domain in the tenant.
• Every legitimate third-party sender passing DMARC in recent reports.
• Parked and unused domains already at p=reject.
• A named person who approves the change and knows how to roll it back.

How MailMarq helps

MailMarq handles this rollout for Microsoft 365 tenants without needing any mailbox passwords: we supply the exact DNS records (or apply them where we manage your DNS), read the reports, chase the third-party senders and recommend each policy step for your written approval. Contact us for a free assessment of your domain.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.