ReachBellDocs

Domain setup

Before you can send email through ReachBell, the sending domain has to be verified. That means three things have to be true: your domain announces ReachBell as an authorised sender (SPF), every message is cryptographically signed (DKIM), and you have a published policy describing what receivers should do with unauthenticated mail (DMARC).

This page walks you through the verification path — auto-setup for the three big DNS providers we integrate with, manual fallback for everything else.

Why verification matters

Without SPF + DKIM + DMARC properly configured, your messages land in spam, get rejected outright by Gmail's new bulk-sender rules, and tank your domain reputation in days. The hybrid auto-connect flow exists so the typical customer can finish the entire setup in under a minute without copying records by hand.

Two paths, one outcome. Whether you use auto-setup or manual setup, the verified state at the end is identical — same six DNS records published, same SES domain identity, same deliverability.

When you enter your domain in the dashboard, the backend runs an NS lookup to identify your DNS provider. If we detect one of the three providers we integrate with, you'll see a one-click auto-setup option.

Cloudflare

  1. In the dashboard, go to Settings → Email → Set up sending.
  2. Enter your domain — for example vedhoroscope.com.
  3. We auto-detect Cloudflare and offer auto-setup.
  4. Create a Cloudflare API token: in Cloudflare's dashboard, go to My Profile → API Tokens → Create Token. Use the template Edit zone DNS. Restrict the token's zone to the domain you're connecting.
  5. Paste the token into the ReachBell dashboard.
  6. Hit Connect & Setup DNS.

What happens next:

  • We validate the token against Cloudflare's API.
  • We create your SES domain identity (this generates the records that need to be published).
  • We push all six DNS records to Cloudflare via their API.
  • We trigger SES domain verification.
  • A cron job rechecks verification status every five minutes; you receive an email when verification completes — usually within one to five minutes.

You can delete the stored credentials after verification finishes — they're encrypted at rest with AES-256-GCM but the safer state is no credentials stored at all.

GoDaddy

Same flow. We ask for your GoDaddy API key + secret instead of a Cloudflare token. Create the credentials at GoDaddy → Developer Portal → API Keys with the Production environment selected.

Route53 (AWS)

Same flow. We ask for an AWS access key ID + secret access key. The IAM user backing the credentials needs the route53:ChangeResourceRecordSets and route53:ListHostedZones permissions on the hosted zone — restrict the policy scope to that zone.

Manual setup

If your DNS lives anywhere else — your registrar, a different managed DNS provider, your own self-hosted nameserver — pick Manual setup in the dashboard.

You'll see a table of the six records you need to add:

TypeNameValuePurpose
TXT_amazonses.vedhoroscope.comxxxxxxxxSES verify
CNAMEselector1._domainkey.vedhoroscope.comselector1.dkim.amazonses.comDKIM
CNAMEselector2._domainkey.vedhoroscope.comselector2.dkim.amazonses.comDKIM
CNAMEselector3._domainkey.vedhoroscope.comselector3.dkim.amazonses.comDKIM
TXTvedhoroscope.comv=spf1 include:amazonses.com ~allSPF
TXT_dmarc.vedhoroscope.comv=DMARC1; p=none; rua=mailto:dmarc@vedhoroscope.comDMARC

Add each record to your DNS provider's control panel. Copy-buttons in the dashboard let you grab each value cleanly.

Then click Verify Domain. We start polling for propagation and email you the moment all six are visible. We retry every five minutes for up to 24 hours.

DNS propagation can take time. Most records appear within a couple of minutes on modern providers, but full propagation occasionally takes up to 48 hours. The auto-recheck cron job covers the long tail without you needing to refresh the page.

Checking propagation yourself

If you want to verify a record without leaving the terminal:

# SES verification token
dig TXT _amazonses.vedhoroscope.com +short

# DKIM CNAMEs
dig CNAME selector1._domainkey.vedhoroscope.com +short
dig CNAME selector2._domainkey.vedhoroscope.com +short
dig CNAME selector3._domainkey.vedhoroscope.com +short

# SPF
dig TXT vedhoroscope.com +short

# DMARC
dig TXT _dmarc.vedhoroscope.com +short

If a record returns empty, the change hasn't propagated yet. Re-run the lookup a few minutes later, or query a different resolver to rule out local caching: dig @8.8.8.8 TXT _amazonses.vedhoroscope.com.

Troubleshooting

Auto-setup said "credentials invalid". Double-check the API token's scope. Cloudflare tokens must include Zone:DNS:Edit for the specific zone. AWS keys must have route53:* for the hosted zone.

The dashboard shows "verifying" for hours. The most common cause is a typo when copying the SES verification record into a manual setup — confirm the TXT value matches the dashboard byte-for-byte. The _amazonses.<domain> record is the only one that's unique per-customer, so even a small mistake breaks verification.

SPF record conflict. You can only have one TXT record at your apex matching v=spf1. If you already send transactional mail through another provider, merge ReachBell's include:amazonses.com into your existing record instead of adding a second TXT. For example: v=spf1 include:_spf.google.com include:amazonses.com ~all.

DMARC policy too aggressive. Start at p=none (monitoring only), watch the aggregate reports for a few weeks, then move to p=quarantine and eventually p=reject. Skipping straight to p=reject while still tuning your sender domain causes legitimate mail to bounce.

What's next?

Previous

WordPress

Next

Sending emails