How to Add an MX Record (GoDaddy, 365, Google Workspace)

Email not landing? Sales reps missing demos because confirmation emails bounce? Nine times out of ten, your DNS is misconfigured - and the first thing to fix is your MX record. Here’s the plain-English, operator-grade guide to adding MX records (with GoDaddy examples), setting priority/TTL, verifying the change, and hardening deliverability with SPF, DKIM, and DMARC.

MX stands for Mail Exchanger. This DNS record tells the internet which mail server is authorized to receive email for your domain. When someone sends sales@yourcompany.com an email, their mail server checks DNS for your MX record and routes the message to that destination. If the MX is wrong or missing, mail bounces or disappears into a void. No pipeline, no revenue.

For business owners and marketing leaders, MX is not an IT trivia question - it’s the difference between campaign results showing up or silently failing. If you’ve migrated email providers, launched a new domain, or changed DNS hosts, you must confirm the MX is clean and authoritative.

Good MX setup is also foundational for deliverability work. Even perfect SPF/DKIM/DMARC won’t save you if mail can’t find your inbox. Think of MX as the street address; SPF/DKIM/DMARC are the ID badges and locks.

Every MX record has four concepts you need to set correctly:

Host (or Name): Usually @ for the root domain (yourcompany.com). Some providers let you add MX for a subdomain (e.g., support.yourcompany.com). Keep it simple: most business email uses @.

Points to (or Value): The fully qualified domain name (FQDN) of your email provider’s inbound server. Examples: a Google Workspace host like ASPMX.L.GOOGLE.COM or a Microsoft 365 host like your-tenant.mail.protection.outlook.com. Don’t guess - copy from your provider’s admin panel.

Priority (Preference): A number where lower is higher priority. Mail servers try the lowest number first, then fall back. If you have one MX, set a low number (e.g., 0 or 10). If multiple, follow the provider’s exact priorities.

TTL (Time To Live): How long resolvers can cache this record. If you’re mid-migration, use a shorter TTL (5–30 minutes) so changes propagate faster. Otherwise, 1 hour is fine.

Your DNS host (e.g., GoDaddy, Cloudflare, Route 53) is where you add MX. Your email provider (e.g., Google Workspace, Microsoft 365, Zoho, Fastmail) tells you the exact MX entries and priorities to add. These are two separate systems. Get the MX list and priority from your email provider first.

Where to find values:

Google Workspace: Admin Console → Domains → Manage domains → Set up Google MX records. You’ll see multiple MX hosts (ASPMX and ALT entries) with specified priorities. Add them exactly as shown.

Microsoft 365: Microsoft 365 admin center → Setup → Domains → DNS records. You’ll see an MX value unique to your tenant (ends with mail.protection.outlook.com) and a recommended priority.

Other providers: Use their onboarding docs or admin page. If they provide more than one MX, add all of them with the given priorities.

GoDaddy is a common DNS host for SMB and mid-market. Here’s the operator version of the process - simple, accurate, and reversible.

1) Log in to your GoDaddy account and open My Products. Under Domains, find your domain and click DNS (or Manage DNS).

2) In the DNS Management page, locate the Records table. Click Add to create a new record. Choose MX from the Type dropdown.

3) Fill the fields exactly:

- Host: @ (unless you are intentionally setting a subdomain mailbox).
- Points to: Paste the MX host from your provider (e.g., ASPMX.L.GOOGLE.COM).
- Priority: Use the number from your provider (lower = higher priority).
- TTL: Start with 1 hour; use 10–30 minutes if you’re actively migrating and will need to switch fast.

4) If your provider lists multiple MX records, click Add again for each additional MX with the specified “Points to” and “Priority”. Don’t improvise priorities; copy exactly.

5) Remove conflicts. If you previously used another provider, you may see old MX records still present. Delete any MX entries that do not belong to your current provider. Leaving multiple, conflicting MX sets can cause random delivery failures.

6) Save changes. GoDaddy applies them immediately, but global propagation can take minutes to hours depending on TTL and caching.

Cloudflare: Go to your domain → DNS → Records → Add record → Type MX. Host is typically @. Paste the provider’s MX host as Content. Set Priority and TTL (Auto is fine unless migrating). Note: Cloudflare does not proxy MX (no orange cloud for MX). Ensure any A/CNAME records referenced by your MX target are not improperly proxied if your provider requires direct access.

Namecheap: Domain List → Manage → Advanced DNS → Add New Record → MX Record. Host is usually @. Mail Server is the MX host. Priority as specified. TTL default or reduced during migration. Remove legacy MX from previous providers.

Amazon Route 53: Hosted zones → your domain → Create record → Choose Simple routing → Define simple record → Record name (leave blank for root, equals @) → Record type MX → Value format “priority host.” Example: “10 ASPMX.L.GOOGLE.COM.” Repeat per MX. Set TTL.

Most enterprise-grade email providers give you several MX entries. This is not optional redundancy; it’s part of how their infrastructure balances load and provides failover. Always add the full set with the exact priorities they provide.

How priority works: A sending server tries the lowest number (highest priority) first. If it times out, it tries the next lowest priority. If you only add one MX from a multi-entry list, you’re reducing resilience and inviting sporadic delivery failures.

Custom mail servers: If you run your own mail server, set your primary MX to your server’s FQDN and publish a backup MX (if you have a secondary server). Keep the backup priority higher (larger number). If you don’t run a secondary, don’t add a backup MX pointing to a host that can’t accept mail - that causes silent black holes.

Don’t rely on “it should work now.” Verify. Two quick methods from any machine:

Terminal commands:

- nslookup -type=mx yourcompany.com
- dig +short MX yourcompany.com

You should see each MX host with the priority you set. If you still see old MX entries, wait for TTL or check if you edited the correct DNS zone (common mistake when your domain’s nameservers point elsewhere).

Send test mail from an external account. Send to a mailbox at your domain from Gmail/Outlook, then reply. Confirm both directions are clean. Watch for bounce messages - they tell you whether routing or authentication failed.

MX gets mail to your inbox. SPF, DKIM, and DMARC keep your mail out of spam and protect your brand from spoofing. After you set MX, complete this trio:

SPF (TXT record): Lists who can send mail as your domain. Start with one record that includes your provider (e.g., include:_spf.google.com for Google, or the directive given by Microsoft 365). Only one SPF record per domain - merge if needed. Keep mechanisms lean to avoid DNS lookup limits (10 max).

DKIM (CNAME or TXT depending on provider): Cryptographic signature added by your outbound mail server. Your provider will give you selector records to publish. Enable DKIM signing in the provider’s admin console once DNS is live.

DMARC (TXT record at _dmarc.yourcompany.com): Policy for how receivers should treat messages that fail SPF/DKIM alignment. Start with p=none and rua/ruf reporting addresses. Review reports, fix authentication gaps, then move to p=quarantine and eventually p=reject when confident.

Conflicting MX sets: Don’t mix old and new provider MX entries. Delete what you don’t use. Mixed sets cause random failures.

Wrong host field: Use @ for the root domain, not your MX host name. The MX record’s “Points to” should be the provider’s server, not an IP address. MX must point to a hostname.

CNAME at apex: If your DNS host allows a true CNAME at the root (apex), you can’t have other records at the same name per RFC. Many modern DNS providers offer ALIAS/ANAME to emulate CNAME-at-apex safely. If your apex is a CNAME, replace it with ALIAS/ANAME or A records so you can publish MX.

Cloudflare orange cloud on MX target: Cloudflare won’t proxy MX records themselves, but if the hostname your MX points to is on a zone you control and is proxied, that can create issues. Generally, leave provider-issued MX hosts alone; don’t proxy them.

SPF duplication: One domain, one SPF TXT record. If you need multiple senders (e.g., Microsoft 365 plus a marketing ESP), merge mechanisms into a single record.

When moving from one provider to another (e.g., from legacy cPanel to Microsoft 365), plan your cutover to avoid missed emails.

1) Lower TTL ahead of time. 24–48 hours before cutover, change your MX TTL to 5–15 minutes. This ensures a quick switch when you’re ready.

2) Prepare mailboxes and aliases at the new provider. Create users, groups, and forwarders to match your current setup. Migrate historical mail with the provider’s migration tool if needed.

3) Add new MX (do not delete old yet). Publish the new provider’s MX records alongside the old for a brief overlap if both can accept mail. Validate delivery to a test mailbox on the new provider.

4) Cut over by removing old MX. Once verified, delete the old provider’s MX. With a lowered TTL, most senders will honor the change quickly.

5) Monitor. Watch inbound mail volumes, bounce logs, and DMARC reports for 48–72 hours. Raise TTL back to normal after stability is confirmed.

Past the basics, think like an operator. Redundancy is free when you follow your provider’s full MX set. Skipping secondary MX entries is like paying for insurance but not adding the beneficiary - it defeats the point.

Coordinate records across environments. If you use subdomains for tools (e.g., support.yourcompany.com with a helpdesk), ensure MX at that subdomain is correct or deliberately absent, depending on the app’s inbound processing.

Don’t forget TLS and policy layers. While MX routes mail, transport security and policy visibility matter. Consider enabling MTA-STS and TLS-RPT if your provider supports them, so sending servers know to enforce TLS in transit and report issues.

If you have an internal IT lead or DevOps function, they typically own DNS. Marketing should still have line of sight - because every go-to-market motion relies on email (inbound confirmations, outbound replies, nurture, billing). At minimum, document where DNS is hosted, who has access, and the current provider MX values.

Avoid vendor sprawl. Your CRM, marketing automation, and outbound tools might all want to send as your domain. Centralize SPF/DKIM management, and use subdomains for third-party senders where sensible (e.g., mail.yourcompany.com for a marketing ESP). This reduces risk to your primary domain’s reputation.

Build simple runbooks. A one-page checklist for “New mailbox,” “Provider migration,” and “DNS change” prevents finger-pointing when something breaks during a launch.

When DNS and email intersect with CRM, outbound infrastructure, and tracking, you need someone who both writes the plan and ships the config. That’s the operator model - not a slide deck. At Anton Chisliuk · AI Marketing Ops, a single senior operator runs the build: MX/SPF/DKIM/DMARC, CRM routing, and automation - the unglamorous plumbing that keeps revenue moving. Proof matters: for Cleverence (B2B SaaS), we went 0→80K organic visits/month and 0→2K inbound leads/month. If you want to understand the operator approach without a sales pitch, read the short overview on our about page.

DMARC enforcement: After you stabilize SPF/DKIM, move from p=none to p=quarantine and then p=reject. Use rua aggregate reports to spot senders you forgot to include in SPF/DKIM. Don’t rush enforcement until you see alignment is consistently passing.

BIMI (optional): If you’re pushing brand presence in inboxes, publish BIMI once DMARC is at enforcement. It won’t fix deliverability, but it can improve recognition. Some mailbox providers have additional verification requirements.

Compartmentalize risk with subdomains: Send bulk marketing from a subdomain with its own SPF/DKIM/DMARC policy (e.g., news.yourcompany.com). Keep transactional and corporate mail pristine on the apex domain.

Symptom: Messages bounce with “no such user” or “recipient not found.” Cause: Mailbox not created at destination provider or alias not replicated. Fix: Create/verify the mailbox and aliases before cutover.

Symptom: Random delivery failures. Cause: Mixed MX records (old + new) or wrong priorities. Fix: Remove legacy MX and re-check priorities. Verify with dig/nslookup.

Symptom: Mail lands but replies go to spam. Cause: Outbound authentication not set. Fix: Publish SPF, enable DKIM, configure DMARC, and align sender domains.

Symptom: Changes don’t show up. Cause: Wrong DNS host edited (registrar versus authoritative nameservers) or high TTL. Fix: Confirm authoritative nameservers and edit the active zone. Lower TTL and retry.

Nameservers matter. If your domain at GoDaddy points to third-party nameservers (e.g., Cloudflare), editing DNS in GoDaddy won’t do anything. Update the zone where your nameservers point.

Priority format: GoDaddy accepts numeric priorities (0, 1, 5, 10, etc.). Don’t add multiple MX records with the same host and identical priority unless your provider explicitly instructs it.

Record limits and duplicates: Keep exactly the MX set your provider lists. Remove stale MX records after a migration. Too many entries with conflicting priorities lead to unpredictable routing.

- Confirm your email provider and copy exact MX entries and priorities from its admin panel.
- Log into your DNS host (GoDaddy or other) and add MX for host @ with the correct values.
- Add all MX entries the provider lists; match priorities exactly.

- Remove old/conflicting MX entries from previous providers.
- Set a short TTL during migration; restore to 1 hour when stable.
- Verify with nslookup/dig and by sending real test mail.

- Configure SPF, enable DKIM, publish DMARC p=none; review reports; move to enforcement later.
- Document access, records, and a rollback plan.

DIY if you’re comfortable in DNS dashboards, understand TXT/SPF syntax, and have a clear migration window. This is a focused task with known steps. The cost of getting it wrong, however, is missed revenue signals and blown SLAs.

Bring in help if you’re juggling CRM routing, multiple senders (sales engagement tools, ESPs), or a provider migration with no downtime tolerance. That’s where an operator shines: set MX, align SPF/DKIM/DMARC, route inbound to the right team inboxes, and validate end-to-end.

If you’re comparing traditional agencies to an operator model for build work like this, read our short note on agency overhead versus accountable execution on the agency vs operator page.

If you suspect MX or authentication drift, request a quick audit. We review DNS, MX, SPF/DKIM/DMARC, and real delivery paths, then give you a prioritized fix list. No fluff - just what to change and why. Book a short, practical Growth Audit.

MX records are simple in theory and costly when neglected. Add the right MX entries, set priorities, remove conflicts, verify, and then harden with SPF/DKIM/DMARC. That’s the reliable path to inbox delivery - and to seeing the real impact of your marketing and sales programs.

If you want a single accountable builder to fix the plumbing and connect it to pipeline - MX to CRM to automation - book a practical Growth Audit. Leads, sales, content, and systems - one senior operator.

Author: Anton Chisliuk

- How long do MX changes take to propagate?

Most changes show up within minutes, but global propagation can take up to 24–48 hours depending on TTL and caching. Lower TTL (e.g., 10–30 minutes) before a planned cutover, then raise it back after stability.

- Do I need multiple MX records?

If your provider lists multiple MX entries, add all of them with the given priorities. It’s built-in redundancy and load balancing. If you run a single custom mail server, you may have only one MX - but ensure it’s reliable.

- Can I use an IP address as the MX target?

No. MX must point to a hostname (FQDN), not an IP address. The hostname should resolve to one or more IPs so providers can manage failover and scaling.

- My domain’s apex is a CNAME. Why can’t I add MX?

Per DNS standards, a name with a CNAME cannot have other records. Use an ALIAS/ANAME (if your DNS supports it) or switch to A/AAAA records at the apex so you can publish MX, TXT (SPF/DMARC), etc.

- What should my MX priority numbers be?

Exactly what your provider specifies. Lower numbers have higher priority. Don’t invent values or normalize them. Copy-paste from the provider’s admin instructions.

- Will MX records fix my spam problem?

MX ensures messages reach your mail server. Spam placement is an authentication and reputation issue. Configure SPF, DKIM, and DMARC, keep lists clean, and send relevant mail at reasonable volume.

- How do I know which DNS host to edit?

Check your domain’s authoritative nameservers at your registrar. Edit DNS where those nameservers live. If your nameservers point to Cloudflare, editing records at GoDaddy will have no effect.