Adding records at your DNS provider

Every provider asks for the same records, and every provider labels the boxes differently. This page covers the ones our customers use most, with every value written out. The one exception is your DKIM key, which is generated for your domain alone — copy that from Admin → Domain → DNS, never from an example here or anywhere else.

The records you'll add

Seven records in total. Six of them are the same for every domain and are written out in full below. The seventh — your DKIM key — is generated for your domain alone, so copy that one from your DNS screen.

MX and the two CNAMEs make mail arrive and set up mail apps automatically. SPF, DKIM and DMARC are what stop your outgoing mail being filed as spam — DNS records & email authentication explains what each one proves.

The host field

Providers disagree most about one thing: what to put in the name field for a record that applies to the domain itself. Nearly every "I added it but it still says pending" turns out to be this.

For a subdomain like dkim._domainkey, every provider above wants the prefix on its own — they add your domain for you. Cloudflare is the exception: it accepts either form and normalises it.

GoDaddy

Domain portfolio → your domain → DNS → Manage zones.

Namecheap

Domain List → Manage → Advanced DNS.

Cloudflare

Select your domain → DNS → Records.

• Cloudflare accepts either @ or the full hostname and normalises it, so the doubled-domain mistake is harder to make here.
• TXT values are quoted for you — paste the value exactly as shown, without adding quotes.
• Leave TTL on Auto.
• Everything needed works on Cloudflare's free plan.

AWS Route 53

Route 53 → Hosted zones → your domain → Create record.

• Leave the record name blank for records on the domain itself — Route 53 shows the resulting full name beneath the box.
• For MX, the value is the whole line including priority: 10 mail-host.
• Multiple values for one record go on separate lines inside the same value box, not as separate records.
• Check you are editing the public hosted zone. A private zone for the same domain looks identical and has no effect on mail.

Hostinger

hPanel → Domains → DNS / Nameservers → DNS records.

• Pick the record type from the row of tabs above the form.
• Delete Hostinger's default MX records pointing at their own mail service before adding ours.
• Use @ in the Name field for records on the domain itself.
• If your nameservers aren't Hostinger's, this page has no effect — make the changes wherever they point.

BigRock

Manage Orders → your domain → DNS Management → Manage DNS.

• Each record type has its own tab across the top. SPF, DKIM and DMARC all go under the TXT tab.
• Leave Host Name blank for records on the domain itself.
• Remove the default MX records BigRock adds to new domains.
• Long TXT values are accepted in full — do not split the DKIM key across several records.
• DNS Management only appears if you're using BigRock's nameservers.

Squarespace

Domains → your domain → DNS → DNS settings. This is where Google Domains moved, so if you are looking for the old Google interface, you are in the right place.

• Scroll to Custom records and choose Add record.
• Remove any existing MX records, but leave records for Squarespace's own website services alone.
• MX priority goes in its own field, separate from the hostname.
• Records save as you add them — there is no separate confirm step.

Any other provider

Look for a section called DNS, DNS Zone, Zone Editor, Advanced DNS or Name Servers. The records are the same everywhere; only the labels change.

• If @ is rejected for the domain itself, try leaving the field blank.
• If TXT values come back with visible quote marks around them, remove the quotes you typed — the provider adds its own.
• If a value is rejected as too long, that is the DKIM key. Contact us rather than shortening it.
• Delete MX records pointing at a previous mail provider before adding ours.

Five things that break it

Ordered by how often they come up. If a record still reports as pending an hour after you saved it, the cause is almost always one of these.

1. The domain got typed twice

Most providers append your domain to whatever you put in the host field, so entering the full name creates the record somewhere that does not exist. Enter only the part before your domain — dkim._domainkey, not dkim._domainkey.yourdomain.com.

2. Cloudflare's proxy is switched on

An orange cloud means Cloudflare answers for that name, so we cannot read what is actually published. Switch each mail record to DNS only — the grey cloud.

3. The DKIM key got cut short

The DKIM value runs to several hundred characters. Selecting it by hand usually misses the end, and a key missing its last characters fails in exactly the same way as a wrong one. Use the copy button on the DNS screen, and check the pasted value still ends in AQAB.

4. There are two SPF records

A domain may publish only one. If you already send through another service, do not add a second — merge ours into the record you have, keeping a single v=spf1 at the front and one all at the end. Receiving servers treat two SPF records as an error and fail both.

5. Strict SPF set before the move

-all tells recipients to reject anything not on the list. Set it while your mail still flows through your old provider and their messages start bouncing outright rather than landing in spam. Use ~all until your MX has moved and mail is arriving normally, then tighten it.

Still stuck? Email support@nevtan.com with your domain name and a screenshot of your provider's DNS page — the DNS screen shows us what is visible from the outside, so we can usually spot the difference from there.