How to Delegate a Subdomain

Subdomain Delegation

iPost Enterprise requires that all clients delegate a domain or subdomain for sending purposes. There are four possible ways to provide a subdomain for use in mailings from iPost.

  1. Name service delegation. This is the preferred method because it allows iPost to create and maintain authentication records and IP addresses and shows your brand identity consistently across all steps of the email process. All steps of name service delegation must be completed before any iPost setup is performed to ensure your deployment is as efficient as possible. The subdomain can be any word or letter prepended to your existing domain, such as:


  2. Canonical name aliasing (CNAME). Some registrars and other DNS hosts do not allow creation of “NS” (nameserver) records for delegation. In this case a “CNAME” record may be created that points to a second name managed by iPost. This has many of the same benefits of subdomain delegation but, in some cases, may expose the iPost-managed name. To use a CNAME, an iPost client record must first be created, so iPost setup must be interleaved with establishing the CNAME. Please notify your Customer Success Manager if subdomain delegation cannot be done.  It should also be noted, that Google postmaster tools cannot be used with CNAME delegations.
  3. Client-hosted name service. In this case, all DNS records are stored at your registrar or DNS provider. THIS IS NOT RECOMMENDED because it means that any future changes iPost may need to make must be communicated through your technical staff, which may result in disruptions to the email services provided to you. To use this approach, iPost must complete all setup and communicate detailed DNS information to your technical team, wait for your DNS service to be updated, and then perform final adjustments and tests. Hourly charges apply for this work. Furthermore, iPost only approves of a client-hosted name service when you have competent technical resources available to assist with the DNS configuration process.
  4. New domain registration. In this case, an entirely new domain name is registered, either by you or by iPost, and full control of that domain is assigned to iPost. This is also not recommended because new domains are viewed with some suspicion by ISPs, which may impact your initial deliverability. Furthermore, recipients may perceive the new domain as an attempt by a third party to masquerade as a trusted sender (i.e., a phishing attempt or a source of malware), which may increase spam complaints and reduce response rates.

If you cannot provide a sub­domain, iPost will assign a name that we manage, but this weakens your brand identity and is not recommended. It also has some of the drawbacks of registering a new domain.

Once the delegation is in place, please contact iPost Client Services so iPost can check your configuration and complete the setup.

Create only NS records when delegating a subdomain. A or MX records are created by iPost.

Identifying the Nameserver

Before a sub-domain can be delegated, the correct nameserver for the parent domain must be found. In many cases the parent nameserver and the domain registrar are one and the same. Therefore, the registrar’s tools may be used to delegate the sub-domain (see example below). In other cases, the nameserver may be located at a web hosting provider or may be privately operated by your IT department.

Using an Online Tool

A useful tool for nameserver lookup is MX Toolbox (

  1. Enter the parent domain name in the “Lookup Anything” box. For example, if the domain to be delegated is “”, enter “”.
  2. Click the down arrow beside the button to the right and choose DNS Check from the menu.
  3. Click the DNS Check button.

Using a Command-line Tool

For UNIX-based systems such as Linux, the best tool to use is “dig”. Use it to query the name servers of the parent domain, again using “” as our delegated sub-domain:

dig +short -t ns
Click to copy

For Windows systems, open a Command Prompt window and use “nslookup”. (It is also possible to use “nslookup” on most UNIX-like systems but it has been deprecated on some in favor of “dig”.)

nslookup -type=ns
Click to copy

Additional detail or to look up several domains:

  1. In the Command Prompt window, type “nslookup” and press enter. Some information about your local nameserver is displayed and then an “>” prompt appears.
  2. Type “set querytype=ns” and press enter.
  3. Type the name of the parent domain, e.g. “” and press enter.
  4. The name server information for is displayed.
  5. Enter other parent domains to look up if needed, one at a time.
  6. Enter “Exit” when you are finished doing lookups.

After the Parent Nameserver is Known

Provide the instructions below to the IT staff who operate the name server, or follow them yourself if you have the necessary access.

Name Service Delegation Instructions

We recommend keeping the subdomain name short to keep down the length of the URL in the text version of the mailing; e.g., if the company name is, you might use a subdomain name of

For UNIX-based Systems

Using the BIND name server software, you would add the following records to the zone file (do NOT create a new zone file for itself):

news IN NS
news IN NS
Click to copy
  • The trailing periods on and are significant. “Glue records” are unnecessary in this setup because the nameservers for the subdomain do not reside within the DNS namespace of the subdomain itself.
  • When updating a zone file, including adding new records, you must be sure to update the Serial Number in the SOA record that controls the zone. If you don’t know what this means, get help from your IT professional.

For Administering DNS Under Windows

  1. Go into in the DNS management console.
  2. Right click on the parent zone (i.e.
  3. Select New Delegation.
  4. Follow the wizard instructions to create a delegation for “news” using these name servers: 
Click to copy

For Registar Control Panels Such As GoDaddy

  1. Choose “” and click Edit Zone.
  2. Scroll down to the very bottom of the list (“NS (Nameserver)”).
  3. Enter the subdomain name (in this case “e” or “mail”, etc. - just the leftmost part) in the “Host” box
  4. Enter “” in the Points To box.
  5. Click Save.
  6. Repeat steps 1-3, then enter “” in the Points To box.
  7. Click Save again.

For Amazon Route53

If your new subdomain is a direct child of a parent domain that is already hosted in Route53, skip to step 6. Steps 1 through 5 are required only to create an additional zone in which to add further nested delegated subdomains.

  1. Sign in to the Route 53 console, and select Hosted Zones from the navigation pane on the left.
  2. Choose Create Hosted Zone.
  3. Enter the following information into the corresponding fields:
    For Domain Name, type your domain name. For example, "".
    For Comment, type a description for the zone.
    For Type, choose Public.
  4. Choose Create. Select the NS type record in the newly created zone, and replace the assigned hostnames with the iPost DNS servers on separate lines.
  1. Choose Save Record Set to update the NS record.
  2. Select Hosted Zones from the navigation pane on the left, and select the "" parent hosted zone.
  3. Choose Create Record, and enter the following information:
    For Name, type your preferred subdomain name. For example, if the subdomain you want to create is "", type "subdomain".
    For Type, choose NS – Name Server.
    For TTL, select the 1d preset button. A shorter selection is also OK.
    For Value, type the iPost name server hostnames (noted above) on separate lines.
    Leave all other values as their defaults.
  4. Choose Create Records to commit the record to the hosted zone.

The example below shows the Route53 configuration for delegated domain in parent domain

What to do if NS records cannot be created/changed

In the event that delegation records cannot be created for technical or policy reasons, the subdomain can be created as a CNAME (canonical name) record instead.

  1. Contact your iPost representative and inform them that you wish to create a CNAME.
  2. iPost creates a customized name to be the target of your CNAME alias. This name typically has the format or something similar.
  3. Your iPost representative will communicate this name to you. Using your registrar control panel (or via your technical staff), create a CNAME record linking your desired sub-domain to the iPost-managed name.
  4. Inform your iPost representative that the CNAME has been created. iPost then validates the new sub-domain and completes your setup.

A note on second vs. third level domains

A “sub-domain” usually refers to a name with three or more parts separated by dots (e.g., It is typical to start with the “second-level” domain ( that is best identified with your brand, and then add a third “level” (news) that you designate for email purposes. This is the same pattern by which “www” (world wide web) is often designated for website use, but there is no de facto standard for email akin to “www” for websites.

In some cases, you may wish to create a second-level domain exclusively for email (the new domain registration option described above). The instructions for creating name server records for a second-level domain are similar to those for sub-domains, with one important difference: Name service for a second-level domain CAN NOT be delegated. Instead, iPost’s name servers must be assigned to the second-level domain at the registrar, and you give iPost full control over all third-level (or greater) names within the second-level domain.

We do not recommend using second-level domains in this way, but it is supported.

Why Do We Do All This?

Name service delegation, or the creation of a CNAME, enables the following:

  1. Our system automatically generates a complete set of DNS records for the appropriate domain. That set includes:
    1. A records: Address Record points a domain or subdomain to an IP address.
    2. MX records: Mail eXchanger record is a type of certified and verified resource record in the Domain Name System that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain.
    3. TXT records for:
      1. SPF: Sender Policy Framework record is used to indicate to mail exchanges which hosts are authorized to send mail for a domain.
      2. DKIM: DomainKeys Identified Mail is a protocol that allows verification through cryptographic authentication.
      3. DomainKeys: A deprecated email authentication system designed by Yahoo to verify the domain name of an email sender and the message integrity.
      4. DMARC: Domain-based Message Authentication, Reporting & Conformance is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
    4. For a delegated sub-domain only, a further sub-domain “img” for hosted assets (e.g.,
  2. URLs in the email content are automatically replaced with new URLs that use the sub-domain so that iPost can track views and clicks. Those new URLs redirect to the original URL after recording the action.
  3. The SMTP envelope FROM: field uses a tagged address at the sub-domain, so that iPost can handle bounces (via the automatically created MX records) and match them with recipient addresses.
  4. At the customers’ option, the user-visible From: field in the message may use an address at the sub-domain (we call this the IBMF, “in-bound message filter”, address) to automatically process opt-out requests, out-of-office responses, etc. (also via the MX records). This is not required. The customer may use any other working email address and handle all responses themselves.

This automation frees you from having to react if we update any of our IP addresses or if a new type of TXT record becomes standard, etc.