Set up business email DNS without mixing receiving and sending records.

Collect the current records before changing DNS

Open the authoritative DNS provider for the domain and copy the current TXT, MX, CNAME, and mail-related records. EmailDesk can show the required values, but a registrar or external DNS host may remain the place where they must be published.

Decide whether EmailDesk will receive mail for the domain, send mail for it, or do both. An outbound-only domain does not need its inbound MX changed merely to authorize sending.

• Record existing MX priorities and targets before replacing them.
• Keep the current SPF value so its legitimate senders can be merged into one policy.
• Confirm which EmailDesk sending gateway is active before copying SPF or DKIM values.
• Use the exact host names and values shown for the customer domain; do not reuse another domain's verification record.

Publish ownership TXT and inbound MX for their separate roles

The EmailDesk ownership TXT token proves that the customer controls the domain. It does not route mail and it does not authenticate a particular From address.

MX records tell other mail systems where to deliver inbound messages. Change MX only when EmailDesk should receive mail for the domain, and preserve the priorities shown in the EmailDesk domain requirements.

• Ownership TXT: required before EmailDesk can activate a managed receiving domain.
• MX: required for EmailDesk-hosted inbound delivery, not for an outbound-only sender domain.
• Mailbox activation: also depends on the EmailDesk mail host and domain service being ready; public DNS alone is not the whole activation state.

Add SPF, DKIM, and DMARC for outbound identity

SPF authorizes the systems that may send for the envelope domain. EmailDesk checks the include required by the selected gateway. MailChannels sending currently requires include:relay.mailchannels.net.

DKIM uses a selector and public key issued by the active sending provider. DMARC evaluates aligned SPF or DKIM results and applies the domain policy. Start with a monitoring policy only when that matches the organization's rollout plan, then tighten it after legitimate sending sources are known.

• Publish one SPF record, merging every legitimate sender into it.
• Copy the provider-issued DKIM selector and value exactly.
• Use a DMARC reporting mailbox that the organization can review.
• Verify the exact From email in EmailDesk; domain DNS does not replace that permission check.

Wait for propagation, then verify each layer

DNS changes can be visible at different times from different resolvers. Wait for the provider's TTL and propagation window, then run the EmailDesk domain check again before sending a controlled test.

Review the ownership, MX, SPF, sender identity, DKIM, and DMARC evidence separately. A green result for one record does not prove the others are ready.

• Confirm public resolvers return the intended records.
• Check that only one SPF policy is returned.
• Reverify the exact sender address and the selected gateway.
• Send a small test and inspect EmailDesk Outbound History plus any later provider evidence.

Know the safety boundaries

Changing MX can interrupt inbound delivery if the target is wrong or the receiving service is not active. Removing an existing SPF mechanism can break another legitimate sender. A strict DMARC policy applied before all senders align can cause valid mail to fail authentication.

Passing SPF, DKIM, and DMARC does not prove that content is safe, wanted, or destined for the inbox. Recipient providers still control filtering, throttling, Spam/Junk placement, and final delivery.