Changing CNAME

[Sean_Tierney2]

Hi Valerie Armstrong​,

I know it's been some time since your original post, but I'm in the midst of a similar exercise now and curious to hear how your domain/cname changes went across the board. Any tips from your experience?

Thanks,

Sean

[Valerie_Armstro]

Hi Sean Tierney​,

So far, so good! We had a few bumps with Marketo Services with understanding what actually needed to be done, but here are some of my lessons learned.

• You may not have to change your Account String.  We had signed our contract to include a $1,500 account string change to find out we didn't need it, as our images URLs appear with our Munchkin Account ID (e.g. http://resources.upserve.com/rs/025-DFN-263/images/doc.pdf vs. http://resources.upserve.com/rs/swipely2/images/doc.pdf).
• Following the Marketo Doc from Dory Viscogliosi​ and instructions from Grégoire Michel​ in this thread, I was able to ensure that our resources.swipely.com continued to work if someone accessed an old email or a link back to one of our pages somewhere other than our website.  Internally, we did a good job of updating all of our URLs to reflect the new domain.
• I worked with the IT Team to ensure that we kept both SPF/DKIM Entries for upserve.com and swipely.com.  Also, we made sure that our branded email links (go.swipely.com and go.upserve.com) would continue to work. Here, once we made the switch to Upserve, now anything and everything from our system has the new company name.

LMK if you have any additional questions on the process and good luck!

[Sean_Tierney2]

Thanks Valerie Armstrong​!

Our landing page domain and CNAME changes rolled out perfectly...we haven't run into any issues

Tackling the branded email tracking link domain updates now. How were you able to make sure your original branded email links continued to function properly from old emails? Did your IT just keep the original domain up and running for a period of time or did you have to request redirect rules in Marketo and/or with your internal IT?

Thanks again

-Sean

[Valerie_Armstro]

Hi Sean Tierney​ - I believe IT kept our original branded tracking and added the new the new one.  Both branded link continue to work for us.

[Anonymous]

Hi Val and everyone else!

Firstly, thanks so much for this post. We are also moving to a new domain name so it's been incredibly helpful.

I'm reading through this thread to get a better understanding and one thing I'm not entirely sure I understand is the issue with the branded email tracking links. I just want to make sure I even understand the problem: is the problem that, even after we create the new CNAME and the redirect rule, Marketo still won't be able to track the lead activity in old emails? The problem is not that the old email links won't redirect, correct?

Also, did anyone ever come up with a solution for the tracking cookies? Is there any way to transfer over lead activity data from the old domain to the new domain?

Thanks,

Hoi

[SanfordWhiteman]

1. The links will still be tracked. But of course the branding domain won't magically be changed in old emails in people's inboxes.
2. Sharing cookies across domains is certainly doable (it's the same pattern as when multiple domain aliases are all live). However, you will need a solid JS developer who understands this area.
3. It's better to open new threads than to comment on old closed threads. You can of course link to other threads you used for research.

[Omar_Al-Sinjar1]

One thing you need to be aware of is the TTL (time-to-live for the DNS) should be set to 60 minutes or less.

[SanfordWhiteman]

There's no reason for the TTL to be set lower when you're setting up a new CNAME RR. One day is advisable.

[Anonymous]

Hi everyone,

We are doing another CNAME switch and this article has been incredibly helpful.

I was wondering for the redirect rule:

What is the best and easiest way to ensure that ALL of our landing pages from the old domain are redirected to the new domain? Do I need to create a redirect rule for each and every single landing page?

Additionally, I want to make sure I have my order of operations done correctly. So far, this is my understand of what needs to get done and the order in which it needs to get done:

For landing pages:

1. Setup the CNAME in the DNS of the new domain and do not remove the CNAME from the old domain
2. Go into Admin -> Landing Pages and replace the old domain with the new one
3. Still in Amin-> Landing Pages, create the domain redirect to the old domain, and do it quickly after step 2, since the web traffic to your LP old URL goes nowhere until you have do this.

For branded tracking links in emails:

1. Choose and setup a different CNAME for branded tracking links.
2. Ask IT to create a CNAME that redirects the CNAME chosen earlier to our current tracking domain which can be found in Admin -> Email: go.yourdomain.com > mkto-qe0877.com
3. Once IT has completed the creation of the CNAME, go back to Admin -> Email and enter branded tracking CNAME and Branding Domain
4. Ask IT to keep the go.olddomain.com dns entry or even better to redirect it to go.newdomain.com.

Is there anything we have to do on the DKIM/SPF side, if we are just rebranding?

Thanks,

Hoi

[SanfordWhiteman]

Hoi, you have the idea but I want to be picky about terminology and available functionality.

First, the informal term "redirect" has two very different meanings (as indeed you're using it in 2 different ways in your post):

1. An HTTP (response code 3xx) redirect. This kind of redirect is only possible if a browser connects to the webserver with the URL you want to redirect present in their location bar.*  In addition, depending on the environment, an HTTP redirect of a hostname does not necessarily mean that all paths and query strings under the hostname will be redirected (it may be only the root hostname that's redirected), and when paths and query strings are included in the redirect match, that doesn't mean they will stick around after the redirect (http​://www.example.com/path/name?key=value and http​://www.example.com/another/path?key2=value2 may both redirect to http​://www.ejemplo.org and that's still a legit form of global redirect -- keeping the path and query string is sort of a "value added" feature).
2. A DNS (CNAME RR, a.k.a. "alias") redirect. This kind of redirect occurs outside of (i.e. deeper than) the HTTP connection. As a result, you can't use the canonical (right-hand-side) side of a CNAME in an HTTP redirect, because the browser location will not change. If I have a CNAME record that says www.example.com is merely an alias for the A record www.ejemplo.org, that's all well and good and the browser will connect to the IP address for www.ejemplo.org -- but the URL you see, as well as the Host: header sent by the browser, is still www.example.com. So an HTTP 3xx redirect (see 1. above) on the webserver that intends to redirect www.ejemplo.org to www.examplar.net would have no effect. In addition, DNS CNAMEs do not have any awareness of paths and query strings. They only work on hostnames.

These details are important when planning a CNAME migration because Marketo only lets you set up HTTP redirects on their side. Your IT may think they can "game the system" with additional CNAMEs, but that ability is limited for the reasons noted above.

Marketo HTTP redirects only apply to individual hostnames and paths, not wildcards. Marketo will append the query string to the redirection target (the "value added" I mentioned above) which is nice/necessary, but it doesn't eliminate the need to create many redirects. If you really need to redirect all your old LPs to new ones (as opposed to just letting the old ones be) I would advise doing the redirect in JS. You can add this JS snippet to the <head> of your template(s):

function toCanonical(cn) { 
  if ( document.location.hostname != cn ) { 
    var newLoc = document.createElement('a'); 
    newLoc.href = document.location.href, 
    newLoc.hostname = cn, 
    newLoc.search += '&ref=' + encodeURIComponent(document.referrer); 
    document.location.replace(newLoc.href); 
  } 
  return false; 
} 
toCanonical('new-domain.example.com');

Note that you will lose the first hit's Referrer URL unless you also append it to the destination URL, that's why I add it onto the destination.

When you use the above method, you don't have to worry about hurriedly creating a huge bunch of redirects. Just move the new domain into the default Domain Name position and make the old domain a Domain Alias (swapping their initial positions).

As for branding domains, no real worry there. Just leave the old CNAME pointing to mkto-qe0877.com and add a new one, setting the new one as the default. Since people are redirected immediately after visiting the branding domain it doesn't matter that old emails in people's inboxes show the old domain (and you can't change that, anyway).

*Technically, it's with the URL as their HTTP Host: header but you can think of it the same way

**