← Content Support

Changing A Website's Main Domain

Acquiring a new domain

Chances are the client has already purchased the new domain they would like to use. If not, they will need to do this first, preferably with a registrar that has decent customer support – you will need them later. Please note, JHA can't purchase .bank domains for our clients.

Setting up the SSL

The client should keep their current domain active for at least a year after changing their primary domain – visitors to their site may have that domain bookmarked or will need time getting used to using the new domain.

To have the current and new domains active, they will need our Multi-domain SSL package. This may already be part of their existing contract – if it's not, let them know they will need to order it. The pricing for a standard multi-domain SSL cert is listed in the SSL Info document.

If the client approves of this, send an email to Emily Gershbein including the quote given to the client and a list of all domains that will be on that cert, along with the FI name and JSource ID, and a name + email of their preferred contact.

Emily will provide a Data Sheet for the client to sign off on, and once they have, you will need to send a signed copy back to her. The billing for this will just be part of their monthly invoices.

Now you can create a case with the SSL Team to order the new cert. If the client needs to do validation via DNS, you will need to get a zone for the new domain set up before this can be completed.

Setting up the DNS

If we already host their DNS, you can send a request in to Websol DNS to create a zone for the new domain with a DMARC record – you will need to provide the email address of the appropriate FI contact. We can manage DNS for .bank domains under profitstarscms.bank DNS.

Once the zone has been created, you should receive a list of the new domain's nameservers and a few DS Resource records that need to be sent to the new domain's registrar to be added. For more information on to DMARC (and DKIM) records, please see the DMARC & DKIM Records section of this document.

Confirming Details

You will need to ask the client which domain they want to be the primary domain – the one all others will re-direct to. Also now is a good time to ask if they are going to replace their logo, footer, affiliation info or anything else that could be affected by a domain change.

Sending to Banno Tech OPS

Next you will need to send a case to Banno Tech OPS, taking note of the current and new domains. Request the new domain be set up in vhost and have the A record pointed to it.

If re-directs will be necessary, request those be set up as well. Once the re-directs are completed, be sure to check that they are working properly.

  1. Send case over 3 business days before ‘due date’
  2. Send reminder in Slack at least 1 business day beforehand (#org-launch-control)
  3. Set expectation with client, the process for the domain update/redirect will start 30 minutes prior to ‘due date time’ but propagation can take up to 1 hour (30 minutes post due date time)

Updating Google Maps API

If the client uses Google Maps on their site, they will need to add the relevant URLs for the new domain to the list of restrictions within their Google Maps API. The maps and locations feed will not load properly until this is completed.

Updating Google Analytics

If the client uses Google Analytics or Google Tag Manager, they will need to update the tracking URL to their new domain so site data can continue to be collected. Check to see if we manage either of these services for the client and update as needed. If we do not, reach out and let the client know to make the appropriate changes.

Updating the CMS

If this client uses the Banno CMS, you will need to create a Trello card on the Aggregation Implementation board using the Update Institution Details template. Fill out the details and place it in the Incoming column.

The Institution ID can be found in the CMS under Settings > Admin Settings.

Updating the Microsite

If this client uses the Banno CMS they should have a working microsite, and if the primary domain was changed, this will need to be updated (otherwise it will go to a 404 page) Just open up a case with the Banno Dev team requesting the microsite be updated to their new URL.

DMARC & DKIM Records

DMARC records work alongside SPF and DKIM records to protect a domain from unauthorized use. It allows a client to see what email servers are sending using their domain. This information can be used to determine if SPF record changes are needed to authorize additional servers. Initially, a DMARC record can be set to p=quarantine, but once the SPF record is correctly configured, the DMARC record should be set to p=reject.

Any domain can have a DMARC setup. Please note that DMARC is not related to the domain registrar, and it can be set up for any email address. A client can put together their own DMARC record and use their own email address – but please suggest a reporting service (like Postmark). In the case of Postmark, the client can provide them with their domain, and Postmark will provide the DMARC record to add – sending out a weekly digest email of the compiled info.

See the following example record for reference:

v=DMARC1; p=reject; fo=1; rua=mailto:leverett@jackhenry.com; ruf=mailto:leverett@jackhenry.com

If a DMARC record is pointing to an email address at a different domain than it was created on, another record will need to be created at that domain to authorize it. In the case of the example above, let’s assume the record was created on exampledomain.com. The following record would need to be created at jackhenry.com:

exampledomain.com._report._dmarc.jackhenry.com IN TXT "v=DMARC1"

A reporting service, such as Postmark, will identify situations like this and provide the client with the appropriate records – saving time and ensuring their setup is correct.

DKIM records digitally sign an email on the server at the time it is sent. This allows email servers to compare against the public record when an email is received from a domain, to determine if it is a legitimate email. DKIM records need to be provided by the client. They aren’t something we can create for them.