My onmicrosoft.com domain already passes DKIM — do I still need to set this up for my real domain?

Yes. Microsoft auto-signs only the *.onmicrosoft.com domain. Mail you send from yourdomain.com is not DKIM-signed with your domain until you publish the two selector CNAMEs and enable signing in Defender. Without it, your brand-domain mail relies on SPF alone and fails DMARC whenever it's forwarded or hits a mailing list.

Should my SPF use include:spf.protection.outlook.com or include:secureserver.net?

If you bought Microsoft 365 directly from Microsoft and just host DNS at GoDaddy/IONOS, use include:spf.protection.outlook.com. If you bought 'Microsoft 365 from GoDaddy,' GoDaddy's setup and auto-managed DNS use include:secureserver.net — but that's GoDaddy's own mail include, so if your actual outbound is Exchange Online, spf.protection.outlook.com is what authorizes Microsoft's servers. Use whichever your current provider instructions specify, never both, and only one SPF record total.

Why does the Defender DKIM toggle throw an error the first time I flip it?

That's expected. The first attempt generates your tenant's key pair and returns the CNAME values you need — it can't sign yet because the DNS records don't exist. Close the Client error dialog, copy the two targets from the domain's Publish CNAMEs flyout, publish them at GoDaddy/IONOS, wait for propagation, then flip the toggle again to actually enable signing.

My DKIM target ends in .onmicrosoft.com but a guide shows dkim.mail.microsoft — which is right?

Both are valid. Microsoft introduced the newer ... -v1.dkim.mail.microsoft target format for custom domains added since roughly May 2025; domains that enabled DKIM earlier keep the older selector1-yourdomain-com._domainkey. .onmicrosoft.com targets, and Microsoft honors both. What matters is that you publish exactly the two targets the Defender DKIM flyout (or Get-DkimSigningConfig) shows for YOUR domain — don't convert one format to the other by hand, and don't mix formats across your two selectors.

I added the CNAMEs but Defender still says CnameMissing — what now?

Almost always one of two things: DNS hasn't propagated yet, or the records were saved with the wrong type/host. Give it time (usually minutes, occasionally a few hours), then confirm with dig/nslookup that selector1._domainkey.yourdomain.com returns a CNAME to a ...dkim.mail.microsoft (or ...onmicrosoft.com) target — not a TXT and not NXDOMAIN. On GoDaddy/IONOS, check you entered just selector1._domainkey in the host field (they auto-append your domain) and picked CNAME, not TXT. Once it resolves, reopen the flyout and flip the signing toggle again.

Do I edit these records at GoDaddy/IONOS or inside Microsoft 365?

The records live in your DNS host — the GoDaddy or IONOS DNS editor — but you read the exact values (the MX token, the DKIM CNAME targets) from Microsoft's admin center and Defender portal. If your zone is auto-managed by 'Microsoft 365 from GoDaddy' or an IONOS-connected setup, the admin center may write MX/SPF/autodiscover for you; the two DKIM selector CNAMEs you still add yourself. Either way, keep exactly one SPF and one _dmarc record for the whole domain.

SPF setup guide

SPF, DKIM & DMARC for Microsoft 365 (GoDaddy / IONOS).

Microsoft 365 (Exchange Online) authenticates your domain with a mix you assemble yourself: one shared SPF include you add to your root record, two DKIM CNAME records whose exact targets you generate inside the Microsoft Defender portal, and a DMARC policy record — all published in whichever DNS panel holds your domain, here GoDaddy or IONOS. The catch that trips up most M365 tenants: your free *.onmicrosoft.com domain is DKIM-signed automatically, but your custom domain (yourdomain.com) is NOT — you have to turn its DKIM signing on by hand, or your branded mail leans on SPF alone and fails DMARC the moment it's forwarded. This guide walks the real GoDaddy/IONOS-plus-M365 path end to end: the SPF include (and the GoDaddy reseller twist), generating the DKIM CNAMEs in Defender, publishing them without breaking on the record type, and adding DMARC.

SPF include

Your DNSAdd the CNAME / TXT records

Microsoft 365 (GoDaddy / IONOS)Signs & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Microsoft 365 (GoDaddy / IONOS)?

For a Microsoft 365 domain, authentication isn't hygiene — it's the difference between the inbox and the junk folder. Since February 2024, Gmail and Yahoo have required bulk senders (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft itself began enforcing the same requirements on Outlook.com and Hotmail for high-volume senders in May 2025 — mail that doesn't comply gets throttled or rejected outright. M365 has a specific trap on top of that: Microsoft auto-signs DKIM for your onmicrosoft.com domain, so tenants assume DKIM 'just works' and never enable it for their real brand domain. It doesn't. Until you publish the two selector CNAMEs and flip the signing toggle in Defender, your custom-domain mail carries no DKIM signature aligned to yourdomain.com — it passes DMARC only via SPF, which breaks on any forward or mailing list because the Return-Path changes but the signature that would have survived was never there. Enabling custom-domain DKIM closes that gap: SPF and DKIM both align to yourdomain.com, DMARC passes reliably, and the reputation you build accrues to your domain.

The SPF reality for Microsoft 365 (GoDaddy / IONOS)

Microsoft 365 is a genuine SPF-include provider: you add include:spf.protection.outlook.com to your domain's single root SPF TXT record, and that one include authorizes every Exchange Online outbound IP. Microsoft's recommended record is v=spf1 include:spf.protection.outlook.com -all (a hard fail; use ~all only while you're testing). That include resolves to a flat list of ip4/ip6 ranges with no nested includes, so it costs exactly one of your ten allowed SPF DNS lookups — cheap and stable. Two provider wrinkles matter on GoDaddy and IONOS. (1) If you bought 'Microsoft 365 from GoDaddy,' GoDaddy's own setup and its auto-managed DNS prescribe v=spf1 include:secureserver.net -all instead — but secureserver.net is really GoDaddy's own shared mail include, not Microsoft's, so if your outbound genuinely runs through Exchange Online, spf.protection.outlook.com is the include that actually authorizes Microsoft's servers. Use whichever your current GoDaddy instructions specify, don't stack both, and verify the include you keep resolves to Microsoft's ranges. IONOS-resold M365 normally still uses spf.protection.outlook.com. (2) You may already have a stray SPF record: GoDaddy parks domains with a default include:secureserver.net SPF and IONOS mail can pre-seed one. A domain must have exactly ONE SPF record — merge the Microsoft include into the existing v=spf1 line rather than publishing a second TXT, or every SPF check fails as 'permerror.'

Step by step

Before you start

1
Confirm the domain is verified in M365 and know your tenant prefix
In the Microsoft 365 admin center (admin.microsoft.com -> Settings -> Domains), make sure yourdomain.com is added and shows Healthy/Verified. Note your tenant's onmicrosoft.com prefix (the 'contoso' in contoso.onmicrosoft.com) — it appears in your DKIM targets. You'll need Global Administrator or Security Administrator rights to enable DKIM in Defender. Also settle one question up front: did you buy M365 directly from Microsoft, or as 'Microsoft 365 from GoDaddy' / an IONOS-connected plan? That decides which SPF include you use and whether your DNS is auto-managed.

In your DNS panel

2
Open the GoDaddy or IONOS DNS editor
GoDaddy: sign in at account.godaddy.com, go to Domains, select yourdomain.com, then open Manage DNS (Domain Settings -> DNS). IONOS: sign in, open Menu -> Domains & SSL, find the domain, click the gear/Actions control, and choose DNS. Both show a table of existing records with an Add Record button.
3
Publish or merge the SPF record
Add a TXT record with Host/Name = @ (root) and value v=spf1 include:spf.protection.outlook.com -all. If an SPF record (any TXT starting v=spf1) already exists, EDIT it — insert include:spf.protection.outlook.com before the -all/~all — rather than creating a second one. On 'Microsoft 365 from GoDaddy' the reseller flow uses include:secureserver.net; keep only one include, and if your real outbound is Exchange Online use spf.protection.outlook.com. TTL of 1 hour is fine.

In Microsoft 365 admin center

4
Add the MX and autodiscover records so mail routes to Exchange Online
On the admin center's domain page, Microsoft lists the exact DNS records to add in your DNS panel. Add the MX (points to yourdomain-com.mail.protection.outlook.com, priority 0) and the CNAME autodiscover -> autodiscover.outlook.com. These handle receiving and client setup — SPF/DKIM/DMARC are separate, but a real M365 mailbox setup needs them too. On IONOS, note the MX-vs-autodiscover limitation in the gotchas below.

In Microsoft 365 (Defender)

5
Generate your two DKIM CNAME targets
Go to the Defender portal at security.microsoft.com/authentication (Email & collaboration -> Policies & rules -> Threat policies -> Email authentication settings), open the DKIM tab, and click your custom domain. Try to slide its toggle to Enabled (or use 'Create DKIM keys' in the details flyout) — the first attempt deliberately throws a Client error / 'CNAME record doesn't exist' dialog and generates your key pair. Reopen the domain's details flyout: the Publish CNAMEs section now shows the two host/value pairs (Status = CnameMissing). New domains use the current format ending in ...<char>-v1.dkim.mail.microsoft; older tenants may show the ...onmicrosoft.com format. Copy both exactly — or run Get-DkimSigningConfig in Exchange Online PowerShell to read Selector1CNAME/Selector2CNAME.

In your DNS panel

6
Publish the two DKIM CNAME records
Back in GoDaddy/IONOS, add two CNAME records. Host/Name = selector1._domainkey and selector2._domainkey (just the selector — GoDaddy and IONOS auto-append yourdomain.com, so don't paste the full FQDN). 'Points to' = the two targets from the Defender flyout. Record type MUST be CNAME, never TXT — this is the single most common failure. Save both.

In Microsoft 365 (Defender)

7
Enable DKIM signing
Wait a few minutes for the CNAMEs to resolve (occasionally up to a few hours), then return to the domain's flyout in the Defender DKIM tab and slide 'Sign messages for this domain with DKIM signatures' to Enabled. When it succeeds, Status changes to 'Signing DKIM signatures for this domain' and Rotate DKIM keys becomes available. If it errors, the CNAMEs haven't propagated or the record type/host is wrong — fix DNS first, then retry.

In your DNS panel

8
Add your DMARC policy record
Add a TXT record with Host/Name = _dmarc and value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only) so nothing is affected while you confirm M365 mail passes aligned SPF and DKIM. Keep exactly one _dmarc record for the whole domain.

Verify

9
Confirm authentication on a real message
Send a test from a mailbox on yourdomain.com to a Gmail address, open it, and use Show original: you want SPF: PASS, DKIM: PASS, and DMARC: PASS, all listing yourdomain.com (not onmicrosoft.com). Then run the domain through a checker to confirm every record resolves and DKIM is signing.

Records to add

Microsoft 365 (GoDaddy / IONOS) generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
TXT	@	v=spf1 include:spf.protection.outlook.com -allOne SPF record only — merge into any existing v=spf1 line. 'Microsoft 365 from GoDaddy' prescribes include:secureserver.net instead; for true Exchange Online outbound, spf.protection.outlook.com is the include that authorizes Microsoft.
MX	@	yourdomain-com.mail.protection.outlook.comPriority 0. Exact token is shown on the M365 admin center domain page; routes inbound mail to Exchange Online.
CNAME	autodiscover	autodiscover.outlook.comOutlook / mobile client auto-setup. See the IONOS MX-coexistence gotcha.
CNAME	selector1._domainkey	selector1-yourdomain-com._domainkey.contoso.a-v1.dkim.mail.microsoftIllustrative — copy the exact target from the Defender DKIM flyout (contoso = your tenant prefix, a = Microsoft's assigned dynamic character). Must be CNAME, not TXT.
CNAME	selector2._domainkey	selector2-yourdomain-com._domainkey.contoso.a-v1.dkim.mail.microsoftSecond selector, required for automatic key rotation. Older tenants show a ...contoso.onmicrosoft.com target instead — use whichever the portal shows.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comStart at p=none, tighten to quarantine/reject later. One _dmarc record per domain.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Microsoft 365 (GoDaddy / IONOS)'s setup costs against that budget.

SPF 10-lookup budget1 used · 9 free

Microsoft 365 (GoDaddy / IONOS) adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

DKIM for a Microsoft 365 custom domain is delivered through two CNAME records — selector1._domainkey and selector2._domainkey — that point at Microsoft-hosted public keys, so you never paste a raw key or TXT record. Microsoft holds the private keys and uses the two selectors to rotate them automatically once signing is on. The exact targets are unique to your tenant and you must read them from the Defender portal (security.microsoft.com/authentication -> DKIM tab -> your domain -> the details flyout, Publish CNAMEs section) or from Get-DkimSigningConfig in Exchange Online PowerShell. Custom domains added since roughly May 2025 get the current target format selector1-yourdomain-com._domainkey.<tenantprefix>.<dynamicchar>-v1.dkim.mail.microsoft (the dynamic character, e.g. a/n/r, is assigned by Microsoft and isn't configurable); domains enabled earlier keep the older selector1-yourdomain-com._domainkey.<tenantprefix>.onmicrosoft.com format. Use whichever format the portal shows for YOUR domain — Microsoft honors both, but don't convert one to the other by hand or mix formats across your two selectors. Two hard rules on GoDaddy/IONOS: the records must be type CNAME (not TXT — the #1 cause of 'DKIM won't enable'), and you must publish them BEFORE you flip the signing toggle, or Defender reports CnameMissing and refuses to sign. Your onmicrosoft.com domain is signed automatically and needs none of this — but that signing does nothing for mail sent from your brand domain.

DMARC

DMARC is a single TXT policy record at _dmarc.yourdomain.com, independent of SPF and DKIM but the piece that ties them together. Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to start in monitor-only mode — it changes nothing about delivery while you confirm that M365 mail passes SPF and DKIM both aligned to yourdomain.com. Exchange Online sets the SMTP MAIL FROM (Return-Path) to your domain and, once custom-domain DKIM is enabled, signs with d=yourdomain.com, so both authentication methods align and DMARC passes cleanly. Watch the aggregate (rua) reports for a week or two, make sure Microsoft shows up as a passing, aligned source and no legitimate third-party sender (a CRM, a marketing tool) is failing, then tighten to p=quarantine and eventually p=reject. Keep exactly one _dmarc record no matter how many services send as your domain — GoDaddy and IONOS will happily let you create a duplicate, and two _dmarc records is an invalid configuration.

Check it actually worked

Don't trust the Defender 'Signing DKIM signatures for this domain' badge alone — confirm it on a live message. Send a test from a mailbox on yourdomain.com to a Gmail account, open it, and choose the three-dot menu -> Show original: you want SPF: PASS, DKIM: PASS, and DMARC: PASS, with the DKIM signature's d= showing yourdomain.com (not yourtenant.onmicrosoft.com). For a plain-text report you can also send to check-auth@verifier.port25.com and read the reply. On the DNS side, confirm both selector CNAMEs actually resolve to Microsoft targets (dig/nslookup selector1._domainkey.yourdomain.com CNAME) — a common GoDaddy mistake is the record silently saved as TXT, which resolves as nothing. Run the domain through Qualisend's SPF/DKIM/DMARC checker and domain health check to confirm SPF has exactly one record and one lookup for the Outlook include, both DKIM selectors are live, and DMARC is valid. Once aggregate reports start arriving, drop one into the DMARC report analyzer — Microsoft should appear as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

DNS setup
DKIM records must be type CNAME, not TXT. GoDaddy and IONOS both default the Add Record dropdown to other types, and a selector saved as TXT resolves to nothing — this is the number-one reason 'DKIM won't enable' in Defender.
DNS setup
Publish the two selector CNAMEs BEFORE you flip the Defender signing toggle. The first toggle attempt is meant to fail (a Client error / 'CNAME record doesn't exist' dialog) — it just generates the keys and shows you the CNAME values. If you enable before the CNAMEs resolve, Status stays CnameMissing and signing won't turn on.
Coverage
Custom-domain DKIM is OFF by default. Microsoft auto-signs only your *.onmicrosoft.com domain, so tenants wrongly assume DKIM is handled. Mail from yourdomain.com stays unsigned — and DMARC-fragile on forwards — until you enable it.
Breaks auth
A domain may have only ONE SPF record. GoDaddy parks domains with a default include:secureserver.net SPF and IONOS-resold mail can pre-seed one; adding a second v=spf1 TXT for Microsoft causes a permerror. Merge include:spf.protection.outlook.com into the existing line instead.
Coverage
GoDaddy and IONOS auto-append your domain to the Host/Name field. Enter just selector1._domainkey, @, or _dmarc — never the full yourdomain.com FQDN, or you'll create selector1._domainkey.yourdomain.com.yourdomain.com.
DNS setup
IONOS won't let a domain hold both an MX record and a top-level autodiscover CNAME at once — a documented Exchange Online limitation. Either skip the root autodiscover CNAME or create it on a subdomain per IONOS's workaround; it doesn't affect SPF/DKIM/DMARC.
Coverage
If you bought 'Microsoft 365 from GoDaddy,' your DNS is likely auto-managed and GoDaddy's prescribed SPF include is its own include:secureserver.net, not spf.protection.outlook.com — and hand edits can be overwritten. IONOS-connected M365 can likewise auto-write records. Check who controls your zone before hand-editing, and if your real outbound is Exchange Online, confirm the SPF include actually authorizes Microsoft's servers.
Coverage
Don't jump straight to DMARC p=reject. Start at p=none, read the aggregate reports until Microsoft and every legitimate sender show as aligned/passing, then step up to quarantine and reject — otherwise you can null-route your own mail.

Build your SPF record

Microsoft 365 (GoDaddy / IONOS) is pre-selected below. Add any other platforms you send through, then publish the single merged record.

Sending sources

Search for each platform you send email through and tick it.

Selected

Microsoft 365 (GoDaddy / IONOS)include:spf.protection.outlook.comGuide →

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record1/10 DNS lookups

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

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list

SPF, DKIM & DMARC for Microsoft 365 (GoDaddy / IONOS).

Why authenticate Microsoft 365 (GoDaddy / IONOS)?

The SPF reality for Microsoft 365 (GoDaddy / IONOS)

Step by step

Records to add

The 10-lookup budget

DKIM

DMARC

Check it actually worked

Common gotchas

Build your SPF record

Sending sources

This domain's own servers

Other senders & IPs

Policy for everyone else

Microsoft 365 (GoDaddy / IONOS) SPF — FAQ

Related reading