Domain authentication

Before you can send from yourdomain.com, you have to prove you own it. Until you do, sends fail with domain_not_verified.

This is not a formality

Gmail and Yahoo require authentication for bulk senders. Unauthenticated mail doesn’t get penalised — it gets rejected or junked, silently, and you’ll see it as a mysteriously low open rate rather than an error.

Get this right before you send a single production email. It is the single biggest lever on whether your mail arrives.

Set it up

1. Add the domain

   Email → Domains → Add Domain in the dashboard, or:

   curl https://api.9bits.net/email/ng/v1/domains \
     -H "Authorization: Bearer $NINEBITS_EMAIL_KEY"

2. Publish the DNS records

   We give you the exact records. Add them at your DNS provider.

   Type	Purpose
   TXT (SPF)	Authorises our servers to send for your domain.
   TXT/CNAME (DKIM)	Cryptographically signs your mail so it can’t be forged in transit.
   TXT (DMARC)	Tells receivers what to do with mail that fails the checks.

3. Wait for propagation

   Usually minutes; occasionally up to 48 hours depending on your registrar’s TTL.

4. Verify

   curl https://api.9bits.net/email/ng/v1/domains/yourdomain.com \
     -H "Authorization: Bearer $NINEBITS_EMAIL_KEY"

   Once it reports verified, you can send.

What each record does

SPF lists who may send for your domain. Without it, anyone can claim to be you, so receivers distrust the lot.

You get exactly one SPF record

A domain must have one SPF TXT record. Two records is not “extra protection” — it’s a permanent error, and receivers will fail all your mail.

If you already send through another provider, merge the mechanisms into a single record rather than adding a second:

v=spf1 include:_spf.google.com include:spf.9bits.net ~all

DKIM signs each message with a private key; receivers check the signature against the public key in your DNS. It survives forwarding, which SPF often doesn’t — which is why DKIM does most of the real work.

DMARC ties the two together and tells receivers what to do on failure. Start permissive and tighten once you’re confident:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none means “don’t block anything, just send me reports”. Read the reports for a couple of weeks, confirm all your legitimate mail passes, then move to p=quarantine and eventually p=reject.

Don't jump straight to p=reject

p=reject on a domain you haven’t monitored will silently destroy legitimate mail — your invoicing system, your CRM, that one cron job nobody remembers.

Go none → read reports → quarantine → reject. There is no prize for rushing.

Use a subdomain for bulk sending

Send marketing and transactional mail from a subdomain:

mail.yourdomain.com     ← transactional
news.yourdomain.com     ← marketing

Reputation is tracked per-domain. If a marketing campaign gets spam complaints, that damage stays on news. and doesn’t drag down your password resets — or, worse, the CEO’s email from yourdomain.com.

Separating them is cheap now and very hard to retrofit after your root domain’s reputation is burnt.

Suppressions

Hard bounces and spam complaints are added to your suppression list automatically, and we won’t send to them again.

Don’t fight this. Re-sending to a hard bounce is exactly what receivers watch for when deciding whether you’re a spammer. Check the list before importing recipients:

curl https://api.9bits.net/email/ng/v1/suppressions \
  -H "Authorization: Bearer $NINEBITS_EMAIL_KEY"