How do I set up DNS records for GoDaddy, Outlook, Gmail, and Yahoo to be ready for email authentication updates?
Published 13 Aug 2025
Updated 4 Jun 2026
10 min read
Summarize with
The direct answer is this: GoDaddy is usually only the DNS host, Outlook means Microsoft 365 mail, and Gmail and Yahoo are mostly the receivers enforcing stricter authentication rules. To be ready, publish Microsoft 365 MX, SPF, DKIM CNAME, and Autodiscover records in GoDaddy, add DKIM records for every other platform that sends mail using your domain, then publish one DMARC TXT record at _dmarc. Start DMARC at p=none, review reports, then move to p=quarantine and p=reject when real mail is passing.
The key caveat is that no single article can give final DKIM values for every domain. Microsoft, Google Workspace, an email marketing platform, a helpdesk, a store platform, and any app that sends invoices or password resets each gives its own records. I treat GoDaddy as the place where the records are published, not the source of truth for all record values.
For ongoing visibility, Suped's DMARC monitoring shows which services are passing SPF, DKIM, and DMARC, which sources need fixes, and when it is safe to tighten policy.
The direct setup path
Start by separating four jobs that often get mixed together. GoDaddy holds the DNS zone if your nameservers point there. Outlook, usually Microsoft 365, handles mailbox delivery. Gmail and Yahoo evaluate the mail you send to their users. Your other senders, such as ecommerce, CRM, support, and marketing systems, need their own authentication records too.
- Confirm DNS host: In GoDaddy, check that the domain uses GoDaddy nameservers. If not, publish records at the active DNS host instead.
- Add Outlook records: Use Microsoft 365's admin center values for MX, SPF, DKIM CNAME, and Autodiscover. The Microsoft GoDaddy DNS records page is the safest reference for that handoff.
- Authenticate every sender: If a platform sends using your domain, add its DKIM record and include its sending mechanism in SPF only when needed.
- Publish DMARC: Create one DMARC TXT record for the organizational domain, then monitor before moving to an enforcement policy.
- Verify with real mail: Send messages through Outlook and every other sender, then confirm SPF, DKIM, and DMARC pass with your domain.
Do not copy DKIM targets from another domain. DKIM selectors are domain-specific and tenant-specific. Microsoft and each sender must generate the records for the exact domain you are authenticating.
GoDaddy DNS Management screen showing common email authentication records.
What each provider needs
The setup changes depending on who sends mail for the domain. Gmail and Yahoo updates do not mean you publish special Yahoo records in GoDaddy. They mean your messages to gmail.com, googlemail.com, yahoo.com, and related inboxes need to pass authentication, keep low spam complaints, and use DMARC on the visible From domain. The specific sender rules are covered separately in the new Gmail and Yahoo requirements article.
DNS is only the authentication part. For subscribed or marketing mail, Gmail and Yahoo also expect one-click unsubscribe support, low complaint rates, and secure transport. Those are not GoDaddy DNS records, but they affect whether authenticated mail is accepted cleanly.
|
|
|
|---|---|---|
 GoDaddy | DNS host | Publishes TXT, CNAME, MX |
 Outlook | Mailbox host | MX, SPF, DKIM, Autodiscover |
 Gmail | Receiver or host | Receiver checks, or Google records |
 Yahoo | Receiver | Checks SPF, DKIM, DMARC |
Other senders | Mail source | Usually DKIM, sometimes SPF |
Use provider-generated values where the table says admin center or sender portal.
GoDaddy as registrar
If GoDaddy only registered the domain, DNS changes happen somewhere else. Updating records in the wrong zone has no effect, even when the domain was bought through GoDaddy.
- Check nameservers: The active nameservers decide where SPF, DKIM, DMARC, and MX records must be edited.
- Avoid duplicate zones: A perfect record in an inactive GoDaddy zone will not authenticate any mail.
GoDaddy as DNS host
If GoDaddy hosts DNS, use the record name exactly as the sender gives it. For root records, GoDaddy usually expects @.
- Use short hosts: Enter _dmarc rather than the full name unless the UI asks for a full host.
- Keep one SPF: A domain should have one root SPF TXT record, with approved senders merged into it.
The DNS records to publish
For a GoDaddy domain using Outlook, publish the Microsoft 365 records that the admin center gives you. The examples below show the normal shape of the records, but the tenant part of the DKIM CNAME target must come from your Microsoft 365 tenant.
Typical Microsoft 365 records in GoDaddydns
Host: @ Type: MX Value: yourdomain-com.mail.protection.outlook.com Priority: 0 Host: @ Type: TXT Value: "v=spf1 include:spf.protection.outlook.com -all" Host: selector1._domainkey Type: CNAME Value: selector1-yourdomain-com._domainkey.tenant.onmicrosoft.com Host: selector2._domainkey Type: CNAME Value: selector2-yourdomain-com._domainkey.tenant.onmicrosoft.com Host: autodiscover Type: CNAME Value: autodiscover.outlook.com
SPF lists the servers allowed to send for the domain. If Outlook is the only sender, Microsoft 365's include is enough. If another platform sends using the same From domain, SPF might need that sender too, but DKIM is usually the cleaner control because each platform can sign mail with its own selector.
One domain should not have two separate SPF TXT records at @. If you find two, merge approved senders into one SPF record. Multiple SPF TXT records cause SPF permerror and can break DMARC alignment.
The DMARC record is the policy receivers use after SPF and DKIM are evaluated. For a first rollout, publish a monitoring record and send aggregate reports to a real reporting address. Suped gives you a reporting address when you add the domain, and the record generator can create a clean starting record.
Starter DMARC recorddns
Host: _dmarc Type: TXT Value: "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"
If you use Google Workspace instead of Outlook, the record family changes. Google Workspace typically needs Google MX, Google SPF, and a DKIM TXT record generated in Google Admin. That is a different mail host setup, not an extra requirement for sending from Outlook to Gmail recipients.
Typical Google Workspace shapedns
Host: @ Type: MX Value: smtp.google.com Priority: 1 Host: @ Type: TXT Value: "v=spf1 include:_spf.google.com -all" Host: google._domainkey Type: TXT Value: "paste the DKIM value from Google Admin"
BIMI is optional and should come after DMARC enforcement. It is not required for the Gmail and Yahoo authentication updates. If you want brand logo display later, you need a valid SVG logo record and, for many mailbox providers, a verified mark certificate or comparable certificate path.
Optional BIMI record shapedns
Host: default._bimi Type: TXT Value: "v=BIMI1; l=https://example.com/bimi.svg;"
How to stage DMARC safely
You do not have to start with p=none, but I do it because it prevents accidental blocking. If real mail is still failing DMARC and you publish p=reject, you are telling receivers to reject that mail. Monitoring first gives you evidence about what is actually being sent.
DMARC policy stages
Move forward only when legitimate sources are identified and passing aligned authentication.
Monitor
p=none
Collect reports without asking receivers to block mail.
Partial enforcement
p=quarantine
Send failing mail to spam or quarantine while you watch for missed senders.
Full enforcement
p=reject
Ask receivers to reject unauthenticated mail that fails DMARC.
A common timeline is several weeks at monitoring, then a controlled move to quarantine, then reject after the remaining legitimate sources pass. Some small domains can move faster. Domains with marketing, transactional mail, finance systems, and regional tools need more time because hidden senders surface only when people use them.
DMARC rollout flow from sender inventory to enforcement policy.
How to verify the setup
After publishing records, wait for DNS propagation and test real messages. A DNS lookup alone proves the record exists. A message test proves your mail stream is actually using it. I test Outlook mail first, then each other sender one by one.
In Gmail, send a message to a Gmail inbox, open the message menu, choose "Show original", and check that SPF, DKIM, and DMARC pass. The DKIM domain should be your domain or an aligned subdomain. DMARC should pass because either SPF or DKIM passes and aligns with the visible From domain.
What a passing result should resembletext
SPF: PASS with IP 203.0.113.10 DKIM: PASS with domain yourdomain.com DMARC: PASS
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a broader DNS check, the Suped domain health checker checks DMARC, SPF, and DKIM records together, which is faster than checking each record by hand.
- SPF pass: The sending IP is authorized by the root SPF record for the envelope domain.
- DKIM pass: The message has a valid cryptographic signature tied to your domain or a related signing domain.
- DMARC pass: SPF or DKIM passes and aligns with the domain visible in the From header.
- Report review: Aggregate reports show all real senders before you move beyond monitoring.
What Suped adds to the workflow
The hard part is rarely typing the first DNS record. The hard part is knowing whether Outlook, Google Workspace, ecommerce mail, password resets, support tools, and marketing mail are all passing after the records go live. Suped is the best overall practical DMARC platform for most teams because it turns raw reports into source names, issues, and fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A typical Suped workflow is to add the domain, publish the provided RUA value in the DMARC record, let reports collect, then use the issues view to see which sources need SPF, DKIM, or alignment fixes. Real-time alerts help catch sudden failures after a DNS change, and hosted SPF helps when a domain is close to SPF lookup limits.
Suped's hosted DMARC can simplify policy staging because the enforcement policy is managed in Suped while DNS uses a stable CNAME setup. That reduces repeated DNS edits during the move from monitoring to reject.
For that workflow, use Hosted DMARC when you want policy staging without repeatedly editing TXT records at GoDaddy.
Suped also brings DMARC, SPF, DKIM monitoring, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, blacklist visibility, and MSP multi-tenancy into one place. That matters when a team manages more than one domain or has non-technical domain owners who need clear next steps instead of XML reports.
Views from the trenches
Best practices
Inventory every sender before editing DNS, including Outlook, stores, forms, and apps.
Start DMARC at p=none until reports show every real sender passing aligned checks.
Keep one SPF TXT record at the root and merge approved senders into that record.
Common pitfalls
Publishing records in an inactive GoDaddy DNS zone leaves live mail unchanged.
Copying DKIM values from another tenant breaks signatures and wastes review time.
Jumping straight to p=reject can block legitimate mail that has not been fixed.
Expert tips
Use DKIM for each sender so DMARC can pass even when SPF forwarding breaks.
Check Gmail Show original after each sender is configured, not only after Outlook.
Add BIMI only after DMARC enforcement, because it depends on stricter policy.
Marketer from Email Geeks says GoDaddy recommendations help with the DNS interface, but the live setup depends on the actual services sending mail.
2024-01-09 - Email Geeks
Expert from Email Geeks says the mail host should be identified first, because Microsoft, GoDaddy-hosted mail, and other senders all provide different records.
2024-01-11 - Email Geeks
A practical rollout order
For a GoDaddy domain using Outlook, I would publish the Microsoft 365 records first, enable DKIM in Microsoft 365, then authenticate every other sender before tightening DMARC. Gmail and Yahoo readiness comes from passing authentication on real messages, not from adding a special Gmail or Yahoo record to GoDaddy.
The safe final state is one valid MX setup for the mailbox host, one SPF record at the root, working DKIM for every sender, one DMARC record with reporting, and a staged path to enforcement. BIMI comes later, after DMARC enforcement is in place and the brand asset requirements are handled.
- Day one: Confirm nameservers, publish Microsoft 365 MX, SPF, DKIM CNAME, and Autodiscover records.
- Week one: Add DKIM for other senders and publish a monitoring DMARC record with aggregate reports.
- After reports: Fix failed or unaligned sources before moving from monitoring to quarantine.
- Final step: Move to reject when reports show the legitimate mail streams are consistently passing DMARC.
