DNS setup

Three records, once, and then never again.

This is the only part of setting up send25 that happens outside your building, and it's where people get stuck. So here it is properly: what to publish, exactly where to click for your provider, and the mistakes that quietly break mail.

1 · Work out where your DNS actually lives

Do this first. It's the single biggest time-waster in DNS changes — people spend an hour editing records at their registrar, and nothing happens, because the registrar stopped being in charge of DNS years ago.

Who you bought the domain from is not necessarily who answers DNS questions about it. If someone once pointed the domain at Cloudflare, then Cloudflare is where records have to go — and edits anywhere else are ignored completely.

Find out for certain. On Mac or Linux:

dig +short NS yourdomain.com

On Windows PowerShell:

Resolve-DnsName yourdomain.com -Type NS | Select-Object NameHost

Not comfortable with a terminal? Any "DNS checker" website will show the same nameservers. Then read the answer:

2 · The three records, and what each one does

All three are TXT records. None of them affect your website, your existing email, or anything else — they only add permission for us to send on your behalf.

Your exact values are in your send25 console, under the domain, on the DNS setup page. It reads your live DNS first and shows you only what actually needs to change. Don't copy the examples below — they're here to show the shape.

DKIM — the signature

A cryptographic key that lets us sign mail as your domain, so receivers can prove it really came from you and wasn't altered. This is the one that makes relayed mail pass DMARC. Longest value, most important record.

SPF — the permission list

Names the servers allowed to send for your domain. We add one IP address to whatever you already have.

DMARC — the policy

Tells receivers what to do with mail that fails the checks above, and where to send reports. If you already have a DMARC record, leave it alone — your console will say so.

P=NONE means monitor only. It changes nothing about how your mail is delivered — it just asks receivers to report what they see. It is the correct place to start, and it is safe to publish today.

3 · Your provider, step by step

Pick the one your nameservers pointed at in step 1. The boxes below are diagrams of each form — the field names are what matter and those rarely change, even when the buttons get moved around.

4 · The five things that actually break it

In roughly the order they cause trouble. The first one is worth reading even if you skip the rest — it's the one that breaks all your email, not just ours.

MISTAKE 1
Two SPF records

A domain may have exactly one record starting v=spf1. Not two. If a second appears, the standard says the result is an error — and receivers treat that as no SPF at all, for every system you send from. Your Microsoft mail, your CRM, everything.

It's an easy mistake because adding a record feels safer than editing one. It isn't.

Your console does this merge for you and shows the finished line. Copy it whole, and replace what's there.

MISTAKE 2
Typing the full name in the Name field

Nearly every provider adds your domain automatically. Typing mr2026._domainkey.yourdomain.com produces mr2026._domainkey.yourdomain.com.yourdomain.com, which nothing will ever find. Enter the short name and let the provider finish it.

The exception is the handful of Zone Editors that want the full name with a trailing dot. Look at how existing records in the list are written — they'll tell you which kind you're in.

MISTAKE 3
The DKIM value getting mangled

The DKIM record is long — around 400 characters. Three things go wrong:

• It gets truncated. Copy from your console with the copy button rather than selecting by hand; it's easy to miss the last characters of a long line.
• A line break sneaks in. Pasting through a word processor or a chat window can insert one. The value must be a single unbroken line.
• Route 53 needs it split into quoted chunks — see the Route 53 section above.

If DKIM shows as mismatch in your console rather than missing, a truncated or altered paste is the usual cause.

MISTAKE 4
Editing DNS at the registrar when it's hosted elsewhere

Covered in step 1, and it's worth repeating because the failure is so quiet: the form saves, shows a success message, and changes nothing at all. If you've published records and nothing happens for an hour, check your nameservers before you check anything else.

MISTAKE 5
Expecting it to be instant

New records usually appear within a few minutes. Changes to a record that already existed can take as long as its old TTL — often an hour, occasionally a day. Nothing is broken during that window; the internet is just still holding the previous answer.

Your console re-checks live DNS every time you open it, so refresh rather than re-adding. Adding the record a second time because the first "didn't work" is how mistake #1 happens.

5 · Checking it worked

Three ways, easiest first.

1. Your send25 console. Open the domain's DNS page. It queries live DNS and shows each record as published, missing or mismatched — with the exact value it expected. When all three are green, you're done, and the domain switches on for sending.
2. Send yourself a message. The real test. Send through the relay to a Gmail or Outlook address you can open. In Gmail, use Show original: you want SPF: PASS, DKIM: PASS and DMARC: PASS. That's the recipient's own verdict, not ours.
3. Check the records directly, if you like a terminal:

dig +short TXT mr2026._domainkey.yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com