Microsoft 365 Email Authentication: SPF, DKIM and DMARC for Indian Businesses

A customer receives a convincing payment reminder carrying your company name. At almost the same time, a genuine quotation from your sales application lands in junk. These look like separate problems, but both should prompt a review of how your business authorises and authenticates outgoing email. For Indian businesses using Microsoft 365, that review must include the website, accounts software, CRM, support platform and marketing service alongside employee mailboxes.

This Microsoft 365 email authentication guide explains SPF, DKIM and DMARC through a practical implementation project. It focuses on reducing misuse of your domain while preserving legitimate business messages. The rollout examples and checklists are suggested operating practices, not guaranteed security outcomes. Microsoft’s official documentation was checked on 8 September 2026; use the current instructions and your own tenant values when making changes.

Define the business problem before editing DNS

Start by identifying which communications would cause the greatest disruption if they failed or were impersonated. A distributor may depend on dispatch notices and payment reminders. A consultancy may rely on proposals and project invitations. A manufacturer may send purchase orders through an application that the IT team rarely sees. These messages deserve explicit owners and tests.

Agree on two outcomes: authorised sending systems must authenticate correctly, and the business must establish an appropriate policy for messages that impersonate its domain. Keep these outcomes separate from broader promises about eliminating phishing or guaranteeing inbox placement. A project with measurable acceptance criteria is easier to commission, review and maintain than a request to simply make email secure.

SPF, DKIM and DMARC: a useful comparison

Microsoft explains how the three mechanisms work together in its email authentication overview. SPF checks whether a sending source is authorised for the envelope sender domain. DKIM checks a cryptographic signature associated with a signing domain. DMARC connects authentication to the domain users see in the From address and adds policy and reporting.

MechanismQuestion it helps answerBusiness review point

SPF

Is this source authorised for the envelope domain?

Maintain an accurate sending inventory.

DKIM

Does the domain signature validate?

Test actual messages from each service.

DMARC

Does authentication align with the visible domain?

Review evidence before strengthening policy.

A DMARC pass requires an aligned SPF pass or an aligned DKIM pass; it does not require both to pass simultaneously. Alignment is therefore a separate question from whether a sending platform displays a green authentication indicator. Ask the implementer to demonstrate alignment for your visible sending domain, rather than accepting a screenshot that only says a vendor’s own domain passed.

Build a complete register of sending services

Create one row for every system that sends business email. Record its business purpose, owner, supplier, visible From domain, sending route, administrative contact and test method. Include low-volume services. A monthly invoice process can matter more commercially than thousands of routine notifications, even though it is less visible in an ordinary working-day sample.

Interview finance, sales, HR, marketing and support separately. Ask each department to show a recent message generated by its applications. Also review website forms, scheduled reports, monitoring alerts, multifunction printers and older applications. Do not assume that everything uses Microsoft 365 simply because staff read their email in Outlook.

Identify exceptions before they become outages

For every unclear entry, assign an investigation owner and a deadline. Record whether the service is active, seasonal, being replaced or no longer required. An unknown sender should not receive permanent authorisation merely to clear a dashboard warning. Equally, an unfamiliar address should not be removed without checking whether it supports a legitimate business process.

Use a short evidence pack for each service: a sample message, relevant vendor instructions, business approval and the planned test recipient. Keep customer information out of unnecessary screenshots. A concise register shared between business and technical owners prevents repeated discovery work whenever a supplier changes or an employee leaves.

Establish ownership of the domain and DNS

Confirm who controls the domain registration and authoritative DNS hosting. These may be different suppliers, and neither is necessarily the company that hosts your website. Identify a named administrator, a backup administrator and the approved access method. Test access before scheduling the change window; discovering a missing login during implementation creates avoidable pressure.

Export or record the existing DNS configuration and note when it was captured. Write down the exact records being changed, the reason, the reviewer and the rollback values. Keep unrelated website or routing changes outside the same change request where practical. That makes it easier to isolate the cause if a test behaves unexpectedly.

Choose a window when the technical owner and business testers are available. Consider dispatch cut-offs, payment runs and campaign schedules. The right time is determined by the business processes affected, not simply by when the administrator has a free evening. Ensure support arrangements cover the observation period after the change.

Configure SPF from the verified inventory

SPF is published as a DNS TXT record. Microsoft requires one SPF record per sending domain or subdomain; multiple SPF records can cause a permanent error. The standard permits a limited lookup budget, and nested includes count towards it. Refer to Microsoft’s current SPF configuration guide when constructing the record.

For the documented Microsoft 365-only scenario, Microsoft gives v=spf1 include:spf.protection.outlook.com -all. Treat this as a scenario-specific example. Replacing an existing record with it without reviewing other senders could exclude legitimate application mail. Combine approved requirements into the appropriate record after reviewing each service’s official instructions.

Make every authorisation explainable

Maintain a note beside each approved source identifying its owner and purpose. Ask whether the sender is still needed and whether its documented configuration has changed. Do not add broad ranges or copied entries simply because another company uses them. A record should reflect your actual mail routes and approved vendors.

After editing, check public DNS resolution and send representative messages. Preserve the result in the change record. If a vendor later asks for another authorisation, repeat the review instead of treating the request as routine copying. This habit keeps the configuration understandable as applications accumulate over several years.

Enable DKIM with values from your tenant

Microsoft’s DKIM configuration documentation instructs administrators to obtain the required CNAME values from the Defender portal or Exchange Online PowerShell. Do not calculate them from an old tutorial. Microsoft uses two selectors for custom-domain signing, with the second supporting key rotation. Publish the required records and complete the enablement procedure.

Publishing DNS records and enabling signing are separate checks. Send an external test and inspect the received message to verify the signing domain and result. Repeat the process for each relevant custom sending domain. A successful test for the main company domain does not establish that another domain or application is correctly configured.

For third-party senders, use the supplier’s current domain authentication procedure. Record who completed it and who will maintain it. If a supplier claims that DKIM is already enabled, request evidence from a message using your business From address. The objective is a verified configuration for your use case.

Introduce DMARC through controlled policy stages

Microsoft describes DMARC policies of p=none, p=quarantine and p=reject, and recommends a staged rollout. Monitoring allows investigation before stronger handling is requested. Quarantine and reject express the domain owner’s requested treatment of failures; receiving systems make their own handling decisions. Follow the official DMARC setup guide for syntax, reporting and alignment options.

Use an evidence gate, not an arbitrary date

Define what must be true before moving to the next policy stage. For example, every critical sending service should have an owner, a passing representative test and an explanation for known exceptions. The observation period should include the organisation’s relevant business cycle. A few quiet days may omit a monthly statement run or scheduled customer campaign.

Have the business owner approve progression based on this evidence. Record unresolved risks and the person responsible for each. If important messages still fail, investigate their sending route and alignment before increasing enforcement. If they pass, retain the results so a future review can distinguish an old design issue from a new change.

Give reporting a person and a purpose

Decide who receives and reviews DMARC reporting, how findings become support work and how unresolved items are escalated. If a reporting service is proposed, evaluate its access model, data handling, retention and commercial terms. Do not assume that collecting reports automatically produces an accurate or complete picture of all business mail.

For each unusual source, ask whether it belongs to a known service, whether the business authorised that service and whether its messages authenticate as intended. Group findings into legitimate configuration issues, confirmed unwanted sources and items needing investigation. Keep the evidence and reasoning attached to the case so another administrator can understand the decision.

Agree on a review rhythm that the team can sustain. A small organisation might choose a short scheduled review with a clear escalation route for urgent delivery issues. Avoid buying a dashboard with no operating owner. The value comes from correcting and validating the mail flow, not from accumulating unread reports.

Test business journeys, not just employee mail

Build a test matrix covering ordinary employee messages, customer quotations, invoices, website acknowledgements, support replies and approved marketing messages. Use designated external recipients with permission to receive tests. Make subjects and attachments clearly identifiable as test material, and prevent automated tests from generating real orders or payment actions.

For each test, capture the sending application, time, sender domain, recipient, delivery result and authentication evidence. Ask the business tester whether the message content and reply workflow are usable. A technical pass is valuable, but a customer replying to an unmonitored address can still expose an operational defect in the service.

Investigate forwarding and message modification

Forwarding and intermediate message changes can affect authentication results. Microsoft discusses these paths and related authentication mechanisms in its authentication overview. Where the organisation depends on a gateway, forwarding arrangement or signature service, test the actual route rather than extrapolating from a direct message.

When a test fails, preserve the original received headers or delivery report through the approved support process. Record which path was used and which earlier test passed. Avoid broad allowlisting as an automatic response. Ask the implementer to identify the failing mechanism and propose a narrowly scoped correction with a repeatable verification step.

A practical example for an Indian distributor

Consider a hypothetical distributor with employee mail in Microsoft 365, quotations in a CRM, statements in an accounts application and campaigns sent by an agency. The owner initially assumes that one Microsoft configuration covers all outgoing messages. Discovery instead identifies four separately managed sending paths, each with a different person able to change it.

The team registers all four services and appoints finance to validate statements, sales to validate quotations and marketing to validate campaigns. The administrator documents the DNS baseline and obtains current configuration requirements. One application’s visible domain differs from its authenticated domain, so that service is corrected and retested before the DMARC policy is strengthened.

The rollout includes the next statement cycle rather than ending after employee email passes. At handover, the business receives the inventory, tests and escalation contacts. This example illustrates a decision process, not a product compatibility claim or customer case study. Its central lesson is that business ownership reveals dependencies that a mailbox-only review can miss.

Separate domain protection from payment controls

Email authentication does not establish that a payment request is commercially valid. An attacker using a compromised legitimate account can still exploit trust, and a different lookalike domain creates a separate problem. Treat SPF, DKIM and DMARC as part of a wider security design rather than a replacement for careful handling of sensitive instructions.

For payment-detail changes, define an independent verification procedure using previously established contacts. Train staff to escalate unusual urgency or changes in approval behaviour. Review access protection and incident response alongside domain authentication. These are complementary business controls; none should be advertised as a promise that fraud becomes impossible.

Specify the deliverables in your quotation

Ask suppliers to price a defined scope: domains, sending services, discovery work, DNS changes, testing, observation and handover. Identify who purchases any reporting subscription and who owns that account. Separate implementation charges from recurring monitoring and support so the renewal decision is clear.

Request explicit exclusions. Examples to clarify include unsupported legacy applications, supplier-side changes, after-hours support and remediation of unrelated deliverability problems. Ask what happens when a new sender is discovered during the project. A transparent change process is more useful than a low headline figure based on incomplete assumptions.

Do not infer a required Microsoft licence upgrade from the presence of a security project. Ask the supplier to identify the exact feature and current entitlement whenever additional licensing is proposed. The DNS work, third-party tools and broader security services should each have a documented reason in the quotation.

Keep a rollback plan that people can execute

Before implementation, agree on the symptoms that trigger escalation and the person authorised to decide the next step. Preserve the earlier record values and explain which change they reverse. A rollback must be specific enough that an alternate administrator can follow it without reconstructing a conversation from memory.

If genuine mail is disrupted, collect evidence and identify the affected service first. Consider a targeted correction where feasible. Any temporary policy relaxation should have a reason, an owner and a review date. Avoid leaving an emergency workaround in place indefinitely because normal mail appears to have resumed.

Maintain the configuration after handover

Add email authentication review to onboarding for every new application that sends as the business. Require the requester to name a business owner and provide current vendor documentation. Test before ordinary customer use begins. This makes authentication part of purchasing and deployment rather than a cleanup exercise after delivery complaints arrive.

When retiring a service, confirm that business sending has ended before removing its authorisation or signing records. Coordinate with any replacement supplier and retain the change evidence. Review the domain register during renewals, acquisitions and agency changes, when responsibility can shift without an obvious technical event.

Make the support handover useful on a busy day

Write a short troubleshooting intake form for the people who receive delivery complaints. Ask for the sending application, approximate time, intended recipient, visible sender and any delivery notification. Give staff a secure route for sharing the original message with authorised support. Avoid asking them to forward customer attachments to several unrelated suppliers simply to obtain an initial diagnosis.

Separate one recipient's complaint from a widespread service failure. The support owner should establish which journeys are affected before announcing an outage or changing policy. Compare the failed example with a recent successful test from the same application. This helps the team ask a precise question of the correct supplier and reduces repeated requests for information.

Record the business impact in ordinary language: quotations delayed, statements not received or support replies missing. Technical evidence explains the mechanism, while business impact determines the urgency and who needs an update. Assign one coordinator when several suppliers are involved, so the customer-facing team receives a coherent account of progress.

Run a handover exercise

Before closing the project, give an alternate administrator a fictional delivery complaint and ask them to use the operating pack. They should be able to identify the sending service, find its owner, locate the last successful test and explain the escalation route. Do not make live changes during this exercise; its purpose is to expose gaps in instructions and ownership.

Ask a department representative to repeat the exercise from the business side. Can finance identify the supplier responsible for statements? Can marketing describe how a new campaign platform receives approval? Their answers show whether the work has become part of normal operations or remains knowledge held by a single technical specialist.

Measure progress without misleading security scores

Use a small scorecard with separate measures for inventory coverage, successful business tests, unresolved legitimate failures and overdue investigations. Explain the denominator for each measure. Ten tested services out of ten known services means something different from ten tests when nobody knows how many applications send mail.

Track critical services individually even when their message volume is low. A monthly statement service should remain visible beside employee mail. Record the last tested business cycle, the person who accepted the result and the next review trigger. This creates useful evidence for management without implying that a high aggregate pass rate proves every important workflow is safe.

Use trends to prompt questions rather than automatic policy changes. If failures rise after a new website launch, investigate the website's sending route and recent configuration changes. If an unexplained source disappears, document what was learned before closing the case. A clear explanation is more valuable than a temporarily cleaner chart.

Schedule the first ownership review before project closure. Confirm that the named people accept their responsibilities and know where the records are stored. A calendar entry with an accountable owner helps turn handover promises into a recurring operational habit.

Management acceptance checklist

• Every active sending domain and service has a named owner.
• DNS access, baseline records and rollback instructions are documented.
• SPF and DKIM are configured and tested for the relevant routes.
• DMARC progression is supported by evidence from critical business processes.
• Known exceptions have actions, owners and review dates.
• Reporting review and delivery-issue escalation have ongoing coverage.
• New suppliers and retired services enter a controlled change process.
• The handover pack is accessible to an authorised alternate administrator.

Conclusion: protect the domain without losing the workflow

A reliable Microsoft 365 email authentication project begins with understanding who sends for the business. It then turns SPF, DKIM and DMARC into verified controls supported by tests, ownership and maintenance. The strongest policy is useful only when the organisation understands its legitimate mail and can respond confidently to exceptions.

Contact India Enterprises to discuss an email authentication assessment and a scoped implementation quotation. Bring your domain list, Microsoft 365 details and the applications that send quotations, invoices or customer updates. Ask for a proposal covering discovery, configuration, business testing and ongoing responsibility, so the expected work and acceptance evidence are clear before implementation begins.