1. The brief

The ask was both cosmetic and functional. The old subdomain had been a workaround; the new domain is the real address. The magic-link issue was a bigger problem because it silently broke sign-in for a whole category of users.

2. DNS, certificate, sender authentication

An A record was added at domains.co.za for the apex of vodalibrary.online pointing at the VPS. A CNAME was added for www pointing at the apex hostname (Hasmukh first set the www as a CNAME pointing at an IP, which Let’s Encrypt rejected as invalid; corrected to the bare hostname and validation passed).

SendGrid domain authentication for vodalibrary.online followed: three CNAMEs added at domains.co.za, validated green at SendGrid. The sender address moved from library@vodalibrary.vodavideos.co.za to library@vodalibrary.online.

A new Let’s Encrypt certificate was issued for the apex. After Let’s Encrypt’s strict DNS resolver caught up (about fifteen minutes), the cert was expanded to also cover the www subdomain. The old certificate for vodalibrary.vodavideos.co.za was deleted via certbot delete --cert-name; the cert is gone, the vhost no longer mentions the old hostname, and anyone hitting it gets a TLS mismatch in the browser, which is exactly the “this is gone” signal we wanted.

3. Nginx, three server blocks

The new vhost has three server blocks: an HTTP catcher that redirects everything to HTTPS (and exposes the ACME challenge path so renewals continue to work), an HTTPS www block that redirects to the bare apex, and the HTTPS main site at the bare apex. App config was updated to the new site_url and the new sender_email.

4. The two-step magic link, for Mimecast

Some managers were reporting “the link doesn’t work, it says it expired before I clicked it.” The cause was their corporate email gateway (Mimecast in Hasmukh’s case, others run Microsoft Defender or Apple Mail Privacy Protection). These scanners pre-fetch every link in an inbound email to scan it for malware. A single-use magic link gets consumed by that pre-fetch, so by the time the human clicks, the token is already burnt.

The fix: split the verify endpoint into two steps. A GET request on /verify?token=... now shows a small “Click to sign in” confirmation page and does not consume the token. A POST request on /verify, triggered by the human clicking the button, actually consumes the token and signs the user in. The corporate scanner sees the GET and finds nothing to attack; the human gets one extra click but a working sign-in.

5. Auto-invite when a person is added

Adding a person via the admin page used to insert them into the allowlist and stop there; the new manager would then have to navigate to the URL and type their email. We removed that step. Adding a person now also auto-sends them their first sign-in link via SendGrid, with the status message reflecting whether the email went out.

6. The Damyanti typo and what it taught us

One enrolled manager (Damyanti) reported never getting her sign-in email. The cause was a typo on the login form: she had typed damyantu@ instead of damyanti@. The system correctly logged the attempt as login_attempt_unknown, but the visible “email sent” reassurance message had hidden the issue from her.

Worth keeping for future debugging: when someone says “I never got the email”, check the access_log for login_attempt_unknown entries first. HEX(email) in MySQL makes it easy to see the actual character bytes when two strings look identical to the eye.

7. Going forward

Optional cleanup at domains.co.za: delete the old vodalibrary A record under vodavideos.co.za. The hostname is dead anyway (no vhost serves it, no cert covers it), but removing the DNS record makes it tidier. Not urgent.

One small UX improvement to consider later: customise the email body slightly when an admin adds someone (“You’ve been given access to the Vodavideos Library by Hasmukh”) versus the standard self-requested sign-in flow.