How to Set Up SPF, DKIM and DMARC for .com.au in Microsoft 365

SPF, DKIM and DMARC stop criminals sending email that looks like it came from your exact domain. This guide gives the exact records Microsoft 365 needs for a .com.au domain, how to enter them at your DNS host, and a staged rollout from p=none to p=reject with a check at every step.

What do SPF, DKIM and DMARC actually do?

All three are DNS records that let receiving mail servers decide whether an email claiming to be from your domain really is.

• SPF lists the servers allowed to send mail for your domain. It checks the hidden "envelope" sender, not the From address people see.
• DKIM adds a cryptographic signature to each outgoing message. The receiving server checks it against a public key published in your DNS.
• DMARC ties them together. It requires the domain that passed SPF or DKIM to match (align with) the From address, tells receivers what to do with mail that fails, and sends you reports.

ASD’s Australian Cyber Security Centre (ACSC) puts it bluntly: "Irrespective of where your organisation is in terms of implementing anti-spoofing controls, implement DMARC immediately, even if only in a monitoring mode (‘p=none’) configuration." It matters for invoice fraud too. Without enforcement, a scammer can send email that appears to come from your exact address to your customers. (Our call-back checklist for accounts teams covers the process side.)

Before you start

You need:

• Admin access to Microsoft 365, with permission to change email authentication settings in the Microsoft Defender portal, and ideally Exchange Online PowerShell.
• Access to wherever your domain’s DNS is hosted. For a .com.au domain this is often, but not always, the registrar you bought it from. It could also be your web host or a separate DNS service. Look up your domain at whois.auda.org.au and check the name servers listed: whoever runs those name servers is where you make the changes.
• A list of everything that sends email as your domain. This is the step people skip. Think beyond Microsoft 365: your accounting or invoicing system, CRM, newsletter platform, website contact form, booking system, payroll, multifunction printers and scanners, and any helpdesk tool. Each one needs to pass SPF or DKIM in a way that aligns with your domain, or DMARC enforcement will block it.

Throughout this guide, example.com.au stands for your domain and example for the first part of your initial example.onmicrosoft.com domain.

Step 1: Publish one SPF record

If Microsoft 365 is the only thing that sends mail as your domain, Microsoft’s recommended record is:

Type:  TXT
Host:  @ (the domain itself)
Value: v=spf1 include:spf.protection.outlook.com -all
TTL:   3600

Microsoft recommends -all (hard fail) rather than ~all (soft fail) for Microsoft 365 domains, because you’ll also have DKIM and DMARC. Its documentation notes that DMARC policy is effectively ignored for ~all failures on messages that also lack a DKIM signature.

If other services send as your domain, add their include: (or ip4:) values before -all, using the value each service documents. For example:

v=spf1 include:spf.protection.outlook.com include:mail.your-invoicing-service.example -all

Rules that matter:

• One SPF record per domain. Two TXT records starting v=spf1 make SPF return permerror. If you already have one, edit it; don’t add a second.
• No more than 10 DNS lookups. Each include:, a, mx, ptr, exists and redirect counts, including lookups nested inside included records. ip4:, ip6: and all don’t count. Go over 10 and SPF fails with permerror.
• Don’t "flatten" Microsoft’s include into IP addresses. Microsoft says its sending IPs change frequently.
• Each subdomain that sends mail needs its own SPF record. The record on example.com.au doesn’t cover news.example.com.au.

Check: look the record up from your own computer.

Resolve-DnsName -Name example.com.au -Type TXT

or on macOS and Linux:

dig +short TXT example.com.au

You should see exactly one string starting v=spf1.

Step 2: Enable DKIM in Microsoft 365

Microsoft 365 already signs mail with your onmicrosoft.com domain, but that signature doesn’t align with your .com.au From address, so it doesn’t help DMARC. You need DKIM signing with your own domain.

1. In the Defender portal at security.microsoft.com, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, or go straight to https://security.microsoft.com/authentication.
2. Select the DKIM tab, then select your domain.
3. In the flyout, select Create DKIM keys. (A "Client error" dialog may appear with the CNAME values in it. That’s expected; close it.)
4. Reopen the domain. The Publish CNAMEs section now shows the two records to create. Copy them exactly.
5. At your DNS host, create two CNAME records:

Type:  CNAME
Host:  selector1._domainkey
Value: (Selector1CNAME value from your tenant)

Type:  CNAME
Host:  selector2._domainkey
Value: (Selector2CNAME value from your tenant)

1. Wait for Microsoft to detect the records (Microsoft says a few minutes, possibly longer), then go back to the domain flyout and turn on Sign messages for this domain with DKIM signatures.

What the CNAME values look like

Microsoft introduced a new format for new custom domains in May 2025:

selector1-example-com-au._domainkey.example.<partition>-v1.dkim.mail.microsoft
selector2-example-com-au._domainkey.example.<partition>-v1.dkim.mail.microsoft

The dots in your domain become dashes (example.com.au becomes example-com-au), and <partition> is a single character (for example r or n) that Microsoft assigns and you can’t choose. Domains added before the change keep the older format:

selector1-example-com-au._domainkey.example.onmicrosoft.com

The two formats can’t be mixed for the same selector, which is why you should never copy values from a guide (including this one). Get your exact values from the portal, or in Exchange Online PowerShell:

Get-DkimSigningConfig -Identity example.com.au | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Key size

Keys created with New-DkimSigningConfig default to 1024-bit unless you pass -KeySize 2048. Once DKIM is working, you can move to a 2048-bit key with:

Rotate-DkimSigningConfig -Identity example.com.au -KeySize 2048

Microsoft notes a rotation takes four days (96 hours) to take effect, and the old key keeps signing until then.

Check: send an email from your domain to an external mailbox you control (a personal webmail account is fine), open the message headers and find:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com.au; s=selector1; ...
Authentication-Results: ... dkim=pass header.d=example.com.au ...

d= must be your domain, not onmicrosoft.com. The Defender portal should also show the domain’s status as Valid with the toggle Enabled.

Step 3: Publish a DMARC record in monitoring mode

Start with p=none so nothing is blocked while you find every sender:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]
TTL:   3600

• p=none asks receivers to take no DMARC action. You’re collecting data.
• rua= is where aggregate reports go. Microsoft recommends a dedicated shared mailbox or Microsoft 365 Group, not a person’s inbox, because the volume adds up.
• Leave out ruf= (forensic reports) to start. Microsoft suggests rua only at first; forensic reports can be high-volume and many receivers, including Microsoft 365, don’t send them.
• If the report address is on a different domain (for example, a reporting service), that domain must publish an authorisation record (example.com.au._report._dmarc.otherdomain with v=DMARC1;), or receivers won’t send reports there.
• Your DMARC record covers subdomains that don’t have their own DMARC record, including subdomains that don’t exist. That’s useful: it stops scammers inventing invoices.example.com.au.

The tool below builds SPF, DKIM and DMARC records and explains an SPF or DMARC record you paste in. It runs entirely in your browser and doesn’t look anything up in DNS, so use it to draft and sanity-check a record, then confirm what’s live with the dig check.

Check:

dig +short TXT _dmarc.example.com.au

You should see one record starting v=DMARC1. Then send another test email and look for dmarc=pass in the Authentication-Results header.

Staged rollout: from p=none to p=reject

Microsoft's recommended approach is gradual, aiming for p=reject, and starting with lower-volume domains or subdomains before the main domain. Move to the next stage only when the reports from the current stage are clean.

Easing in with pct. Microsoft's guide suggests stepping pct through 10, 25, 50, 75 and 100 at the quarantine stage (left out, it means 100). Be aware that the DMARC standard was revised in May 2026: RFC 9989 replaces RFC 7489, drops pct because receivers applied values other than 0 and 100 inconsistently, and adds a t=y test-mode flag instead. Records still start v=DMARC1 and keep working, but don't rely on a partial percentage being honoured by every receiver. Treat pct as an optional extra step, not a safety net.

Check at each stage: send a test message from every sending service (Microsoft 365, the invoicing system, the newsletter tool and so on) to an external mailbox and confirm the header shows:

spf=pass ... smtp.mailfrom=example.com.au (or a subdomain of it)
dkim=pass ... header.d=example.com.au
dmarc=pass ... header.from=example.com.au

DMARC passes if either SPF or DKIM passes and aligns. So a third-party service that passes SPF for its own domain (smtp.mailfrom=bounce.servicename.example) but doesn't sign with DKIM as your domain will fail DMARC. The fix is to set up DKIM for your domain in that service, or a custom return-path on your domain.

Check after enforcement: your aggregate reports should show a disposition of quarantine or reject for spoofed mail. Where the receiver is Microsoft 365 with its Honor DMARC record policy setting on, a spoof against p=quarantine is marked dmarc=fail action=quarantine and goes to Junk, and a spoof against p=reject is refused during delivery (550 5.7.1, recorded as action=oreject).

The same setting decides how your own tenant treats inbound mail that spoofs other domains. In the Defender portal it's Honor DMARC record policy when the message is detected as spoof in your anti-phishing policies; in Exchange Online PowerShell, check it with Get-AntiPhishPolicy | Format-List Name,HonorDmarcPolicy.

One more thing Microsoft points out: once your policy is quarantine or reject, outbound mail from your tenant that fails DMARC at the destination is routed through its high-risk delivery pool, with no override. That's another reason not to rush past stage 1.

How to read DMARC aggregate reports

Receivers send aggregate reports as compressed XML attachments, typically once a day. Raw XML is hard to read, so many organisations use a DMARC reporting service to turn them into readable summaries. Either way, the same fields matter:

The patterns you'll see most:

• Microsoft 365 IPs, aligned pass: healthy, no action.
• A known service, SPF pass but not aligned: the service uses its own bounce domain. Set up DKIM for your domain in that service.
• A known service, everything failing: it isn't in your SPF and isn't signing. Add it to SPF and set up DKIM.
• Unknown IPs, all failing: likely spoofing. Once you're at quarantine or reject, your policy is doing its job.
• Mailing lists and forwarders failing: normal. Forwarding breaks SPF, and edits to the message break DKIM.

Microsoft also notes that not every receiver sends reports, so the reports won't cover all of your mail.

DNS host notes for .au domains

These differences between DNS control panels cause most failed setups:

• Host field conventions. Some panels want just _dmarc or selector1._domainkey and add your domain automatically. Others want the full name (_dmarc.example.com.au). If you enter the full name into a panel that appends the domain, you end up with _dmarc.example.com.au.example.com.au. After saving, always check with dig or Resolve-DnsName.
• Trailing dots on CNAME values. Some panels need a trailing dot on the target (...dkim.mail.microsoft.) and some add it for you. A missing or extra dot is one of the DKIM problems Microsoft lists.
• TXT quotes. Some panels add quotation marks around TXT values automatically; others need you to. Don't end up with doubled quotes.
• DKIM is a CNAME, not a TXT record. Microsoft 365 uses CNAMEs for DKIM. Creating TXT records at selector1._domainkey won't work.
• TTL. Microsoft recommends at least 3600 seconds (one hour) for SPF records.
• Several domains. If you own example.com.au and also example.au or example.com, treat each separately. Each domain that sends mail needs its own SPF and DKIM. Domains that never send mail should be locked down as parked domains (below).

Lock down parked domains (and onmicrosoft.com)

For any domain you own that never sends email, publish records that say so:

example.au           TXT  v=spf1 -all
_dmarc.example.au    TXT  v=DMARC1; p=reject;

Microsoft also recommends a DMARC record on your example.onmicrosoft.com domain if you don't send from it. You add that in the Microsoft 365 admin center under Settings > Domains > your onmicrosoft.com domain > DNS records > Add record, with TXT name _dmarc and value v=DMARC1; p=reject.

Common mistakes

• Two SPF records. Usually created when a new service's setup guide says "add this TXT record". Merge them into one.
• More than 10 SPF lookups. Adding includes for every service adds up, especially as some include others. Move bulk or marketing mail to a subdomain (for example news.example.com.au) with its own SPF record; each subdomain gets its own 10-lookup budget.
• Forgetting other senders. The invoicing system that emails your invoices is the classic one. Jumping to p=reject without finding it means your invoices stop arriving.
• Leaving DMARC at p=none. Monitoring mode protects nobody from spoofing. It's a stage, not the destination.
• Sending reports to a personal inbox. They'll be ignored or filtered. Use a shared mailbox or a reporting service.

If you'd rather have this checked across all your domains and senders, including the Microsoft 365 settings around it (anti-phishing, external forwarding, MFA), our Microsoft 365 security review and email protection services cover it.

Key takeaways

• Publish exactly one SPF record, v=spf1 include:spf.protection.outlook.com -all, plus any other services you use, and stay under 10 DNS lookups.
• Enable DKIM in the Defender portal and copy the CNAME values from your own tenant; new domains use the dkim.mail.microsoft format introduced in May 2025.
• Start DMARC at p=none with a rua address, then move to quarantine and reject only when the reports show every legitimate sender passing and aligned.
• Check each stage in real headers for spf=pass, dkim=pass and dmarc=pass with your domain.
• Lock down parked domains and your onmicrosoft.com domain with v=spf1 -all and p=reject.

Sources

• Microsoft Learn, Set up SPF to identify valid email sources for your Microsoft 365 domain
• Microsoft Learn, How to use DKIM for email in your custom domain (updated August 2026)
• Microsoft Learn, Set up DMARC to validate email in Microsoft 365
• ASD's ACSC, How to combat fake emails
• ASD's ACSC, Protecting against business email compromise
• IETF, RFC 7208: Sender Policy Framework
• IETF, RFC 9989: DMARC (May 2026, replaces RFC 7489)
• .au Domain Administration, WHOIS lookup