Module 4 of StartCloud's Microsoft 365 Security Essentials learning pathway, in six short units with a knowledge check: how email spoofing powers invoice fraud, what SPF, DKIM, and DMARC each do in plain English, and the exact steps to set all three up for Microsoft 365.
Stop Email Spoofing: SPF, DKIM, and DMARC in Plain English
The scam: email that looks exactly like you
Here is how the classic invoice scam plays out. Your bookkeeper gets an email from you, or so it appears. Same display name, same email address, even your usual sign-off. It says a supplier has changed banks and the attached invoice should be paid to the new account. The money goes out on Friday. By the time anyone rings the real supplier, it is sitting in an account that no longer exists.
The uncomfortable part is how easy the impersonation is. Email was designed in a friendlier era, and by default nothing stops a scammer typing your domain into the From field of a message. It costs them nothing and it works often enough that this style of attack, known as business email compromise (or BEC), is one of the most expensive crimes going. Microsoft lists spoofed senders as a key ingredient in BEC, ransomware, and phishing campaigns.
The fix is three small DNS records with awkward names: SPF, DKIM, and DMARC. Together they let the receiving mail server check whether a message claiming to be from your domain actually is, and tell it what to do when the answer is no. None of them cost anything. All three are things you set up once and mostly leave alone.
There is a selfish reason to do this too. The big mail providers increasingly treat email from domains without these records as suspect, so your own quotes and invoices are more likely to land in spam. Set the three records up and you protect your customers from fake you, and your real mail from the junk folder. Two birds, three DNS records.
SPF (Sender Policy Framework) is the guest list. It is a single TXT record in your domain's DNS that names every mail server allowed to send email on behalf of your domain. When a message arrives claiming to be from you, the receiving server checks the list. On the list, come on in. Not on the list, that is a mark against the message.
For a business that sends everything through Microsoft 365, the whole record is one short line:
v=spf1 include:spf.protection.outlook.com -all
- v=spf1 says this is an SPF record.
- include:spf.protection.outlook.com puts Microsoft 365's servers on the guest list.
- -all says nobody else is invited. The softer ~all means "treat strangers with suspicion", useful while you are still finding all your senders.
If other services send email as your domain (an accounting package firing off invoices, a newsletter tool, a website contact form), each one needs its own include: in that same record. A domain gets exactly one SPF record, so you extend the existing line rather than adding a second one. Two SPF records is a misconfiguration, and receivers will hold it against you.
SPF checks a hidden behind-the-scenes address, not the From address your reader actually sees, and it breaks when a message is legitimately forwarded. Microsoft is blunt about it: SPF on its own cannot stop every spoofing trick. That is why there are two more records to go.
DKIM (DomainKeys Identified Mail) is the tamper-proof seal. Every message leaving your domain gets a cryptographic signature stamped into its header, covering the important parts of the message: who it is from, the subject, and the body itself. The matching public key sits in your DNS, where any receiving server can look it up and check the seal.
If the seal checks out, the receiver knows two useful things. The message genuinely came from your domain, because only your mail system holds the private key that made the signature. And nothing important was changed along the way, because altering the signed content breaks the seal. A scammer cannot forge it, and unlike SPF, the seal survives forwarding, since it travels inside the message rather than depending on which server delivered it.
Already done. Microsoft 365 automatically DKIM-signs mail sent from your built-in yourbusiness.onmicrosoft.com domain. No action needed.
Not done until you do it. Custom domains like yourbusiness.com.au are not DKIM-signed out of the box. It takes two DNS records and a toggle in the Defender portal, covered step by step in unit 5.
A letter with an unbroken wax seal tells you who sent it and that nobody steamed it open on the way. A letter with no seal tells you nothing, however lovely the handwriting. DKIM is the wax seal, minus the candle burns on the good tablecloth.
SPF and DKIM run the checks, but on their own they never told receivers what to do about a failure. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the bouncer holding the instructions. It is one more TXT record in your DNS, and it does two jobs.
First, it insists the checks line up with the From address your reader actually sees. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the domain in the From line. That closes the loophole where a scammer passes the checks with their own domain while displaying yours.
Second, it publishes your policy: what receivers should do with a message that fails. You choose one of three, and you can ask for regular reports on who is sending as your domain, real or otherwise.
Watch and report
Delivery carries on exactly as before. Receivers simply send you reports on which messages passed and failed, so you can find every legitimate sender before anything gets blocked. This is where everyone should start.
- No mail is blocked or junked by your policy
- Reports show every source sending as your domain
- Safe to switch on today
- Monitoring mode, not protection yet
Send fakes to junk
Messages that fail the checks should be accepted but treated as suspect, which usually means the junk folder or quarantine. A sensible middle step once your reports look clean.
- Failing mail lands in junk, not the inbox
- Real senders you missed can still be rescued
- Can be phased in gradually with pct=
- Keep watching the reports
Turn fakes away at the door
Messages that fail the checks should be refused outright. The scammer's invoice never reaches your customer at all. This is the destination Microsoft recommends aiming for, once you are confident nothing legitimate is failing.
- Spoofed mail is rejected during delivery
- Strongest protection for your customers
- Only after quarantine has run cleanly
- The end goal for every domain
The three together: one message, three checks
A message arrives saying it is from yourbusiness.com.au
The receiving mail server starts checking.
SPF: the guest list
Did it come from a server this domain has authorised?
DKIM: the seal
Is the signature genuine, and is the message untouched?
DMARC: the bouncer
Do the passes line up with the From address, and if not, what does the domain owner want done?
Checks pass: delivered
Checks fail: your policy applies
Add a rua=mailto: address to your DMARC record and receivers send you regular aggregate reports: which messages claimed to be you, where they came from, and whether they passed. The raw reports are XML and about as fun to read as they sound, so most businesses point them at a DMARC reporting service that turns them into charts.
Time to do it for real, in the order Microsoft recommends: SPF, then DKIM, then DMARC. You will need two things: access to your domain's DNS records (usually at your registrar, wherever you bought the domain), and admin access to Microsoft 365. Each DNS change can take a little while to spread, so do not panic if a check does not pass instantly.
One habit worth keeping for all three steps: copy and paste the record values rather than typing them. One stray dot or dash and the record quietly does nothing.
- 1Sign in to your DNS host (usually your domain registrar) and open the DNS records for your domain.
- 2Look for an existing TXT record starting with v=spf1. Microsoft 365 setup usually created one when you added your domain.
- 3If there is none, add a TXT record on the host @ with the value: v=spf1 include:spf.protection.outlook.com -all
- 4If one exists, edit it so it includes include:spf.protection.outlook.com plus an include for any other service that sends as your domain. Never create a second SPF record.
- 5Save, and check your domain has exactly one SPF record.
Not sure of every service that sends as your domain yet? Use ~all instead of -all while you find them all, then tighten to -all once the list is complete. Also note: SPF covers one domain at a time, so any subdomain you send from needs its own record.
- 1Sign in to the Microsoft Defender portal at security.microsoft.com and go to Email & collaboration, Policies & rules, Threat policies, then Email authentication settings (or head straight to security.microsoft.com/authentication).
- 2On the DKIM tab, select your custom domain to open its details.
- 3Select Create DKIM keys. Microsoft shows you two CNAME records, one for selector1._domainkey and one for selector2._domainkey. Copy both.
- 4Back at your registrar, add both CNAME records exactly as shown. Enter only selector1._domainkey (and selector2._domainkey) as the hostname; most DNS providers add your domain on the end automatically.
- 5Wait for the records to be picked up, then return to the domain's details in the Defender portal and switch on Sign messages for this domain with DKIM signatures.
You need both selector records, even though only one is active at a time. The second is how Microsoft rotates your keys later. And they must be CNAME records, not TXT; that is the most common mistake Microsoft's own troubleshooting guide lists.
- 1Confirm SPF and DKIM are done first. DMARC leans on both, so it goes last.
- 2At your registrar, add a TXT record on the host _dmarc with a value like: v=DMARC1; p=none; rua=mailto:dmarc@yourbusiness.com.au
- 3Leave it on p=none for a few weeks and read the reports. Every legitimate sender that shows up as failing needs fixing (usually by adding it to SPF or setting up its DKIM) before you tighten anything.
- 4When the reports run clean, change the policy to p=quarantine. You can ease in with pct= to apply it to a percentage of mail at first.
- 5Once quarantine has run quietly for a while, finish the job with p=reject. That is the setting that actually turns fake invoices away at the door.
Microsoft's advice is to move gradually and let the reports guide you, starting with your quieter domains and saving the main one for last. Jumping straight to p=reject on day one is how a business discovers, mid-crisis, that its invoicing system was never in the SPF record.
- Microsoft Learn: Email authentication in Microsoft 365
- Microsoft Learn: Set up SPF to identify valid email sources for your domain
- Microsoft Learn: Set up DKIM to sign mail from your Microsoft 365 domain
- Microsoft Learn: Set up DMARC to validate the From address domain
- Microsoft Learn: External DNS records required for SPF in Microsoft 365
Record formats and portal steps were current at the time of writing (July 2026). Microsoft occasionally moves things around the Defender portal, so screens may vary slightly.
Knowledge check
5 quick questions. Get 4 right and the module is yours.
1. What does an SPF record actually do?
2. What does a valid DKIM signature prove about a message?
3. Your DMARC record says p=none. What happens to a message that fails the checks?
4. What is the recommended way to roll out DMARC?
5. How do you get DKIM signing working for your own domain in Microsoft 365?