Create a Global Authentication Landing Page

Overview

An authentication landing page is the gatekeeper for any content you want to keep under lock and key. When a recipient clicks a secure link in an email, they don't see the content straight away — they land on this page first and are asked to verify who they are using the factors you've nominated. Once their details check out, they're granted access.

You'd reach for this whenever the content behind the link is sensitive: a personalised statement, a tax document, a policy update, or anything containing personally identifiable information (PII). Rather than send the document itself, you send a secure link, and the landing page does the gatekeeping.

The page you create here is your global default — it'll be used across every Application unless an Application overrides it with its own version. Build it once, brand it properly, and it'll serve as the front door for all your secure content.

‍

Before you start
‍The authentication factors recipients are asked for — surname, date of birth, postcode, account number, or anything else — are configured in the Security / data retention section of your Application. The field names on your landing page need to match what's set up there, otherwise the form won't validate. Get that lined up first, then build the page.

‍

Open the Login page editor

The global authentication page lives in your Send module settings, alongside your other default pages (Unsubscribe and Archived / expired). Here's how to get to it.

In the secondary navigation menu, click Edit settings to open the Send module settings.
Click the Default pages tab.
Click Login page to open the Visual Editor.

From here, you've got two ways to design your page — pick the one that suits how you like to work.

Option 1 — Visual Editor

The default option. Drag in blocks, drop in your logo, set your colours and copy, and you've got a branded page in minutes. No code required, and it's the quickest route if you're matching a simple brand template.

Option 2 — Advanced template

If you'd rather paste in your own HTML or write the page from scratch, click the dropdown arrow next to Save and choose Convert to Advanced template. This swaps the Visual Editor for the Advanced HTML editor, giving you full control over the markup, styles, and structure of the page.

‍

One-way conversion
‍Once you convert to an Advanced template, you can't switch back to the Visual Editor for this page. If you're not sure which to use, start with the Visual Editor and only convert when you know you need the extra control.

‍

Add the authentication HTML

Whichever editor you're using, the page needs a few specific bits of HTML to actually do the authenticating. Drop in a pretty form and nothing else, and the page will look great but won't validate anyone.

Here's what every authentication page needs to include.

Component	What it does
Form with POST method	The form has to submit using `method="post"` so the credentials are sent securely to CX Platform for validation. A GET request won't work.
XSRF token	The line `@Raw(Model.XsrfHtml())` renders a hidden anti-forgery token into the form. It's a security requirement — without it, the request will be rejected. Drop it inside the `<form>` tag, before your inputs.
Error message block	The `@if (!string.IsNullOrWhiteSpace(Model.ErrorMessage))` conditional shows a friendly message when someone enters the wrong details. Without it, failed attempts just refresh the page silently, which is a confusing experience.
Input fields	One `<input>` per authentication factor, with a `name` attribute that matches the field configured in your Application's Security / data retention settings. Adding `required` stops empty submissions reaching the server.
Submit button	A standard submit input — usually labelled Next or Verify — that posts the form back for validation.
Stylesheets and assets	Linked CSS files in the `<head>` handle the visual styling. You can use the bundled CX Platform stylesheets or point at your own CDN to match your brand.

‍

Build the page

If you're using the Advanced template, here's how the pieces come together.

Start with a standard HTML5 document — DOCTYPE, <head>, and <body> — and add the viewport meta tag so the page works on mobile.
Link your stylesheets in the <head>. These CSS files and any other assets can be added into your Application Asset Library.
Wrap the page content in your container divs — a logo block, a header block with the page title and instructions, and a form block.
Inside the form, drop in @Raw(Model.XsrfHtml()) as the very first thing. This is the security token — skip it and the form won't submit.
Add the error message conditional next, so failed attempts surface a clear message rather than a silent reload.
Add one input per authentication factor. The name attribute on each input has to match the field name configured in your Application — these names tell CX Platform which value to check against.
Finish with a submit button. Use type="submit" and give it a clear label like Next or Verify.

‍

The full example HTML

Here's a working example. Swap the logo, stylesheet links, header copy, and input fields to match your brand and authentication factors.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Secure Document Verification</title>
  <meta content="width=device-width, initial-scale=1" name="viewport">
  <link href="path/to/your-brand.css" rel="stylesheet">
</head>
<body>
  <div class="page_wrapper">
    <div class="container_auth-wrapper">

      <!-- Logo -->
      <div class="card_logo-wrapper">
        <img src="path/to/logo.png" alt="" class="logo">
      </div>

      <!-- Header copy -->
      <div class="card_header-wrapper">
        <h1>Secure Document Verification</h1>
        <div>To access this document, please enter your details below and click 'Next'.</div>
      </div>

      <!-- Authentication form -->
      <div class="card_form-wrapper">
        <form method="post">

          <!-- Security token (required) -->
          @Raw(Model.XsrfHtml())

          <!-- Error message shown on failed attempt -->
          @if (!string.IsNullOrWhiteSpace(Model.ErrorMessage)) {
            <div class="error-message">
              <p>Those details are incorrect. Please try again.</p>
            </div>
          }

          <!-- Input fields — names must match Application config -->
          <div class="input-row">
            <label>Dealer Number</label>
            <input name="dealernumber" type="text" required>
          </div>
          <div class="input-row">
            <label>Zip Code</label>
            <input name="zip" type="text" required>
          </div>

          <!-- Submit -->
          <input class="btn-submit" type="submit" value="Next">

        </form>
      </div>

    </div>
  </div>
</body>
</html>

‍

Match the page to your brand

The structure stays the same across every authentication page — what changes is how it looks. A few common ways to make it your own:

Swap the logo by updating the <img> source in the card_logo-wrapper div. Use a hosted image so the logo loads reliably regardless of where the page is accessed from.
Adjust the header copy in the card_header-wrapper block to match the tone of the email that sent recipients there. A statement send might say "Verify your identity to view your statement", a policy update might say "Confirm your details to access your policy".
Style with your own CSS by replacing the linked stylesheets with your brand stylesheet. The class names in the example (page_wrapper, card_form-wrapper, btn-submit and so on) are just hooks — name them whatever fits your conventions.

‍

Test before you go live
‍Always send a test email to yourself first and click through the secure link. Try the form with the correct details, then deliberately enter the wrong ones to confirm the error message displays the way you expect. A quick five-minute check beats finding out about a broken page after the send goes out.

‍

What's next

That's it — your global authentication landing page is built and ready to sit in front of secure content. Recipients clicking a secure link will land on your page, enter their details, and be granted access once the values match.

If you need to change which factors recipients are asked for, head back to the Security / data retention section of your Application. And if a particular Application needs its own bespoke landing page, you can override the global default at the Application level — handy when you've got different brands or audiences running through the same platform.