GoDaddy + Microsoft 365: SPF, DKIM and DMARC setup that passes

This guide walks through the complete GoDaddy Microsoft 365 SPF, DKIM and DMARC setup. If your Microsoft 365 mail is landing in spam, or someone is sending invoices as your domain, the cause is almost always the same three records — published wrongly, published twice, or never published at all. This fixes that for a domain whose DNS lives at GoDaddy.

Before you touch anything

Run your domain through our free record checker and screenshot the result. You will want to know what was there before, and it tells you which steps below you can skip.

What each record does

Three records, three separate jobs. Publishing one and assuming you are covered is the usual reason mail still lands in spam.

Record	What it says	Without it
SPF	Which servers may send mail for your domain.	Receivers cannot tell your mail from a forgery.
DKIM	A signature proving the message was not altered in transit.	Mail can be tampered with and still look valid.
DMARC	What to do when a message fails, and where to send reports.	Failures are delivered anyway, and you never learn who is spoofing you.

Since 2024 Gmail and Microsoft both expect all three from anyone sending at volume. A missing DMARC record alone is now enough to affect placement. The formats themselves are open standards: SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 7489).

Step 1 — Find the DNS editor and lower the TTL

In GoDaddy: My Products → Domains → DNS → DNS Records → Add New Record

Choose Custom and enter 600 seconds while you work, then set it back to 1 hour. TTL is how long resolvers cache a record — at four hours, a typo takes four hours to correct everywhere; at five minutes it is effectively reversible. Put it back once everything passes.

GoDaddy-specific warning

GoDaddy often pre-publishes its own SPF record containing include:secureserver.net. Do not leave it alongside a new one — merge or remove it, because two SPF records fail completely.

Step 2 — Audit what is already there

List every record of type TXT and write down anything starting with v=spf1.

• Zero SPF records — straightforward; you add one in step 3.
• Exactly one — you will edit it, not add another.
• Two or more — already broken, and the most common state we find. Step 3 fixes it by merging.

Note any include from a previous host. Whether you keep it comes down to one question: does that server still send mail for you? A website contact form or WooCommerce order notification counts. If nothing sends from there any more, drop it.

Step 3 — Publish exactly one GoDaddy Microsoft 365 SPF record

Add a new record in GoDaddy with these values:

Field	Value
Type	TXT
Name	@
Value	v=spf1 include:spf.protection.outlook.com ~all
TTL	Low, as set in step 1

GoDaddy's Name field takes @ for the root. Entering the domain creates a doubled hostname. Paste the value unquoted. GoDaddy trims trailing spaces but not line breaks — keep it on one line.

If you also send from your website or another service

Merge, never duplicate. One record, one v=spf1 at the start, one ~all at the end, every include in between:

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

Keep the total number of DNS-resolving mechanisms — every include:, a:, mx: and redirect= — at ten or fewer. Above ten, SPF returns a permanent error and fails as though absent.

The mistake that breaks the most mail

Adding a second SPF record when you connect a new provider. Two records do not combine — they make SPF fail completely, which is worse than having none. If your checker result showed two, deleting one is the highest-value thing you will do today.

Why ~all rather than -all? Softfail marks unlisted senders as suspicious; hardfail rejects them outright. Start with ~all and tighten once DMARC reports confirm nothing legitimate is being missed. Never use +all — it authorises the entire internet to send as you.

Step 4 — Generate the DKIM key in Microsoft 365

This half happens in Microsoft 365, not GoDaddy. Go to Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.

1. Select your domain in the DKIM list and click Create DKIM keys.
2. Microsoft shows two CNAME targets — copy both; DKIM here needs two records, not one.
3. Domains added since May 2025 get targets ending in -v1.dkim.mail.microsoft (selector1-yourdomain-com._domainkey.yourtenant.<letter>-v1.dkim.mail.microsoft); older domains use selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com. Copy exactly what the portal shows — the two formats cannot be mixed for the same selector.
4. Publish both CNAMEs before returning to the portal.

Leave that tab open — you come back to it in step 5, and forgetting to is the second most common failure.

If Microsoft 365 has moved its screens around since this was written, its official DKIM instructions always show the current path.

Add the DKIM records in GoDaddy

Field	Value
Type	CNAME
Name	selector1._domainkey and selector2._domainkey
Value	The CNAME target Microsoft 365 gives you — one record per selector
TTL	Low, as set in step 1

Use the bare host as shown — not the full selector1._domainkey.yourdomain.com, for the same reason as the SPF record. If the value is rejected as too long, remove any line breaks your clipboard introduced; it must be one continuous string.

Step 5 — Switch signing on (the step everyone forgets)

Once both CNAMEs resolve, go back to the DKIM page and switch Sign messages for this domain with DKIM signatures to Enabled. Microsoft refuses to enable it until both records are visible.

The two selectors rotate keys automatically — never delete one because it looks unused. If enabling fails, the usual cause is a typo in the tenant part of the target, which is easy to mistype and impossible to spot at a glance.

Step 6 — Publish DMARC in monitoring mode

Back in GoDaddy, one more record:

Field	Value
Type	TXT
Name	_dmarc
Value	v=DMARC1; p=none; rua=mailto:you@yourdomain.com; fo=1
TTL	Low, as set in step 1

Start at p=none. It enforces nothing, but it starts the aggregate reports arriving, and those reports are how you find the sender you forgot about — the invoicing tool, the CRM, the old newsletter platform.

Resist going straight to p=reject. On a domain with a forgotten sender, reject means those messages vanish silently, and the first you hear of it is a client asking why they never got your quote.

Step 7 — Verify, then tighten

Wait fifteen minutes, then check all three. From a terminal:

dig yourdomain.com TXT +short
dig selector1._domainkey.yourdomain.com CNAME +short
dig _dmarc.yourdomain.com TXT +short

Or run the domain through our record checker, which flags duplicates and weak policies for you. For an end-to-end test, send a message to a Gmail address you own, open it and use Show original — you want PASS beside SPF, DKIM and DMARC. Once all three pass, your GoDaddy Microsoft 365 SPF, DKIM and DMARC setup is done — the rest is tightening.

The tightening schedule

• Week 1–2: leave p=none and read the reports. Identify every legitimate sender.
• Week 3: add missing senders to SPF (merged into the one record), then move to p=quarantine.
• Week 5+: if reports stay clean, move to p=reject and change SPF to -all.
• Finally: restore the TTLs.

A note on MX records

Microsoft's MX is yourdomain-com.mail.protection.outlook.com at priority 0, with your domain's dots replaced by hyphens. Also publish the autodiscover CNAME to autodiscover.outlook.com so Outlook configures itself.

MX records are separate from the GoDaddy Microsoft 365 SPF record: MX decides where mail for your domain is delivered, SPF decides who may send it. Authentication cannot fix a routing problem. If mail is not arriving at all — as opposed to arriving in spam — the MX records are where to look first, not SPF.

When it still does not work

Mail still in spam with all three passing

Authentication is necessary, not sufficient. Check your domain and sending IP against a blocklist, make sure you are not mailing purchased lists, and give a brand-new domain a few weeks of low-volume sending before expecting good placement.

Microsoft 365 says the DKIM record cannot be found

Nine times out of ten the host field contains the domain twice. Open the record in GoDaddy and confirm it reads exactly selector1._domainkey and selector2._domainkey.

SPF was fine, then broke after adding a service

That service told you to "add this SPF record" and you added a second one. Merge them into one.

DMARC reports arrive as unreadable XML

They are meant to — the format is for machines. Paste one into any free DMARC report analyser, or point rua at a reporting service that renders them for you.

GoDaddy Microsoft 365 SPF, DKIM and DMARC: quick answers

How long do GoDaddy DNS changes take to work?

It depends on the TTL. On GoDaddy: Choose Custom and enter 600 seconds while you work, then set it back to 1 hour. With a low TTL most resolvers see a change within 15 to 60 minutes; at a four-hour default, allow up to four hours, occasionally longer.

I already have an SPF record on GoDaddy. Do I add another one for Microsoft 365?

No. Edit the record you have and add include:spf.protection.outlook.com to it, keeping a single v=spf1 at the start and one ~all at the end. A second SPF record makes SPF fail for every message.

Which DKIM record does Microsoft 365 use?

Microsoft 365 uses two CNAME records at selector1._domainkey and selector2._domainkey, generated in Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Publishing it is only half the job — signing has to be switched on as well, as in step 5.

Which DMARC policy should I start with?

p=none with a rua= address, so reports start arriving without anything being blocked. After two or three weeks of clean reports move to p=quarantine, then to p=reject.

Can someone do this for me?

Yes. We publish the records on GoDaddy, configure Microsoft 365, verify that all three pass and send you the proof, for $49 flat — get in touch. Using a different host or mail provider? Every combination is in the guides hub.