Exchange Online deliverability / domain protection / Microsoft 365

SPF DKIM and DMARC review for Microsoft 365

A Microsoft 365 mail-authentication review checks every authorised sender, SPF, DKIM, DMARC and real mail flow before tightening a domain's policy.

Businesses often ask for a DMARC record to stop phishing. The meaningful work is larger: which platforms are allowed to send as the business domain, how Exchange Online signs its messages, whether third-party systems align with the visible From address, and how to interpret the reporting before enforcement. An apparently simple DNS edit can interrupt website enquiries, CRM invoices or payroll notifications when the sender inventory is incomplete.

A managed review should therefore begin with real traffic and current domain ownership. It should produce an authorised-sender register, a rollout design and independent delivery checks. No one should promise that a DNS record alone eliminates spoofing or guarantees that legitimate messages will arrive.

The operating principle

DMARC enforcement is the last step of an inventory and validation process

SPF and DKIM authenticate sending mechanisms; DMARC evaluates alignment with the visible sender domain and publishes a requested handling policy. Review legitimate senders before strengthening that policy.

01

Inventory every system that sends as the brand

Start with Exchange Online user mailboxes, shared mailboxes, CRM tools, billing platforms, marketing systems, website contact forms, helpdesk platforms, HR systems, printers and any delegated third-party vendor. Verify whether each uses the corporate domain, a subdomain, a different envelope sender or a vendor relay. A service account that was installed years ago may not be represented by an employee mailbox.

Ask the business owner of each system to send a harmless test to an external mailbox and record the authentication outcome. This identifies what is legitimate before anyone edits the record that governs the domain.

Sending sourceEvidence to captureRisk if omitted
Exchange OnlineDKIM signing and authentication for visible From domainNormal staff mail may not align
CRM or accounting SaaSEnvelope sender, DKIM and vendor instructionsInvoices or customer notices rejected
Website enquiry WorkerVerified sender subdomain and received testLost prospects with no visible website error
Bulk mail platformSeparately authorised domain/subdomainCampaign mail blocked by enforcement
Legacy SMTP applianceOwner, relay and retirement planUndetected operational dependency
02

Read SPF, DKIM and DMARC together

An SPF record should describe the actual permitted sending infrastructure, not every vendor that once supplied a tool. DKIM relies on correctly enabled signing for the relevant domain. DMARC examines alignment and gives receivers policy guidance. Microsoft documentation explains why all three controls need to be considered together and why enforcement without aligned legitimate traffic can cause delivery failures.

Check for duplicate or invalid DNS records, provider-specific authentication requirements and subdomains that send independently. Where multiple platforms use the same visible brand, design clear subdomain ownership and avoid unnecessary shared credentials. A report of pass or fail for one message does not describe all senders.

Documented administration controls

  • Source inventory approved by system owners
  • SPF syntax and sending mechanisms checked
  • DKIM selectors verified for Microsoft 365 and vendors
  • DMARC alignment inspected on representative traffic
  • Subdomain and bounce routing documented
03

Use a staged policy and evidence-led exceptions

Begin with observation and a written plan to remediate legitimate sending before enforcement. When the domain is ready, tighten policy according to the agreed risk tolerance and validation outcomes. Do not move directly to a rejecting policy merely because a dashboard reports a score; a forgotten finance sender or shared mailbox can cause costly disruption.

Any temporary exception should have a named owner and review date. Keep baseline DNS and sample message headers for recovery. Enforcement should be a controlled change with a stop condition for significant business impact.

04

Measure delivery after each approved change

Use Exchange message trace where applicable, external test accounts and direct confirmation from a real receiving mailbox. Confirm customer-facing mail flows such as invoice delivery, lead notification and password resets, not just administrator-to-administrator messages. If mail is missing, trace whether it was accepted, filtered, deferred or rejected rather than blaming DNS by default.

Provide the business with an authorised-sender register, current DNS state, exceptions, rollout decisions, validation results and instructions for adding a new vendor safely. Continue to review when integrations or domains change. Mail authentication is part of operating discipline, not a one-off badge.

Documented administration controls

  • Real external sending and receiving tests passed
  • Critical business application notifications verified
  • Message-trace or equivalent evidence retained
  • All policy exceptions assigned to an owner
  • Documented onboarding process for new email senders
The goal is not to install the strictest record. It is to protect the company's identity without breaking the legitimate messages customers and employees depend on.

Primary technical references

Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.

Commercial next step

Audit Microsoft 365 email authentication

Tell us the corporate domains, Microsoft 365 tenant count and known third-party senders. We can discuss a measured inventory and deliverability review.

Request an administration assessment