Email security with Microsoft 365, part 1: setting up SPF, DKIM and DMARC correctly

SPF, DKIM and DMARC are considered standard equipment for any domain. Yet we keep finding the same gaps in Microsoft 365 environments: duplicate SPF records, DKIM never switched on, DMARC left in monitoring mode. This article explains the mechanisms, the consequences of gaps and the setup in Exchange Online. Part 2 then covers protection of inbound mail with Microsoft Defender for Office 365.

What happens if SPF, DKIM and DMARC are missing?

Without these three records, anyone can send email that shows your domain in the From field. For management, this means:

• Fraud in your name: criminals write to your customers, suppliers or your bank using your sender address, for example with a “corrected” bank account on an invoice.
• Your genuine mail lands in spam: partners whose systems check senders strictly filter out your quotes and invoices because your domain cannot identify itself.
• Loss of reputation: if your domain is abused for spam, its standing with the large mail providers suffers. That affects your legitimate mail too.
• Questions from insurers and auditors: SPF, DKIM and DMARC are among the points cyber insurers and auditors ask about. A gap has to be explained.

Your decision: who is responsible internally, and who reviews the reports regularly?

What does SPF do and how do I set it up for Exchange Online?

SPF (Sender Policy Framework) is a public list of the servers allowed to send mail for your domain. Think of telling the postal service which mailboxes may be used for your letters; a letter from any other mailbox stands out.

If SPF is missing or wrong: receiving systems cannot check whether a message came from an authorised server. A faulty record is often worse than none, because it can cause your own mail to be rejected.

Implementation: SPF is a TXT record in your domain’s DNS, managed at your registrar or DNS provider, not in the Microsoft 365 portal. If Exchange Online is the only sender, it reads:

v=spf1 include:spf.protection.outlook.com -all

Use -all (hard fail), because otherwise DMARC can hardly act on messages without a DKIM signature. Two limits matter: there may be only one SPF record per domain, and the check may trigger no more than 10 DNS lookups. Every include: counts at least once, and nested includes count on top. If the limit is exceeded, SPF fails with a permanent error.

What does DKIM do and why do I have to switch it on myself in Microsoft 365?

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing message. Think of a seal on the envelope. The recipient uses a publicly published key to check that the seal is genuine and the content was not altered in transit.

If DKIM is missing: without your own seal, nobody can prove that a message really came from you and arrived unchanged. DMARC also loses one of its two checks.

Implementation: Microsoft 365 does not automatically sign mail for your custom domains. Setup happens in the Microsoft Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings (direct link: security.microsoft.com/authentication), on the DKIM tab:

1. Select the domain and enable DKIM. The portal displays the two required CNAME values.
2. Create two CNAME records at your DNS provider: selector1._domainkey and selector2._domainkey, each pointing to the value shown.
3. Once Microsoft has detected the records, switch DKIM signing on and check the status.

What does DMARC do and how do I get safely to p=reject?

DMARC (Domain-based Message Authentication, Reporting and Conformance) links SPF and DKIM to an instruction for the recipient: what should happen to messages that fail the check? DMARC verifies that the visible sender domain aligns with SPF or DKIM. In the letter analogy: you tell the postal service what to do with letters lacking a valid seal, and ask for regular reports.

If DMARC is missing or set to p=none: recipients decide for themselves. Forged messages may be detected but still delivered. This is exactly where invoice fraud with “corrected” bank details happens.

Implementation: DMARC is a TXT record at _dmarc.yourdomain.com. Introduce it gradually:

1. Start in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The aggregate reports (rua) show which systems send mail in your name.
2. After analysis, raise the policy to p=quarantine. The pct= tag lets you increase the share gradually.
3. Then move to p=reject. Only now do recipients refuse forged messages.

Start with low-volume subdomains and switch the main domain last. Send reports to a dedicated mailbox or Microsoft 365 group, not a personal mailbox, and name the people who review them.

Why is staying at p=none the most common mistake?

p=none is a measurement mode and protects nothing. Environments often stay there out of concern that legitimate mail might be lost. That concern is justified only as long as nobody reviews the reports. Once every legitimate sender is known and correctly configured, it disappears, which is why a project with a fixed end date for p=reject beats an open-ended monitoring phase.

Which SPF, DKIM and DMARC errors do we see most often?

• Two SPF records for the same domain: this causes the check to fail. All senders belong in one record.
• Forgotten third-party senders: newsletter tools, ERP or ticketing systems send in the domain’s name without being in the SPF record or signing with your domain. Dedicated subdomains for such services solve this.
• DKIM never switched on: the CNAME records were created but signing was never enabled in the portal, or the other way round.
• Subdomains overlooked: the main domain’s DMARC policy also covers subdomains, but SPF and DKIM do not. Every sending subdomain needs its own SPF and DKIM records.
• Nobody reads the reports: without analysis, DMARC remains a formality.
• Unused domains left open: parked domains need v=spf1 -all and v=DMARC1; p=reject; so they cannot be used for fraud.

What comes after SPF, DKIM and DMARC?

The next step concerns the transport path. MTA-STS tells sending servers to deliver mail to your domain only over an encrypted connection and only to a server with a valid certificate. It needs a DNS record and a policy file that you host yourself over HTTPS. TLS-RPT adds reports on failed encrypted deliveries. Both are worth doing once DMARC is at p=reject.

The next step

You are accountable for making sure nobody defrauds your customers in your name. We provide the evidence that your domain is properly protected. In our Gap Assessment we review SPF, DKIM, DMARC and the other Exchange Online settings and deliver a prioritised list of measures. Ongoing review of DMARC reports can be part of our Managed Security service.

Book an introductory call

Frequently Asked Questions

How long does it take to move DMARC from p=none to p=reject?

That depends on how many systems send mail in your name. The DNS records take minutes; the time goes into analysing reports and adjusting third-party senders. Plan the change as a project with a fixed end date and proceed domain by domain.

Doesn’t Microsoft 365 sign my mail with DKIM automatically?

Only messages from senders in your tenant’s onmicrosoft.com domain are signed automatically. For your own domain you must enable DKIM in the Microsoft Defender portal and create two CNAME records at your DNS provider. Only then does the signature match your sender domain and count for DMARC.

Do we also need to protect domains we never send email from?

Yes. Otherwise unused domains can be abused for forged mail. An SPF record of v=spf1 -all and a DMARC record with p=reject signal that no legitimate mail comes from that domain. Do not publish DKIM records for such domains.