Custom domain setup

To keep staff email on its current provider, add a dedicated domain such as agents.example.com to Robotomail. Publish its returned MX and authentication records at the DNS host for example.com. Depending on the provider, the Name field may expect agents rather than the full hostname; confirm the final record shown in DNS.

Leave the parent domain's MX route in place unless you intend to move its incoming mail. Subdomain mailboxes have their own addresses; agent@agents.example.com does not receive mail sent to agent@example.com automatically.

Publish only one SPF TXT policy for each hostname. Merge requirements only for services that actually send on that hostname, and use the returned Robotomail values rather than guessed includes. Validate the full SPF policy and lookup count before switching traffic.

First identify the authoritative nameservers. A domain bought through Namecheap may use another DNS provider; edits in the registrar have no effect if its DNS service is not authoritative.

In the domain's DNS management, add each record returned by Robotomail. Match its type, name, value and MX priority. Provider interfaces sometimes append the root domain to the host field, so check that a full hostname has not become selector.example.com.example.com.

Do not replace working MX records on the parent domain while configuring an agent subdomain. Save the changes, check the public answers and run Robotomail verification. Interface labels can change; the required DNS records come from the Robotomail setup response.

Check whether GoDaddy is the authoritative DNS host, then add the records returned for your Robotomail domain. Preserve the exact record types, names, targets and priorities. A host field may expect a relative subdomain instead of a fully qualified name.

An A or CNAME record for a website does not establish an email receiving route. The MX records for the email domain determine where its incoming mail is sent. SMTP host, port and password settings from an existing GoDaddy email product are not Robotomail API credentials.

If your main domain uses another email service, configure an agent subdomain or plan a deliberate migration. Verify public DNS and send a message from an external address before relying on the new route.

Check public DNS for the exact hostname you configured. For example:

dig MX agents.example.com
dig TXT agents.example.com
dig TXT _dmarc.agents.example.com

For DKIM, query the record type and selector returned during setup. Compare the result with Robotomail's required value. Check authoritative nameservers if a resolver still returns old data, and allow for the previous TTL to expire.

Common errors include editing a non-authoritative zone, duplicated domain suffixes, missing MX priorities, multiple SPF records and mixing records from another domain. DNS verification and provider verification are separate stages; wait for the domain's final verified state before creating a production dependency. A successful DNS lookup alone does not prove end-to-end delivery.

Copy each DKIM record returned by domain setup, including its selector, record type and full value. Some setups use CNAME records; others use TXT keys. Use the actual response rather than a fixed record count from an old article.

Check public DNS for the exact selector hostname. Watch for truncated values and a provider appending the domain twice. Run Robotomail verification after the records resolve. Then send a test message and inspect the receiving provider's authentication results. Keep old keys during a planned rotation for as long as your provider's migration instructions require.

DMARC records live at _dmarc beneath the email domain. A monitoring policy can help identify legitimate senders before you request stricter handling. For example, replace the reporting destination in this illustrative record with a mailbox you operate:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A missing record means no DMARC policy was found at the checked name. Confirm the domain and authoritative zone before adding one. Avoid duplicate policies. If you use an external reporting domain, additional authorization may be required by that reporting setup.

Review actual alignment results before changing to quarantine or reject. A strict policy can affect legitimate senders that were not included in your inventory. DMARC does not block every forged display name and does not validate an email's instructions.

Aggregate reports summarize sending sources, message counts, policy evaluation and SPF/DKIM alignment over a reporting interval. They commonly arrive as compressed XML. Extract and process them with tooling appropriate for untrusted attachments.

Group results by source and authenticated domain. Investigate legitimate senders that fail alignment, then separate misconfiguration from unknown or abusive sources. Forwarding and mailing-list transformations can complicate interpretation, so do not automatically block every source with a failed SPF result.

Robotomail does not provide a DMARC report analyzer through this guide. Use a reporting workflow you operate, keep access restricted and apply an appropriate retention period. Tighten policy after you understand the aggregate results.

Domain registration, DNS hosting, employee email and identity administration may be operated by different providers. A Google-managed domain or Workspace account does not need to move simply to give an agent a separate address.

Use a subdomain with its own MX route when staff email should remain unchanged. If you intend to change the parent domain's route, inventory every mailbox and alias first. Multiple MX records are not a general way to split the same domain's recipients between unrelated providers.

Robotomail domain setup controls its email domain and mailboxes. It does not administer Google identities, move existing provider accounts or import their historical messages.

Add and verify the new domain before creating the replacement mailbox identities. Update the application's mailbox mapping, credentials where needed, sender addresses and any customer-facing contact information. Test sending and receiving at the new address before switching the workflow.

Changing a domain's name or MX route does not rename every existing identity in place and does not migrate mail history. Plan how active threads, old addresses, forwarding and data retention should work during the transition. Only use forwarding or aliases if the relevant provider and your application explicitly support that configuration.

Keep a rollback plan and monitor both delivery and incoming replies during the cutover. Retire old routing only after you have handled the conversations and systems still using it.