Set up a branded portability tool domain and authenticated email sending for a domain you own, using hostnames and DNS values MultiTEL confirms for your service. These settings are separate from transferring a phone number.
What this setup is for
A white-label portability tool lets you present number-transfer requests under your own brand and, when configured, send request emails on behalf of your own email domain. DNS changes in this guide apply to that branded website and email identity. They are not a requirement for an ordinary phone-number transfer and do not change the phone number's voice routing.
You must own and control the domain whose DNS you will change. You cannot configure these records for an address on a third-party free-mail domain that you do not own.
Confirm the branded service before changing DNS
Open Number portability. Use the branding fields there to set the brand name and logo used for requests in that screen. For a custom-domain white-label site, ask MultiTEL support to confirm which brand settings apply, the hostname, the DNS values to publish, the sender domain and the HTTPS certificate setup for your account before publishing any DNS records.
Do not redirect an existing production website or change existing mail delivery merely to brand a portability request. Record the previous DNS values so you can restore them if needed. If faster propagation of a later change or rollback is needed, lower the affected records’ TTL in advance and wait out the previous TTL before making the change. Lowering the TTL does not immediately expire existing cached answers.
Website CNAME
After MultiTEL confirms the custom hostname and CNAME target for your service, create the requested CNAME at your DNS provider. Check whether the DNS console appends the zone name automatically; enter the host label or full name according to that console’s instructions, without duplicating the domain. The confirmed CNAME hostname must not also have A, AAAA, MX or TXT records. If other records already exist there, check which services use them before making changes. Use a different MultiTEL-approved hostname if that name still serves another service; remove existing records only after confirming they are no longer needed.
The following is an example only: it applies if you own test123.com and MultiTEL confirms both porting.test123.com as your hostname and porting.multitel.net as your service’s CNAME target. Do not use this target unless support confirms it for your service:
porting.test123.com. IN CNAME porting.multitel.net.Use the exact target confirmed for your service. A CNAME alone does not activate the custom domain or guarantee a valid HTTPS certificate. Confirm the site's certificate and the branded request flow before sharing the new URL.
SPF for request emails
If MultiTEL confirms that request emails will be sent on behalf of your domain, ask support to identify the sending domain used for SPF and the signing domain used for DKIM. These need not be the branded website hostname. Publish SPF at the confirmed SPF domain and the DKIM public key at the selector-specific name described below; do not add mail-authentication TXT records at the website CNAME hostname. Authorize the confirmed sending service in the SPF domain's policy. The MultiTEL SPF include shown here is include:_spf.multitel.net. Add it only after support confirms that it applies to the sending service for your account.
If the domain already has an SPF TXT record, merge the authorized include into that existing policy. Preserve other legitimate senders and the intended final policy; do not publish a second SPF record. Check the entire policy, including nested includes and redirects, against SPF’s DNS lookup limits. SPF evaluation permits at most 10 DNS-lookup-causing terms, such as include, a, mx, ptr, exists and redirect; exceeding that limit produces permerror. A broken SPF policy can prevent legitimate mail from passing SPF authentication. If there is no existing policy and MultiTEL confirms this is the only authorized sender, an example is:
@ IN TXT "v=spf1 include:_spf.multitel.net ~all"DKIM for request emails
Publish the exact DKIM selector, DNS record name and public-key TXT value confirmed for your signing domain. The DKIM DNS name combines the selector, _domainkey, and the signing domain. For example, selector mail for example.com produces the full record name mail._domainkey.example.com; mail._domainkey is the relative record name, not the selector. Obtain the current values from MultiTEL support; do not assume that a selector or public key copied from an old article, another account or MultiTEL’s own DNS is the value used for your account. A DKIM public key is published in DNS; a private signing key must never be requested or published.
Check whether your DNS console appends the zone name automatically, and avoid duplicating the domain or _domainkey in the record name. Preserve the complete public-key value when a DNS console splits a long TXT record into quoted chunks.
Verify the complete result
Query the authoritative nameservers and an external resolver for each changed record. Allow the configured TTL and DNS caches time to expire; a result from one cached local resolver is insufficient. Compare the fully qualified record name, type, exact target or value, quoting and any trailing dot with the confirmed instructions and your DNS provider’s input format. Resolve conflicting records, wrong names, missing values and invalid certificates before sharing the URL or relying on branded email.
Open the confirmed branded request URL and confirm that the pages load with a valid certificate and the expected brand. Before submitting any test, ask MultiTEL support which test flow is available and whether a submission would initiate a live number transfer. After support confirms branded email is enabled for your account, test it only through the confirmed test flow and with the sample data or test procedure support provides, so you do not initiate a live number transfer. Inspect the received message’s authentication results for SPF and DKIM. Check that replies and request links reach the intended destination. Keep the previous service and records available until the replacement has been verified, and remove only records that MultiTEL confirms are superseded.