MX Records on Dedicated Domains for Cold Email

Each outbound domain is its own mail domain. It does not inherit MX from your primary company domain. If brandmail.com is the cold domain, brandmail.com needs MX that points to Google Workspace for that domain. Leaving registrar parking MX in place, or pointing at an old host, is one of the most common setup failures.

Primary domain isolation still applies: cold campaigns belong on dedicated domains, not on the apex domain that carries invoices and customer mail. See Primary Domain Isolation for Cold Email.

Always confirm current values on Google's help pages before you publish records. As of the research pass used in earlier ColdMail drafts, Google's MX setup guidance for new setups describes a single MX record pointing to smtp.google.com with priority 1. Remove other MX records for that domain. Google notes recognition can take up to 72 hours. Older organizations may still use legacy values that begin with aspmx; Google still documents support for those. If your Admin console shows specific values, follow those for that organization.

Recheck Google's MX help and the values shown in your Admin console before you publish records; Google's pages are the source of truth.

A practical order for a new dedicated domain:

1. Register or accept the domain in an account you control.
2. Add the domain in Google Workspace (as its own organization or as a secondary domain, depending on how you separate clients).
3. Verify ownership with Google's TXT verification flow.
4. Publish MX to Google and remove parking or prior host MX.
5. Publish SPF and DKIM, then DMARC.
6. Create mailboxes, enforce 2FA, warm up, then connect to your sequencer.

MX early matters because receiving must work before you trust reply based monitoring. Sending authentication still depends on SPF, DKIM, and DMARC. MX alone does not make cold email land in the inbox.

1. Open DNS for the dedicated domain at your DNS host.
2. Delete MX records that point at parking pages, old hosts, or email forwarders you do not intend to use.
3. Add the MX record Google documents for your setup (commonly smtp.google.com priority 1 on new setups).
4. Save and wait for propagation. Plan for delay; Google cites up to 72 hours for recognition in its MX help.
5. In Google Admin, confirm the domain's MX status when the console surfaces it.
6. Send a test to the domain and reply to it so you prove receiving works.

Exact DNS UIs differ. The outcome you want is stable: only the intended Google MX remains.

Receivers use the full picture. A perfect MX with failing DKIM is not "done." Google's sender guidelines expect authenticated mail. Walk SPF, DKIM, and DMARC in the sibling guide rather than inventing values here.

• Leftover parking MX from the registrar default.
• Mixing hosts: one MX to Google and one to an old provider "just in case."
• Publishing MX on the wrong domain (primary instead of the dedicated outbound domain, or a subdomain you did not verify).
• Assuming website redirect replaces MX. A URL redirect to your main site is not mail routing.
• Starting warmup before MX and auth pass. You will train history on a broken domain.
• Inventing tracking records as MX. Click tracking uses DNS your sequencer documents (often a CNAME). That is separate. Do not put tracking targets in MX.

• Query MX for the domain with a DNS lookup tool and confirm only the intended Google hosts appear.
• Send mail to a mailbox on that domain from an external account and confirm delivery.
• On outbound tests, use Show original on the receiving side for SPF, DKIM, and DMARC (those are send checks; MX is confirmed by receiving).
• In Google Admin, use whatever MX validation the console offers for the domain.

If lookup still shows a parking host after several hours, you edited the wrong DNS zone or the change did not publish.

Agencies and larger teams repeat this pattern per outbound domain. Automation helps, but visibility still matters: you should be able to open DNS and see MX yourself. When many domains share one unchecked template error, every domain fails the same way. Density planning (two or three mailboxes per domain) sits on top of correct MX, it does not replace it. See How Many Mailboxes Per Domain for Cold Email.

Once MX and the rest of auth pass, create mailboxes and connect them in Instantly or Smartlead using the methods those tools support (OAuth or IMAP/SMTP with app passwords). n8n and similar tools follow the same idea. MX does not replace app passwords, OAuth consent, or per mailbox caps.

ColdMail provisions official Google Workspace on dedicated domains and publishes SPF, DKIM, DMARC, and MX automatically, so you are not copying MX values between tabs for every domain. You still get an official admin panel per domain with 2FA, and the records remain yours to inspect. AI warmup is available as an optional add on; see coldmail.app for current add on pricing. Mailboxes are ready to connect in Instantly and Smartlead using the methods those tools support.

Correct MX is necessary and not sufficient. ColdMail removes repetition; it does not claim MX alone fixes placement.

Set up your mailboxes at coldmail.app, or Book a Strategy Call if you are rebuilding DNS across many dedicated domains.