Titan Email DNS checker
Check the public DNS records that matter when Titan Email is not receiving, sending, verifying, or passing authentication for a custom domain.
Titan Email hosts business mailboxes for a custom domain, but it is usually purchased through a partner host or registrar such as GoDaddy, Hostinger, or a Namecheap bundle, so the setup values are often shown in that partner's dashboard rather than a standalone Titan screen.
Public DNS still decides whether mail reaches Titan and whether outgoing mail authenticates, and the records take effect wherever the domain's active nameservers point. Use this page to confirm which DNS host is really in charge before copying values from a Titan or partner dashboard.
DNS records to check first
| Record | What to check | Safe note |
|---|---|---|
| Nameservers | Confirm whether the domain's nameservers point at the partner host that sold Titan, at Cloudflare, or at another DNS service, because that active host is where MX, SPF, DKIM, and DMARC records must be edited. | Records only take effect at the DNS host the nameservers make active - editing the partner dashboard while the nameservers point elsewhere changes nothing publicly. |
| MX | Confirm the domain's MX records match Titan's documented receiving hosts, mx1.titan.email at priority 10 and mx2.titan.email at priority 20. | Treat these as the publicly documented starting point and confirm the exact values in your Titan or partner control panel, removing old provider MX records only after migration is complete. |
| SPF | If Titan sends mail for the domain, the SPF record commonly includes spf.titan.email. | Confirm the exact SPF value in your Titan or partner control panel and merge it with any other real senders in one record; publishing a second SPF record breaks SPF for everyone. |
| DKIM | Titan generates a domain-specific DKIM record in its control panel, and the selector and value vary by account. | Copy the exact DKIM host and value from the Titan control panel. Do not invent them. |
| DMARC | Publish a DMARC record once SPF and DKIM are in place so receivers know how to handle messages that fail alignment. | Start with a monitoring policy such as p=none until reports show Titan and any other senders passing authentication. |
| Titan domain setup | Confirm the domain is connected to Titan in the Titan or partner control panel and the receiving mailbox or alias exists. | Correct MX records route mail to Titan, but they do not create the mailbox or alias - that happens inside the Titan or partner control panel. |
Common mistakes
- Editing DNS at the registrar while the domain's nameservers point at the partner host, Cloudflare, or another DNS service, so the Titan records never reach public DNS.
- Adding spf.titan.email as a second SPF record instead of merging it into the existing one.
- Guessing the DKIM selector or copying a DKIM value from a tutorial instead of the account-specific record in the Titan control panel.
- Leaving an old provider's MX records alongside Titan's after moving mailboxes.
Boundaries
Domain Email Doctor checks public DNS records only and does not access a Titan or partner-host account.
Mailbox creation, aliases, and the bundle between Titan and the partner host stay inside the Titan or partner control panel.
The DKIM record is generated per account and must come from the Titan control panel, and a passing DNS check does not guarantee inbox placement.