A company can send ordinary email successfully while its invoicing system, website and marketing platform use completely different delivery routes. That becomes important when the business tightens domain protection: a forgotten sender can turn a security improvement into missing quotations or payment reminders.
For a UAE business, the useful question is not simply “Do we have a DMARC record?” It is “Can we enforce our policy while all approved business messages still work?” This guide sets out a practical change plan, with technical references checked on 9 October 2026.
Understand the check before changing the policy
DMARC connects the visible From domain to a successful, aligned SPF or DKIM result. Passing SPF for an unrelated sending domain is insufficient. Microsoft's DMARC guidance recommends a gradual rollout: monitoring with p=none, then moving towards quarantine or rejection after legitimate sources are corrected. Monitoring is not enforcement. Receivers still apply their own filtering.
This is domain authentication, not proof that a payment instruction is genuine. Keep the independent checks described in the supplier bank-detail verification guide. An authorised but compromised account is a different problem from someone forging your domain.
Build a sender register with the business teams
Ask accounts, sales, HR, operations and marketing to name every system that sends messages using a company address. A hypothetical distributor might have Microsoft 365 staff mail, ERP invoices, a CRM quotation workflow and a website notification service. Checking Outlook alone would miss most of that process.
- Record the system, its business owner and its technical administrator.
- Capture the visible From address, sending provider and purpose.
- Note frequency: daily messages, monthly statements and occasional campaigns.
- Keep a sanitised example and record who can approve a test.
- Identify dormant systems and ask the owner whether to retire them.
The register should produce a named owner for every approved sender. Do not approve an unfamiliar source merely because it appears in a report. Investigate it with the relevant team or provider first.
ITZ's business cybersecurity service can help scope this review. Plan Your Email Authentication Review with your domain list and the systems that send business email; do not include passwords or private message content.
Fix sender configuration before enforcing rejection
For Microsoft 365, obtain the required DKIM DNS values from the tenant's administration tools rather than copying another company's example. Microsoft's DKIM setup documentation explains how custom-domain signing is configured and verified. Third-party senders need their own supported domain-authentication setup; enabling Microsoft 365 signing does not configure an unrelated marketing or invoicing platform.
Ask the administrator to test each approved route and record the receiving system's authentication results. Treat “the provider says it is configured” and “a representative delivered message passes the required checks” as separate milestones. Resolve discrepancies before changing the policy.
If email administration is part of a wider tenant change, coordinate it through Microsoft 365 setup and support. Avoid combining a mailbox migration, sender replacement and enforcement change in one undocumented cutover.
Use reports alongside real business tests
Aggregate DMARC reports show sending sources and authentication outcomes, but not every receiver reports. Assign someone to review them and investigate unexplained sources. Check subdomains too: parent policies can apply where a subdomain has no separate DMARC record.
Build a test list around business events, rather than an arbitrary number of quiet days. Include an invoice, quotation, password reset, form notification and campaign wherever those functions exist. Use approved test recipients and non-sensitive sample content. Record receipt, authentication results and any rejection notice.
For a monthly statement sender, either observe that cycle or arrange a controlled representative test with its owner. A low-volume reporting period is weak evidence that an occasional system is ready.
Agree the change and rollback criteria
- Keep an approved copy of the current DNS records and identify who can change them.
- Confirm that all known senders have a tested outcome and owner.
- Schedule the policy change with accounts and customer-facing teams.
- Define which failures pause the rollout and who makes that decision.
- Continue checking reports, delivery errors and the business workflows afterwards.
A rollback is a controlled response to a confirmed delivery problem, not a reason to abandon the protection permanently. Record which sender failed, restore the agreed configuration if necessary, fix that sender and repeat the affected tests. DNS changes also need time to propagate, so record when the change was made.
Plan your email authentication review
Bring ITZ the domains in use, your email provider, the sender register and any sanitised delivery errors. Request a scoped review of authentication, third-party senders, testing and the move to enforcement. The next step is an agreed change plan, not a promise that authentication alone will stop every malicious email.
