Publish a DMARC TXT record at _dmarc on your domain, but only once SPF and DKIM are verified and passing. Start at p=none so you can watch aggregate reports without affecting deliverability, then move domain by domain, low-volume subdomains first, toward p=quarantine and eventually p=reject. Skipping SPF and DKIM checks risks quarantining your own invoices, newsletters, or customer replies, so always verify those first.
TL;DR:
- Always verify SPF includes your email providers and publish DKIM CNAMEs before setting DMARC to avoid false positives or legitimate mails being rejected.
- Publish your DMARC record at
_dmarc.yourdomain.co.ukwith correct syntax and no duplicate records, and verify withdigorhostimmediately after publishing.- Begin with
p=noneand monitor reports from low-volume subdomains for several weeks to identify unknown senders and fix alignment issues before enforcing stricter policies.- Ensure all senders, including third-party tools or niche platforms, have proper SPF and DKIM configurations; ignorance here causes most failures during enforcement.
- Conduct regular checks of DNS records, message headers, and aggregate reports during each stage, and involve technical support if DNS access or multiple senders complicate setup.
Table of Contents
- What you need before you touch DNS for DMARC Office 365 setup
- How do you publish an Office 365 DMARC record correctly?
- How do you read DMARC reports and stage your rollout?
- Why is my mail failing DMARC in Microsoft 365?
- Getting subdomain inheritance and parked domains right
- How do you verify each stage of DMARC office 365 setup?
- What TTOY Digital’s rollout checklist looks like
- The rollout mistake most guides skip over
- Get help rolling out DMARC without the DNS guesswork
- Sources
- FAQ
What you need before you touch DNS for DMARC Office 365 setup
Most DMARC problems in Microsoft 365 tenants trace back to one thing: someone published the record before checking what was actually sending mail. Before you go anywhere near a microsoft 365 dmarc setup, get four things confirmed.
1. Confirm who controls your authoritative DNS. For a custom domain (yourbusiness.co.uk), that’s your registrar or DNS host, not the Microsoft 365 admin centre. Microsoft is explicit about this: there’s no admin portal button and no PowerShell cmdlet for adding a DMARC record on a custom domain. If your domain runs through GoDaddy, 123 Reg, Cloudflare, or an IT reseller’s panel, that’s where the record goes. Only .onmicrosoft.com domains get DMARC through the admin centre itself. Propagation is usually quick, often under an hour, but plan for up to 48 hours if your host has long TTLs on existing records.
2. Verify your SPF record includes Microsoft’s sending infrastructure. Your SPF TXT should contain include:spf.protection.outlook.com, and the whole record needs to resolve as one single TXT value; two separate SPF records will break validation outright. Check for stray characters, missing ~all or -all qualifiers, and old includes left over from a previous email provider.
3. Publish DKIM CNAMEs and switch on tenant signing. In Defender for Office 365, generate the two CNAME records (commonly labelled selector1 and selector2), publish them at your DNS host, then flip the DKIM toggle in the Security portal. Skip this step and Microsoft 365 signs your outbound mail as onmicrosoft.com by default, which will not align with your custom domain and will fail DMARC even though the mail is entirely legitimate. The Relaymetry guide to Microsoft 365 authentication walks through the exact CNAME format if your DNS host’s interface is unfamiliar.
4. Build a full sender inventory. List every system that sends mail using your domain: your CRM, invoicing tool, marketing platform, helpdesk software, scanners and printers that email scanned documents, and any third-party gateway. Each one needs its own SPF include or DKIM signing arrangement, or it will fail DMARC the moment you enforce.
Pro Tip: Ask your marketing team directly what they use to send campaigns. IT departments are routinely blindsided by a Mailchimp or HubSpot account nobody mentioned, and that’s exactly the kind of sender a DMARC rollout catches out first.
How do you publish an Office 365 DMARC record correctly?
The record itself is short, but the details matter more than most guides let on. A DMARC TXT record always sits at the hostname _dmarc.yourdomain.co.uk, and the core syntax looks like this at the monitoring stage:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.co.uk
Once reports confirm clean alignment, you tighten the policy:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.co.uk; pct=100 (when used, though recent guidance advises caution with pct usage)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.co.uk
A few practical notes that trip people up constantly:
- Quote your value if your DNS host demands it. Some registrar panels need the full string in quotation marks; others reject the record if you add quotes. Check your host’s own field format before pasting.
- Set a short TTL while iterating, around 3,600 seconds, then lengthen it once the record is stable. This lets fixes propagate fast during the testing phase.
- Custom domains go at the DNS host;
.onmicrosoft.comgoes in the admin centre. These are two different publishing routes, and mixing them up is one of the most common errors reported in step-by-step DMARC setup guides for Office 365. - Never publish two DMARC TXT records on the same hostname. Validators will only read one, usually unpredictably, and the record effectively becomes useless.
- Get the
rua=mailto:syntax exact. A missing colon, a stray space, or an unescaped comma between multiple report addresses will silently break report delivery. - Don’t forget the underscore.
dmarc.yourdomain.co.uk(no underscore) is a different hostname entirely and DMARC validators won’t find it.
One detail worth calling out: the mxio guide to Microsoft 365 DMARC recommends verifying the record with dig or host immediately after publishing, before you move on to anything else. A five-minute check here saves days of confused report data later.
How do you read DMARC reports and stage your rollout?
Set up a dedicated mailbox for your rua address, something like dmarc-reports@yourdomain.co.uk, rather than routing reports into a personal inbox where they’ll get ignored. Aggregate reports arrive as compressed XML files, and reading them by hand is painful beyond a handful of senders. A report parser tool turns that XML into a readable table of sending IPs, pass/fail counts, and alignment results.
A sensible staging sequence:
- Start with one low-volume subdomain, not your primary sending domain. If you have a
news.yourdomain.co.ukused for a small newsletter, that’s a safer testbed than your main transactional domain. - Publish
p=noneand monitor for several weeks. This is long enough to catch a monthly billing run, a quarterly newsletter, or a seasonal marketing campaign that might not send every week. - Move that subdomain to
p=quarantineonce reports show consistent alignment passes with no unexplained failures. - Repeat across other subdomains, then advance the parent domain last, following the same sequence Microsoft itself recommends for reducing the risk of blocking legitimate mail.
- Only move to
p=rejecton the parent domain once every subdomain and sender has cleared monitoring cleanly.
Watch for three signals in your reports: sending IPs you don’t recognise (often a forgotten SaaS tool or an old mail relay), a pattern where DKIM passes but SPF fails (usually forwarding, which breaks SPF but not DKIM), and a source failing both checks consistently (almost always a sender that needs its own DKIM signing configured).
Pro Tip: Resist the temptation to lean on the pct= tag to enforce policy gradually across a percentage of mail. Recent guidance around RFC updates favours staging by domain and time instead, since partial-percentage enforcement produces confusing, inconsistent report data that’s hard to act on.
If your organisation has multiple marketing tools feeding campaign data alongside your DMARC rollout, it’s worth having a look at how marketing teams structure their own reporting dashboards too, since sender visibility and campaign visibility often need to be solved together.
Why is my mail failing DMARC in Microsoft 365?
DMARC passes when either SPF or DKIM passes and aligns with the domain in your From header. Alignment is the part people miss: SPF can technically pass while still failing DMARC if the domain in the return path doesn’t match your visible sending domain closely enough.
Three Microsoft 365 specific issues cause most failures:
- Tenant DKIM isn’t enabled. Mail gets signed as
onmicrosoft.comby default, which never aligns with a custom domain. Fix: publish the CNAMEs and switch on signing in Defender. - A hybrid connector or on-premises relay rewrites headers. Mail routed through an on-prem Exchange server or a security gateway before reaching Microsoft 365 can strip or alter signatures. Fix: configure the connector to preserve DKIM signatures, or apply DKIM at the gateway itself.
- A third-party ESP signs with its own domain, not yours. Marketing platforms and CRMs sometimes sign outgoing mail with their own DKIM key rather than yours. Fix: configure domain-level DKIM signing inside that platform so it signs as your domain.
To diagnose which one you’re facing, pull up the raw email headers on a failing message and look at Authentication-Results. It will show spf=, dkim=, and a header.d= value, telling you exactly which check failed and which domain was checked.
A message can show
spf=passand still fail DMARC entirely, because the SPF-passing domain doesn’t match the visible From address. That single line in the header is usually where a “DMARC troubleshooting Office 365” case gets solved.
Getting subdomain inheritance and parked domains right
A parent domain’s DMARC record automatically covers every subdomain unless that subdomain publishes its own separate record. This inheritance catches people out in both directions: enforcing at the parent without checking subdomain readiness, or assuming a subdomain is protected when it actually has its own conflicting record.
Before enforcing at the parent level:
- Confirm every subdomain that sends mail has its own working SPF and DKIM.
- Use the
sp=tag if you want subdomains to follow a different policy than the parent, useful when a marketing subdomain isn’t ready forp=rejectbut your main domain is. - Publish
v=DMARC1; p=rejecton any parked or unused domain immediately, with noruaneeded, since it never sends legitimate mail and only exists as a spoofing target. - Double check any subdomain used by an old project or acquired brand. It’s often forgotten and left wide open.
How do you verify each stage of DMARC office 365 setup?
Run these checks after every change, not just at the end:
- DNS check: confirm exactly one TXT record at
_dmarc.yourdomain.co.ukusingdig,host, or an online DMARC lookup tool. - Message check: send a test email through each major sender and inspect
Authentication-Resultsforspf=pass,dkim=pass, and a matchingheader.d=value. - Report check: confirm your
ruamailbox is receiving XML files and that a parser is reading them without errors. - Tool check: MXToolbox and the Defender portal both give a quick second opinion on SPF, DKIM, and DMARC status side by side.
Green across all four checks, with no unexplained sources in your reports, is your signal to move to the next enforcement stage.
What TTOY Digital’s rollout checklist looks like
When a digital agency works through a configure DMARC Office 365 project for a small business client, the sequence rarely changes: inventory every sender first, publish the DKIM CNAMEs and switch on signing, then publish DMARC at p=none before touching enforcement. Reports get reviewed weekly during the monitoring window, and policy only tightens once every sender has cleared it cleanly.
Businesses with limited DNS access, several ESPs, or a DNS host they’ve never logged into before benefit most from having someone else run the SPF, DKIM, and DMARC setup end to end, including managed report parsing so nobody has to learn XML.
The rollout mistake most guides skip over
Most DMARC guides treat p=none to p=reject as a technical checklist. It isn’t. It’s a communication problem disguised as a DNS problem.
The real risk isn’t misconfiguring a TXT record, most admins get the syntax right eventually. It’s enforcing policy while a department still runs a marketing tool or invoicing system nobody told IT about. That’s not a DNS failure, it’s an inventory failure, and no amount of report parsing fixes a sender you never knew existed.
Prioritise the sender audit over the DNS syntax. Spend more time asking colleagues what they use to send mail than tweaking tag values. The staging period exists precisely to surface these blind spots, so resist rushing through p=none in a week. Four to eight weeks feels slow when you’re keen to lock things down, but it’s the only way to catch a quarterly sender before enforcement blocks their mail permanently.
— Chris
Get help rolling out DMARC without the DNS guesswork
Some digital agencies handle parts of a Microsoft 365 authentication rollout that trip up most small businesses: DNS changes on domains that are rarely logged into, DKIM CNAME publishing, tenant signing, and reading aggregate reports so nobody’s stuck decoding XML files at 11pm. If your DNS access sits with a third-party host, if you’ve got several marketing or invoicing tools sending under your domain, or if you simply need this done properly rather than pieced together from forum threads, that’s exactly where a managed hand pays off. Some digital agencies offer Microsoft 365 services covering this kind of setup and ongoing support. For businesses juggling several sender integrations alongside their DMARC rollout, SmartFlowCRM also brings email, WhatsApp, and lead sources into one place, so you know precisely what’s sending on your domain in the first place. Get in touch and we’ll map your senders before touching a single DNS record.
Sources
- Set up DMARC to validate email in Microsoft 365 - Microsoft Defender for Office 365 | Microsoft Learn
- Setting Up DMARC on Microsoft 365 (2026 Guide) | mxio
FAQ
How do I set up DMARC correctly for Office 365?
Verify SPF includes spf.protection.outlook.com and DKIM is signing correctly, then publish a _dmarc TXT record at p=none with an rua address, monitor reports for several weeks, and advance to quarantine then reject only once every sender passes cleanly.
Do I need to set up DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM alone don’t stop spoofing of your visible From address; DMARC ties the two together with alignment rules and tells receiving servers what to do with mail that fails, which SPF and DKIM cannot do on their own.
What is a DMARC setup, exactly?
A DMARC setup is a DNS TXT record published at _dmarc.yourdomain.co.uk that defines a policy for handling mail that fails SPF and DKIM alignment checks, alongside an address for receiving aggregate reports on how your domain’s mail is authenticating.
What should my DMARC policy be set to when I start?
Start at p=none. This monitors and reports on every message without affecting delivery, giving you the visibility to fix any failing senders before you risk quarantining or rejecting legitimate mail.
