Organizations using Microsoft 365 (Office 365) for email get a lot of built-in protection, but stopping domain impersonation still requires publishing a DMARC record in your domain's DNS. It's a short setup that pays off by blocking phishing attempts that try to spoof your company's name and by keeping your legitimate mail landing in inboxes rather than spam.
What a DMARC policy actually controls
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving mail servers what to do with messages claiming to be from your domain that fail your SPF or DKIM checks. A DMARC policy has a few key parts:
- Policy (p=): what happens to failing mail — deliver it anyway, send it to spam, or block it entirely.
- Subdomain policy (sp=): an optional separate rule for subdomains, if you want them handled differently from your main domain.
- Alignment mode: how strictly the SPF/DKIM domain must match the visible "From" address — relaxed (matching the root domain) or strict (exact match).
- Reporting address (rua=): where daily summary reports get sent so you can see who's sending mail as your domain.
Before you start
Make sure the basics are already in place:
- SPF is configured, listing the servers allowed to send mail for your domain (Microsoft 365's servers plus any other tools you use, like a CRM or invoicing platform).
- DKIM signing is enabled for your Microsoft 365 domain.
- You have access to your domain's DNS zone — your Avalon hosting control panel, if Avalon manages your domain.
Step-by-step setup
- Log in to your DNS management panel where your domain's records are hosted.
- Create a new TXT record with the host name
_dmarc, which becomes_dmarc.yourdomain.com. - Choose your policy value. Start conservatively with monitor-only mode:
v=DMARC1; p=none; rua=mailto:[email protected] - Save and publish the record. Once live, mail servers receiving messages from your domain will start applying this policy and sending you reports.
- Review your reports after a couple of weeks to confirm every legitimate sending source — including Microsoft 365 itself and any other business tools — is passing authentication.
- Move to a stricter policy gradually, shifting from monitor-only to quarantine, and eventually to reject, once you're confident nothing legitimate will be affected.
Growing into a stronger setup
Once your basic policy is stable, you can tighten alignment settings or shorten how often reports are sent, so you catch problems faster. Larger organizations sometimes bring in a dedicated reporting or monitoring service to make sense of DMARC data at scale, but a small business can manage perfectly well by reviewing reports directly.
Troubleshooting common problems
- Record has no effect: check for a syntax error, such as a missing semicolon or malformed policy tag, using a DMARC validation tool.
- SPF and DKIM misalignment: if the domain in your SPF or DKIM records doesn't match your "From" address domain, DMARC will fail even when SPF and DKIM individually pass. Make sure they're consistent.
- Reject policy applied too early: jumping to a blocking policy before all legitimate senders are verified is the most common cause of lost email. Start in monitor mode and give yourself time.
FAQ
Do I need DMARC if I already use Microsoft 365's built-in spam filtering? Yes — built-in spam filtering protects mail arriving in your inbox, while DMARC protects your domain's reputation by controlling how other servers treat mail that claims to come from you.
What happens if I never enforce a stricter policy? Staying at monitor-only still gives you valuable visibility, but it won't actually block spoofed mail from reaching recipients — quarantine or reject is needed for real protection.
