Pointing a Netlify-managed domain at your newsletter

Netlify DNS holds every record Issue Mint asks for, including the one on the root of the domain. Netlify supports a CNAME at the apex and flattens it when it answers, which is exactly what Issue Mint accepts for the website and click tracking records.

This page is about Netlify DNS, meaning the domain’s name servers point at Netlify. A site hosted on Netlify does not imply that: plenty of Netlify sites sit on domains whose DNS is still at the registrar, and in that case the records go there instead. Working out where your DNS actually lives is the quickest way to be sure.

Adding a domain is optional in the first place. A newsletter publishes and sends from the day you sign up, on its {slug}.issuemint.com address, and adding a domain moves the website and the sending onto yours.

Where the DNS panel is

Netlify keeps DNS zones under Domains, at team level, rather than inside a site. Open app.netlify.com, go to your team’s Domains page, click the domain, and the DNS records list opens with Add new record beneath it.

The form asks for Record type, Name, Value and TTL, and a Priority field appears for MX. Netlify shows the domain beside the Name field and appends it, so Name takes the prefix on its own: www, go, send, _dmarc, _acme-challenge.go. An empty Name means the domain itself.

The records to add

Seven records exist the moment you add the domain.

Copy the values from Settings, then Domain and DNS, rather than from this page. The three _acme-challenge records carry an identifier unique to your account, so no documentation page can print them, and every value in the domain tab has a copy button beside it. The two website records are what put your archive and signup pages on your own domain, and what each record is for covers the rest, including which ones are optional.

The record on the bare domain

Add the root record as a CNAME with the Name field left empty and the target Issue Mint shows for it in Value.

A CNAME may not sit at the root of a zone beside its NS and SOA records, so Netlify resolves the target itself and answers with its addresses. Issue Mint compares those addresses against the target’s own and verifies the record, which is why the table can ask for a CNAME on the root at all. The three certificate records are the exception and must stay real CNAMEs, because Cloudflare follows them itself to renew your certificate and a flattened one is genuinely broken.

The sending records, which arrive later

Five more records appear once Amazon has handed back your DKIM tokens, which happens on its own shortly after the domain is added.

Each DKIM host is a long token followed by ._domainkey, and Netlify appends the domain, so Name takes the token and ._domainkey and nothing else. Use the copy button rather than reading the token off the screen, because these are long enough that copying them by hand goes wrong. Until all three verify, issues go out from our address; after they do, they come from yours, which is what sending from your own domain means in practice, and it is the difference between a mailbox that can check your signature and one that has only the sending address to judge you by.

The MX and TXT records both sit on send, a subdomain, so mail addressed to your domain itself is unaffected and any mail records already in the zone should be left alone.

After you save

Netlify publishes a change to its own name servers within seconds, and the public resolvers pick it up within minutes. Issue Mint checks a newly added domain every ten minutes for its first two days and hourly after that, and Verify now forces a check immediately.

Certificates issue on their own once the _acme-challenge records resolve, and the HTTPS card on the domain tab tracks each hostname separately from the record’s own state. If a record you are sure about will not verify, the order to check things in starts with the cause that turns out to be the real one most often.