For Microsoft 365 or hosted business email, use the provider’s current tenant-specific DNS instructions. Publish one SPF policy that covers legitimate senders, enable DKIM with the exact selectors or records generated for your domain, then configure DMARC and verify alignment. Microsoft’s custom-domain DKIM targets can be tenant-specific, so do not copy example CNAME values. Hosting providers may use a different DKIM record format.

Email authentication is not one universal DNS recipe.

Microsoft 365, cPanel mail, Zoho and other hosts can all use SPF, DKIM and DMARC, but the exact records and setup screens differ.

Use the provider’s current values for your domain.

Inventory every system that sends mail

Before editing DNS, list:

  • Microsoft 365 or hosted mailboxes;
  • contact-form service;
  • CRM;
  • invoice or accounting system;
  • newsletter provider;
  • ticketing system;
  • ecommerce platform;
  • scanner, server or application that sends automated mail.

A business can move its staff mailboxes to Microsoft 365 while a website still sends through the old cPanel server.

If you delete the old sender from SPF before changing the website, notifications may start failing authentication.

SPF should describe the real senders

SPF publishes which sources may send for the envelope domain.

Microsoft provides the SPF configuration for domains using Microsoft 365. A hosted email provider will publish its own include domain or IP requirements.

Use one valid SPF record for the hostname.

Do not stack separate SPF TXT records such as:

v=spf1 include:provider-one.example ~all
v=spf1 include:provider-two.example ~all

Combine legitimate sources according to the providers’ instructions.

Also watch the SPF DNS-lookup limit when many third-party includes accumulate.

SPF alone does not protect the visible From address

Microsoft’s documentation emphasises that SPF checks the MAIL FROM domain. It does not by itself prove alignment with the address the recipient sees.

That is why DKIM and DMARC matter.

Do not stop after an SPF checker returns green.

Microsoft 365 custom-domain DKIM needs your exact values

Microsoft 365 uses DKIM signing for custom domains, but the CNAME targets are generated from the tenant and domain configuration.

Microsoft’s current guidance explicitly tells administrators to retrieve the required selector values from the Defender portal or Exchange Online PowerShell.

The examples in documentation are examples.

Do not copy another tenant’s target such as:

selector1-contoso-com._domainkey.contoso...

Your tenant can have different values, including the newer dynamic DKIM target format Microsoft introduced for new custom domains.

Publish both Microsoft selectors

Microsoft 365 uses two DKIM selector CNAME records so it can rotate signing keys.

Retrieve both values and publish them exactly at your DNS provider.

Typical hostnames are based on:

selector1._domainkey
selector2._domainkey

The target values must come from your own Microsoft configuration.

After DNS resolves, enable DKIM signing in Microsoft 365 and confirm the status is valid.

Hosted email may use TXT instead of Microsoft’s CNAME pattern

A cPanel or other hosting provider can publish DKIM differently.

For example, the provider may give you a TXT record containing the public key rather than Microsoft’s selector CNAME targets.

Follow the system that actually signs the mail.

Do not convert a provider’s TXT instruction into a CNAME because a Microsoft tutorial used CNAMEs.

Record type is part of the configuration.

DMARC checks alignment

DMARC evaluates the visible From domain against authenticated SPF and/or DKIM domains.

Before applying a strict DMARC policy, verify every legitimate sender.

A sensible rollout can include:

  1. Publish authentication for known senders.
  2. Start DMARC reporting/monitoring.
  3. Review failures.
  4. Correct alignment for legitimate platforms.
  5. Move to stronger enforcement when the business understands the impact.

Do not publish p=reject on Friday afternoon without knowing what your CRM and invoice platform are doing.

Use a separate subdomain for some third-party mail

Microsoft recommends considering a subdomain for external bulk or third-party senders when you do not want that service’s mail behaviour to affect the main staff-mail domain.

Example:

updates.example.co.za

Configure that subdomain intentionally with the sender’s SPF/DKIM and appropriate DMARC policy.

Do not let a marketing platform choose a random From domain that customers cannot recognise.

Verify real message headers

Send tests from each system to an external mailbox.

Record:

  • visible From;
  • Return-Path / MAIL FROM;
  • SPF result;
  • DKIM result;
  • DKIM d= domain;
  • DMARC result;
  • Reply-To;
  • sending IP or provider where useful.

A DNS lookup tool confirms that a record exists. A real message confirms that the application is using it.

Check forwarding and message modification

Forwarding can break SPF because the forwarding server becomes the new sending source. Security gateways, disclaimers and mailing lists can also modify messages after DKIM signing.

Microsoft documents ARC and enhanced filtering for more complex routing scenarios.

If authentication passes for direct mail but fails after a gateway or forwarding service, map the route before changing the original DNS.

Keep website mail separate from mailbox hosting assumptions

A website hosted at Namecheap, Cloudflare or another provider does not have to send mail from the same infrastructure that hosts the domain’s DNS or website.

Document:

  • web host;
  • DNS provider;
  • mailbox provider;
  • form provider;
  • transactional mail provider.

This prevents someone from changing MX or SPF because they assumed “the website host controls email”.

Build a provider handover sheet

Include:

Item Current configuration
Domain registrar
DNS provider
Mail provider
MX records
SPF authorised senders
DKIM selector/record locations
DMARC record
DMARC report destination
Form sender
CRM sender
Invoice sender
Last message-header test

Do not store credentials in the sheet.

The handover should make the system understandable without exposing admin passwords.

Recheck after adding software

Every new system that sends as your business domain can change the authentication picture.

Review SPF, DKIM and DMARC when adding:

  • CRM;
  • marketing platform;
  • accounting tool;
  • ticket system;
  • website form;
  • ecommerce platform;
  • new subdomain;
  • new mail provider.

Retire old authorisations when the service is gone.

IDJoy can help document and test business-domain email setup through the professional email and website service options, with provider-specific records rather than generic DNS examples.