Set up Microsoft 365 email authentication on GoDaddy

If you bought Microsoft 365 through GoDaddy, your SPF is already there and your MX records already work. What's missing is DKIM and DMARC — and there's a twist on DMARC: GoDaddy may have published one for you, pointing the reports at itself.

DKIM you generate in the Microsoft Defender portal, then publish as two CNAME records in Domain Portfolio → your domain → Domain Settings → DNS → Add New Record. And here's the part that invalidates most tutorials you'll find: since May 2025, Microsoft's DKIM values contain a character it assigns dynamically, which nobody can predict. Any guide handing you a ready-made value is wrong for you.

These records let receiving mail servers check that a message claiming to be from you really is from you. They do not guarantee your email reaches the inbox — your content and your sending reputation matter at least as much — but without them, anyone can send email in your name.

What we don't do: we never touch your DNS zone. This guide tells you what to type and where. You're the one who saves it, in your own account, with your own credentials.

Before anything else: check whether you already have a DMARC record

GoDaddy started publishing DMARC records automatically. In its own words: "Starting April 2025, all new domains purchased with GoDaddy have DMARC set up automatically. If you purchased your domain before April 2025, DMARC will be added automatically in the future."

The record it uses is:

v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net;

Read the rua= again. The reports go to GoDaddy, not to you. Your domain has a DMARC policy, any checker will call it compliant, and you will never see a single report about who is sending in your name — which is most of what DMARC is for.

The policy is also p=quarantine from day one, with no monitoring phase. If a legitimate sender of yours isn't authenticated yet — an invoicing tool, a contact form, a CRM — its mail is already being sent to junk, and the reports that would have told you are going somewhere you can't read.

So look before you write. If _dmarc.yourdomain.com already returns a record, you're editing it, not adding one. Section 3 below tells you what to change.

And check your nameservers. GoDaddy's DNS panel only manages your records if your domain uses GoDaddy nameservers. If DNS lives elsewhere, the values here don't change — the panel does.

The records to copy and paste

1. SPF — probably already done, and worth understanding

If you bought Microsoft 365 from GoDaddy with the domain in the same account, GoDaddy says: "If your domain, DNS and email are in the same GoDaddy account, we'll add your SPF record for you, and you won't need to do anything." The value it uses is v=spf1 include:secureserver.net -all.

That is not Microsoft's published value — Microsoft's is v=spf1 include:spf.protection.outlook.com -all. Curiously, Microsoft's own GoDaddy-specific page publishes GoDaddy's version, so both vendors agree even though it looks wrong at first glance. It works: secureserver.net expands to a GoDaddy list that itself includes spf.protection.outlook.com.

Two things worth knowing about that:

• It costs you three DNS lookups instead of one, out of a budget of ten. Microsoft is blunt about the ceiling: "If the number of DNS lookups… is greater than 10, the message fails SPF with a permanent error (also known as a permerror)." If you add two or three marketing tools later, that's where you'll run out.
• It authorises GoDaddy's whole sending infrastructure, not just your mailboxes.

If you set Microsoft 365 up yourself, or your DNS is elsewhere, use Microsoft's value:

On -all versus ~all: Microsoft genuinely recommends the strict version, and explains why: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain." It adds a point most guides get wrong: "DMARC treats -all (hard fail) and ~all (soft fail) as SPF failures." DMARC does not forgive a soft fail. The difference between the two only matters to servers that check SPF without DMARC.

⚠️ One SPF record per domain. Always. If GoDaddy already published one and you add another, SPF stops working entirely — including for the mailboxes that were fine yesterday. Edit, don't add.

2. DKIM — the part no tutorial can do for you

🔴 This is the most important thing on this page. Microsoft changed the DKIM record format in May 2025. The new value contains a dynamically assigned character, and Microsoft states plainly that it "is automatically assigned by Microsoft when you add a new custom domain and enable DKIM. The value is determined by Microsoft's internal routing logic and isn't configurable."

The shape of the new format is:

selector1._domainkey → selector1-<your-domain-with-dashes>._domainkey.<tenant>.<X>-v1.dkim.mail.microsoft
selector2._domainkey → selector2-<your-domain-with-dashes>._domainkey.<tenant>.<X>-v1.dkim.mail.microsoft

where <X> is that assigned character. You cannot guess it, and neither can any blog post.

Domains added before May 2025 keep the old format — Microsoft: "Existing custom domains and initial domains continue to use the old DKIM format" — which looked like selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Both formats are live in the world right now, which is exactly why copying values from a tutorial fails for half of readers. And you can't mix them: "The old and new formats can't coexist for the same selector."

So go and get your own values:

1. In the Defender portal at security.microsoft.com, go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings. (Or go straight to security.microsoft.com/authentication.)
2. Select the DKIM tab, then your domain.
3. Click Create DKIM keys. Microsoft generates two CNAME records and offers a Copy button.
4. Publish both in GoDaddy — Type CNAME, Name selector1._domainkey and selector2._domainkey, Value as copied.
5. Return to the DKIM tab and turn on Sign messages for this domain with DKIM signatures.

What you must replace: both values, entirely. They are generated for your tenant.

If step 5 fails, that's the expected behaviour, not a bug. Microsoft: if the CNAME records aren't detected, "A Client error dialog opens" and "the Status value of the domain is now CnameMissing". Its advice: "Check for typos in the values at the domain registrar (easy to do with the dashes, periods, and underlines!), wait a while longer, and then run the command again."

If you'd rather not click through the portal, Microsoft publishes the command that returns your exact values:

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

3. DMARC — yours, not your registrar's

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read.

If GoDaddy already published one (see the top of this page), edit that record rather than adding a second. Two changes matter:

• Point rua= at yourself. Reports sent to dmarc_rua@onsecureserver.net are reports you'll never read. If you want GoDaddy to keep receiving them too, DMARC allows several addresses separated by commas — but yours needs to be one of them.
• Consider stepping back to p=none first. Going from a policy you didn't know you had straight to enforcement is backwards. Watch your own reports for two to four weeks, confirm every legitimate sender is recognised, then tighten deliberately to p=quarantine and p=reject.

⚠️ One DMARC record per domain. Microsoft is explicit that duplicates break policy discovery entirely.

⚠️ Ignore the pct= in Microsoft's example. Microsoft's documented DMARC record is v=DMARC1; p=none; pct=100; rua=...; ruf=..., and it suggests ramping with pct=10, pct=25, pct=50, pct=75, pct=100. That tag was removed from the DMARC standard by RFC 9989, published in May 2026. Servers following the current standard ignore it, so a partial percentage gives you no partial rollout — just your full policy while you think you're easing in. Microsoft's staged advice is right; only the mechanism is obsolete. Ramp with the policy itself.

Microsoft's sequencing is otherwise sound and worth repeating: "Start with a DMARC policy of p=none and monitor the results for the domain… Go slowly and methodically deal with issues that are revealed in DMARC reporting." It gives no durations — those are ours: two to four weeks per step.

The click path

1. Sign in and open your Domain Portfolio.
2. Select the domain to open its Domain Settings page.
3. Select DNS.
4. Select Add New Record, then pick the Type — CNAME for the two DKIM records, TXT for SPF and DMARC.
5. Fill in Name, Value, and TTL.
6. Select Save.

The Name field wants the prefix only. GoDaddy: "The hostname or prefix of the record, without the domain name. Enter @ to put the record on your root domain, or enter a prefix, such as mail." So @ for SPF, _dmarc for DMARC, selector1._domainkey and selector2._domainkey for DKIM — never with your domain appended.

Domain Protection adds a verification step. GoDaddy asks for a 2SV code, an authenticator code, or a one-time password sent to your account email before it saves DNS changes.

Two records you may also need, if Microsoft 365 wasn't set up for you: the CNAME autodiscover → autodiscover.outlook.com, and the TXT verification record in the form MS=msXXXXXXXX that the Microsoft setup wizard gives you. Microsoft still lists both as required.

The 3 mistakes we see most often here

1. Copying a DKIM value from a tutorial

It's the single most common failure on Microsoft 365, and since May 2025 it's guaranteed for new domains. Any page that gives you selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com as a value to use is describing the old format — correct for domains added before May 2025, wrong for everyone since, and impossible to adapt by hand because of the assigned character.

How you spot it: the Defender portal shows CnameMissing, or the DKIM toggle refuses to move to Enabled and throws a Client error.

The fix: get your two values from the Defender portal (or the PowerShell command above) and publish exactly those. Never a value from a guide, including this one.

2. Believing "Domain setup is complete"

Microsoft's add-domain wizard ends on a page that says, literally, "Domain setup is complete". What it set up is domain ownership, MX, autodiscover and SPF. Not DKIM. Not DMARC.

Microsoft's own GoDaddy-specific instructions page has the same shape: it walks through the verification TXT, MX, autodiscover, SPF and the Teams SRV records, and then stops. Neither DKIM nor DMARC appears anywhere on it. Follow that page to the letter and you finish with SPF only.

How you spot it: your mail flows perfectly, the setup wizard said complete, and a lookup shows no selector1._domainkey and no _dmarc — or a _dmarc reporting to your registrar.

The fix: treat the wizard as step one of three. DKIM is section 2 above; DMARC is section 3.

3. Adding a second DMARC record on top of GoDaddy's

This one is new, and it will catch careful people, because GoDaddy's own DMARC-for-Microsoft-365 article walks you through creating a _dmarc record without ever telling you to check whether one already exists — even though GoDaddy has been publishing them automatically since April 2025.

Two DMARC records mean no DMARC at all. Microsoft: if multiple records are present, "the receiving email server will immediately end its policy discovery process and your DMARC policy will not be applied."

How you spot it: a scan reports multiple DMARC records, or your policy appears to be ignored entirely.

The fix: look up _dmarc.yourdomain.com first. If something is there, edit it. Keep one record.

⚠️ And don't mix up two opposite traps. Typing the full hostname in GoDaddy's Name field creates a duplicated domain (_dmarc.yourdomain.com.yourdomain.com) and the fix is to shorten it. At some other hosts (OVH, Gandi), the symmetrical trap sits on a CNAME target, where the fix is to add a trailing dot. Same look, opposite fixes.

How long before it takes effect

• In GoDaddy: saved as soon as you select Save. Its figure for the world: "Most DNS changes take effect within an hour but could take up to 48 hours to update globally."
• For Microsoft to see your CNAMEs: "It takes a few minutes (or possibly longer) for Microsoft 365 to detect the new CNAME records you created." Microsoft publishes no fixed figure for DKIM activation — don't trust a guide that gives you one.
• After a DKIM key rotation: "It takes four days (96 hours) for the new private key to start signing messages."
• The old value can stay cached for as long as the TTL you had set before the change.
• For DMARC reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day.

Next steps

• How to set up SPF, DKIM and DMARC on GoDaddy
• Set up Google Workspace email authentication on GoDaddy
• How to move your DMARC policy to p=reject safely
• My emails go to spam even though SPF, DKIM and DMARC pass