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
yourcompany.mktoweb.combecause 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.
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.comis the alias
yourcompany.mktoweb.comis the CNAME, the “canonical name”, i.e. real(er) name
3600is the time-to-live (expiry) of the record in seconds
CNAMEis the record type
INis 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 18.104.22.168
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
22.214.171.124 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
126.96.36.199, including the hostname
pages.example.com so the server sends the right page. Crucially, neither of the intermediate CNAME records are sent to
188.8.131.52. The only hostname sent is the one in the location bar,
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.
 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.