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 20 Oct 2026
15 min read
Summarize with
Updated on 20 Oct 2026: We updated the setup steps for current sender requirements, DKIM activation, and a controlled Microsoft 365 mail cutover.
Publish records at the domain's active DNS host, which is GoDaddy only when it hosts your DNS zone. Outlook is an email client; Microsoft 365 is the mail host in the setup below. Publish the assigned MX, SPF, DKIM CNAME, and Autodiscover records, enable DKIM signing, authenticate every other sender, then publish one DMARC TXT record at _dmarc. Start DMARC at p=none, review reports, then move to p=quarantine and p=reject when legitimate mail consistently passes DMARC.
Each sending platform provides its own DKIM values. Microsoft 365, Google Workspace, and platforms that send automated or marketing email each provide records for your domain. Publish those records in GoDaddy when it hosts the active DNS zone.
For ongoing visibility, Suped's DMARC monitoring shows authentication results and sources that need fixes, providing evidence for deciding when to tighten policy.
Set up email authentication in GoDaddy
Start by separating the jobs involved. GoDaddy holds the DNS zone if your nameservers point there. Microsoft 365 handles mailbox delivery for the Outlook account used in this setup. Gmail and Yahoo evaluate the mail you send to their users. Your other senders, such as ecommerce 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.
- Choose the setup method: Use Domain Connect for a new Microsoft 365 setup, or use manual setup when you need to control verification and the MX cutover.
- Add Microsoft 365 records: Use the admin center values for verification, MX, SPF, and Autodiscover, and the Microsoft 365 DKIM page for both selector CNAMEs. The Microsoft GoDaddy DNS records page explains both setup methods.
- 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 at _dmarc for the organizational domain. Review any existing subdomain policies too, then monitor before enforcing policy.
- Verify with real mail: Send messages through Microsoft 365 and every other sender, then check SPF, DKIM, and DMARC results, including DMARC alignment with your visible From domain.
Do not copy DKIM targets from another domain. Microsoft assigns the CNAME targets for your domain and tenant; selector names alone do not identify the correct targets. Each sender must provide the records for the exact domain you are authenticating.
GoDaddy DNS Management with Microsoft 365 MX, SPF, DKIM, DMARC, and Autodiscover records.
Verify the domain and plan the MX cutover
Before replacing MX records, verify domain ownership and prepare the receiving mailboxes. The verification TXT record proves ownership; MX routes incoming mail, and Autodiscover configures email clients. Neither MX nor Autodiscover authenticates outgoing messages.
- In the Microsoft 365 admin center, open Settings > Domains, select your domain, and copy its verification TXT value beginning MS=ms.
- In GoDaddy, open Domain Portfolio > your domain > DNS > Add New Record. Choose TXT, enter @ as the name, paste the exact verification value, use a one-hour TTL, and save. Return to Microsoft 365 and select Verify. This TXT record can coexist with SPF.
- Create the required mailboxes, aliases, and groups before switching MX. Retain the old service while cached MX records expire.
- At cutover, publish the assigned MX target and priority, and remove obsolete MX routes. Keep old SPF authorizations until those systems stop sending. Run the domain health check in Microsoft 365, then test external sending and receiving.
Gmail, Yahoo, and Outlook.com sender requirements
The setup changes depending on who sends mail for the domain. Gmail and Yahoo do not issue special DNS records for domains that only send to their users. All senders need SPF or DKIM; bulk senders also need both methods and DMARC. These requirements are already enforced. The specific sender rules are covered separately in the Gmail and Yahoo requirements article.
Gmail requires SPF or DKIM for all senders. Treat about 5,000 messages or more to personal Gmail accounts in 24 hours as the bulk threshold, counting the primary domain and its subdomains together. Bulk senders need SPF and DKIM, a DMARC policy of at least p=none, and DMARC alignment with either authenticated domain. Once classified as a bulk sender, a domain keeps that status. See Google's sender guidelines and bulk sender FAQ.
Yahoo's bulk senders also need SPF and DKIM plus a DMARC policy of at least p=none, and messages must pass DMARC. Yahoo does not publish a numerical bulk threshold. Both providers require valid forward and reverse DNS and spam complaint rates below 0.3%; Google recommends staying below 0.1%. For applicable bulk marketing or subscribed mail, include a visible unsubscribe link and working unsubscribe headers, and honor requests within two days. Gmail requires RFC 8058 one-click unsubscribe, which a body link alone does not satisfy. See Yahoo's sender requirements and bulk sender classification.
Outlook.com also enforces bulk sender authentication. Microsoft identifies senders of 5,000 or more messages using the same From domain to its consumer services as high volume. These senders need both SPF and DKIM to pass, a DMARC record with at least p=none, and a DMARC pass. Failures can produce 550 5.7.515. This applies to receiving services such as Outlook.com and Hotmail, regardless of the sender's mail host. See Microsoft's Outlook.com authentication requirements.
Gmail also requires TLS for message transmission. With Microsoft 365 or Google Workspace, the sending provider manages TLS and sending-IP reverse DNS. For a self-managed mail server, request the PTR record from the IP address provider and ensure the hostname resolves back to that IP; a TXT record in GoDaddy cannot configure reverse DNS.
|
|
|
|---|---|---|
DNS host | Publishes TXT, CNAME, MX | |
Mailbox host | MX, SPF, DKIM, Autodiscover | |
Receiver / mailbox host | Gmail checks / Workspace MX, SPF, DKIM | |
Receiver | Checks SPF, DKIM, DMARC | |
Other senders | Mail source | Usually DKIM, sometimes SPF |
Publish the exact record values supplied by your mail host and each sending platform.
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 because GoDaddy appends the domain.
- Keep one SPF: Publish one SPF TXT record per sending hostname. The root domain and a custom Return-Path subdomain can each have their own SPF record.
SPF, DKIM, and DMARC records to publish
For a GoDaddy DNS zone using Microsoft 365 mailboxes, publish the values assigned to your domain. Direct Microsoft 365 subscriptions commonly use include:spf.protection.outlook.com for SPF, while GoDaddy-managed Microsoft 365 plans can use include:secureserver.net. Copy the value assigned to the domain instead of replacing a working SPF record with a generic example. The MX priority and both DKIM targets below are examples, not values to copy unchanged.
Typical direct Microsoft 365 records in GoDaddydns
Host: @ Type: MX Value: yourdomain-com.mail.protection.outlook.com Priority: 10 TTL: 1 hour Host: @ Type: TXT Value: "v=spf1 include:spf.protection.outlook.com -all" TTL: 1 hour Host: selector1._domainkey Type: CNAME Value: selector1-yourdomain-com._domainkey.tenantprefix.x-v1.dkim.mail.microsoft TTL: 1 hour Host: selector2._domainkey Type: CNAME Value: selector2-yourdomain-com._domainkey.tenantprefix.x-v1.dkim.mail.microsoft TTL: 1 hour Host: autodiscover Type: CNAME Value: autodiscover.outlook.com TTL: 1 hour
The DKIM targets above illustrate the format introduced for new Microsoft 365 custom domains in May 2025. Microsoft assigns the tenant prefix and dynamic partition character. Copy both exact CNAME targets from the DKIM page. Existing domains can retain their earlier onmicrosoft.com targets; working records do not need replacement merely because a newer format exists.
After both CNAMEs resolve, return to your domain on the Microsoft 365 DKIM page and enable "Sign messages for this domain with DKIM signatures". Confirm that the status shows signing is enabled. Publishing CNAMEs alone does not turn on custom-domain signing. See Microsoft's DKIM setup instructions.
SPF authorizes sending servers for the envelope sender domain, usually shown in Return-Path, rather than automatically authenticating the visible From domain. Add a platform to the SPF record for the envelope domain it actually uses. If it uses its own Return-Path domain, adding it to your root SPF record does not change that SPF check. Configure DKIM with your domain too. SPF permits at most 10 DNS-querying terms per evaluation, including nested includes; this is not a limit on all DNS queries. See RFC 7208.
Publish only one SPF TXT record at each sending hostname. At the root, that hostname is @. Merge authorized sources that use the same envelope domain into that record. Multiple SPF records at one hostname cause permerror. A separate Return-Path subdomain can have its own SPF record, and TXT records used for verification can coexist with SPF.
The DMARC record requests receiver handling when neither SPF nor DKIM passes with a domain that matches the visible From domain under DMARC alignment rules. With default relaxed alignment, a shared organizational domain is sufficient; strict mode requires an exact domain match. For a first rollout, publish a monitoring record and request aggregate reports using rua. Replace reports@yourdomain.com below with a working reporting destination. Suped provides 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 the rua address is outside your organizational domain, the reporting destination must authorize external reports in its DNS. Use the exact destination Suped provides and verify its reporting authorization. Some receivers do not send reports, so reports cover observed traffic rather than a complete sender inventory. See RFC 9990.
If Google Workspace hosts your mailboxes, use the Google MX and SPF values plus a DKIM TXT record generated in Google Admin. Activate Gmail for the domain in Google Admin after setting MX. Generate a 2048-bit DKIM key, publish its selector record in GoDaddy, then select Start authentication in Google Admin. This setup applies to Workspace sending, even when Outlook is the email client. Existing working legacy Google MX records remain supported; do not replace them solely to match the smtp.google.com example. See Google's MX instructions and Google's DKIM instructions.
Google Workspace examples, using the default google selectordns
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, an eligible mark certificate.
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 monitoring first reduces the risk of rejecting legitimate mail through your DMARC policy. Receivers still apply their own filtering. If legitimate mail is still failing DMARC and you publish p=reject, you are telling receivers to reject that mail. Monitoring gives you evidence about what is actually being sent.
DMARC policy stages
Move forward when legitimate sources are identified and consistently pass DMARC.
Monitor
p=none
Request no DMARC enforcement while reviewing aggregate reports.
Quarantine
p=quarantine
Ask receivers to treat messages that fail DMARC as suspicious.
Reject
p=reject
Ask receivers to reject messages that fail DMARC, including failures caused by a domain mismatch.
Monitor through a representative sending cycle, including infrequent business mail, then move to quarantine and reject after legitimate sources consistently pass. Sender readiness determines the timing. RFC 9989 removed the legacy pct tag, so do not rely on percentage-based enforcement when staging policy changes.
DMARC rollout for GoDaddy and Microsoft 365, from sender inventory through enforcement.
How to verify the setup
After publishing records, allow for DNS caching and test real messages. A DNS lookup proves the record is published. A message header proves the mail stream is actually using it. Test Outlook mail first, then each other sender separately.
Send a message from each configured sender to a Gmail recipient. Open the message menu, choose "Show original", and inspect Authentication-Results for spf=pass, dkim=pass, and dmarc=pass. Compare smtp.mailfrom for SPF and header.d for DKIM with header.from. DMARC needs at least one passing method to match the From domain under its alignment rules, even though bulk sender rules require both methods to pass.
What a passing result should resembletext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a broader DNS check, Suped's domain health checker checks authentication DNS configuration. Use the recipient's Authentication-Results headers to confirm actual signing and DMARC alignment. A passing result does not guarantee inbox placement.
- SPF pass: The sending IP is authorized by the SPF record for the envelope domain.
- DKIM pass: A signature verifies for its signing domain. A valid signature using only a provider's unrelated domain does not establish DMARC alignment for your From domain.
- DMARC pass: SPF or DKIM passes with a domain that matches the visible From domain under the applicable DMARC alignment rules.
- Report review: Aggregate reports identify legitimate and unknown sources before you move beyond monitoring.
Troubleshooting common DNS failures
When mail still fails after a DNS change, first determine whether the problem affects inbound routing, outbound authentication, or DMARC alignment. That distinction narrows the records to inspect and avoids unnecessary changes.
|
|
|
|---|---|---|
Mail is not received | Missing or incorrect MX target, obsolete routing, or a missing recipient mailbox | Copy the host's assigned MX target exactly, verify the recipient mailbox exists, and remove obsolete routes at cutover. Lower MX numbers have higher preference. |
Records are not visible | Edited an inactive DNS zone or cached data remains | Confirm authoritative nameservers, then allow for the record TTL and resolver caching. |
SPF shows permerror | Multiple SPF records at one hostname or more than 10 DNS-querying terms | Merge authorized senders into one record and reduce unnecessary lookup mechanisms. |
Microsoft DKIM stays disabled | Incorrect CNAME target or hostname, a missing selector, or signing not enabled | Publish both exact targets under the short GoDaddy selector names, then enable DKIM and check the signing status in Microsoft 365. |
DMARC fails despite SPF pass | SPF passes for an unrelated envelope domain and no matching DKIM signature passes | Configure a custom Return-Path domain or DKIM signing domain that matches the visible From domain under DMARC rules. |
No aggregate reports arrive | Missing or incorrect rua destination, missing external authorization, or no reporting traffic | Check the published rua address and destination authorization, confirm traffic reached a reporting receiver, and allow at least 24-48 hours for initial reports. |
Check the active DNS zone and provider-generated values before replacing records.
Do not treat every delay as propagation. If the authoritative nameservers return the wrong value, waiting will not fix it. If they return the new value but a recursive resolver returns the old value, wait for the cached TTL to expire.
What Suped adds to the workflow
The hard part is knowing whether Microsoft 365 and every automated sender pass after the records go live. Suped turns DMARC aggregate reports into source names, authentication results, and fix steps so a team can trace reported failures before enforcing policy.
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 destination in the DMARC record, let reports collect, then use the issues view to identify sources needing authentication fixes. Review reported failures after each DNS or sender change before tightening policy.
Suped's hosted DMARC keeps a stable DNS CNAME while policy changes are managed in Suped. This reduces repeated GoDaddy edits during the move from monitoring to reject. When using hosted DMARC, replace the existing _dmarc TXT record with the provided CNAME; do not publish both record types at the same name.
Use Hosted DMARC when the team wants controlled policy staging without changing the DMARC TXT value at each step.
For teams managing multiple domains, Suped keeps reported authentication issues and remediation steps together so each domain can be reviewed before its DMARC policy changes.
Views from the trenches
Best practices
Inventory every sender before editing DNS, including Microsoft 365 and automated email systems.
Start DMARC at p=none until reports show legitimate senders consistently passing DMARC.
Keep one SPF TXT record per sending hostname, with authorized sources in that record.
Common pitfalls
Publishing records in an inactive GoDaddy DNS zone leaves the public DNS records unchanged.
Copying another tenant's DKIM CNAME targets prevents verification of legitimate signed mail.
Moving to p=reject before fixing legitimate senders risks rejection of their business email.
Expert tips
Use DKIM for each sender so unmodified forwarded mail can pass DMARC when SPF fails.
Check Gmail's Show original after configuring each sender, then review its DMARC result.
Add BIMI after DMARC enforcement, once authentication and logo requirements are satisfied.
Marketer view
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 view
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 DNS zone using Microsoft 365 mailboxes, verify ownership and prepare recipients before the MX cutover, enable DKIM in Microsoft 365, then authenticate every other sender before tightening DMARC. Gmail and Yahoo readiness depends on authentication results from real messages.
- Prepare and connect: Confirm nameservers, verify domain ownership, prepare recipient mailboxes, then publish the assigned Microsoft 365 records at the planned MX cutover.
- Authenticate and monitor: Enable DKIM for Microsoft 365 and other senders, then publish a monitoring DMARC record with a working aggregate reporting destination.
- After reports: Fix legitimate sources that fail DMARC before moving to quarantine; include infrequent business mail in the review.
- Final step: Move to reject when reports show the legitimate mail streams are consistently passing DMARC.
Frequently asked questions
No. When Gmail and Yahoo only receive your mail, publish records supplied by your actual sending platforms. Both require SPF or DKIM for all senders. Bulk senders need both methods plus a DMARC policy of at least p=none, and messages must pass DMARC using a matching authenticated domain. DMARC is recommended for smaller senders too.
Start with p=none unless you have already verified every legitimate sender. Moving straight to reject can block real mail that fails DMARC because a sender has not been authenticated yet.
Use one SPF TXT record per hostname, merging authorized sources that use that envelope domain. A root domain and a separate Return-Path subdomain can each have one SPF record. Multiple SPF records at the same hostname cause permerror; that does not force DMARC to fail when a matching DKIM signature passes. Stay within 10 DNS-querying terms, including nested includes.
No. BIMI is optional. Handle SPF, DKIM, DMARC, and sender alignment first, then consider BIMI after DMARC enforcement is stable.
Get both exact selector CNAME targets from the Microsoft 365 DKIM page for your tenant and domain, publish them at the active DNS host, then enable DKIM signing. New custom domains use the dkim.mail.microsoft format introduced in May 2025; working older onmicrosoft.com targets remain valid.
