Your IT team is wrong: there’s no reason to expect https://▁▁.mktoweb.com to open in a browser

Sorry, it’s just facts: experienced MOPS folks are more technical than junior IT staff. (And I say this as a former know-it-all IT guy.)

Or if not more technical at the detail level, certainly more technically assured. If you’ve seen a Marketo config work in 10+ different instances, chances are you know what you’re talking about!

A client forwarded some frustrating IT pushback the other day:

That CNAME record won’t work.
We can’t make pages.example.com point to yourcompany.mktoweb.com because opening https://yourcompany.mktoweb.com gives an SSL error.

Bzzzt! Wrong. Whether https://yourcompany.mktoweb.com opens in a browser is irrelevant.

See, you’re only asking for a DNS alias to be set up, and by definition DNS resolution finishes before the HTTP request/response process starts. Alias-to-CNAME mapping is a DNS issue only. It has nothing to do with HTTP requests.

So https://yourcompany.mktoweb.com might throw a 404 or 500 error, return a 3xx redirect, whatever, doesn’t matter.[1]

What matters is whether https://pages.example.com works. And, provided Marketo Support has installed the SSL cert for that domain, it will.

Let’s dive in a bit and see why.

Setting up a CNAME record for your LP domain

To get a Marketo LP domain working, you make the domain a DNS alias for the Account String shown in Admin:

DNS aliases use the CNAME record type:

pages.example.com 3600 IN CNAME yourcompany.mktoweb.com

In the above CNAME record...

• pages.example.com is the alias
• yourcompany.mktoweb.com is the CNAME, the “canonical name”, i.e. real(er) name
• 3600 is the time-to-live (expiry) of the record in seconds
• CNAME is the record type
• IN is known as the record’s class (short for INternet, you always use IN for standard DNS entries)

The CNAME concept is simple, but still confuses people. To reiterate, the left-hand-side pages.example.com is the alias — it’s not “the CNAME” as people erroneously say. The right-hand-side yourcompany.mktoweb.com is the CNAME. You’re mapping an alias — one of potentially many aliases across different domains — to a more accurate name.

Opening an alias in the browser

HTTP requests (like any requests over the open internet) are between IP addresses. They’re not between names.

So when you open https://pages.example.com, first thing it does is ask its configured DNS servers for the IP address of pages.example.com. It gets a DNS response like this:

pages.example.com.       3600    IN      CNAME   yourcompany.mktoweb.com.
yourcompany.mktoweb.com. 300     IN      CNAME   sj01.mktossl.com.
sj01.mktossl.com.        300     IN      A       104.17.74.206

Now, that may look a little confusing, but I didn’t want to dumb it down.

The response includes two CNAME records, not just one. The IP address is 1.2.3.4 but a couple of aliases need to be resolved to get there.

(I foreshadowed this above by saying the CNAME is the “real(er)” name of any alias — not necessarily the “real(est)” name. The CNAME of one alias can end up being an alias of yet another CNAME, and so on until you reach an A record which points to an IP.)

Now that the browser has the IP address, it connects to 1.2.3.4, including the hostname pages.example.com so the server sends the right page. Crucially, neither of the intermediate CNAME records are sent to 1.2.3.4. The only hostname sent is the one in the location bar, pages.example.com.

The process is visualized here:

So while IT was superficially correct that https://yourcompany.mktoweb.com may generate this error —

— it just doesn’t matter. That’s not how real people request your Marketo LPs and has no bearing on setting up the CNAME record.

Notes

[1] Naturally, the server has a webserver listening on port 80/443. But that webserver doesn’t need to support the HTTP Host/SNI value yourcompany.mktoweb.com. It’s free to throw an error just as it would for any undesired domain.