Skip to main content

Email Channel Setup

Growth plan required

The email channel type is available on the Growth plan and above. Creating an email channel on a plan that does not include it returns 403 with "upgrade_required": true and an allowed list of the channel types your plan permits. To upgrade, visit your billing settings.

Email in Hober is a first-class channel alongside push and in-app. Hober delivers email through SendGrid, authenticated as your sending domain — SPF, DKIM, and DMARC belong to you, not to a shared Hober identity. That means inbox placement depends on DNS records you control, and this guide walks through setting them up and verifying them from the dashboard.

This guide covers creating an email channel, authenticating your sending domain, verifying the DNS records from the per-channel deliverability panel, and the compliance footers Hober adds to outbound email automatically.

1. How email sending works​

Responsibility splits cleanly between you and the platform:

  • You own domain authentication and list quality — who you import and how you got their consent.
  • Hober owns everything after the send button: suppression enforcement, consent checks, bounce and complaint processing, one-click List-Unsubscribe headers, and the feedback loops into your dashboard.

Bounces, spam complaints, and unsubscribes reported back by SendGrid are recorded in a per-tenant suppression ledger and enforced on every subsequent send — see the Deliverability guide for how that ledger works and how to monitor it.

note

SMS and WhatsApp have their own guide: SMS & WhatsApp Setup.

2. Create the email channel​

Dashboard​

  1. Log in to the Hober Dashboard and open Channels from the main navigation.
  2. Start the new-channel wizard and choose Email (SendGrid) as the channel type.
  3. Give the channel a display name (unique per workspace, up to 128 characters).
  4. In the credentials step, paste your SendGrid API key and the verified sender email (the From address you verified in SendGrid). The key is envelope-encrypted on upload and — like every provider credential — write-only: no API or screen returns it, so keep your own record of which key is live. The channel activates on upload.

API​

POST /api/v1/channels
Authorization: Bearer <token>
Content-Type: application/json

{
  "type": "email",
  "name": "Marketing Email"
}

A successful response returns 201 Created with the channel object:

{
  "id": "6f1d2a34-9c1b-4e8a-b0d2-1a2b3c4d5e6f",
  "type": "email",
  "name": "Marketing Email",
  "active": true,
  "status": "pending",
  "created_at": "2026-07-27T12:00:00Z"
}

Then upload the credentials:

POST /api/v1/channels/{id}/credentials/sendgrid
Authorization: Bearer <token>
Content-Type: application/json

{
  "api_key": "SG.your-sendgrid-key",
  "sender_email": "hello@yourdomain.com"
}

Both fields are required (422 names the missing one). A 200 returns the credential metadata (never the key itself) and the channel becomes active.

See the Channels API reference for the full channel object, list/update/delete endpoints, and error responses.

3. Authenticate your sending domain​

Email providers decide inbox-vs-spam largely on whether your domain proves it authorized the mail. Domain authentication is configured in your SendGrid account (SendGrid calls it "Domain Authentication"); SendGrid then gives you a small set of DNS records to publish at your DNS host.

What each record does:

RecordTypePurpose
DKIM 1 and DKIM 2CNAMEPoint to SendGrid-hosted DKIM signing keys. DKIM adds a cryptographic signature to every message that receiving servers verify against your domain — proof the mail wasn't altered and really came from you. Two records allow keys to be rotated without downtime.
Mail CNAMECNAMEDelegates a mail subdomain (the return-path) to SendGrid so bounces route back correctly and SPF aligns with your domain.
SPFCNAME/TXTDeclares SendGrid's servers as authorized senders for your domain. Receiving servers check the connecting IP against this record.

DMARC is a policy record you publish yourself (a TXT record at _dmarc.yourdomain.com). It tells receivers what to do with mail that fails SPF/DKIM alignment and where to send aggregate reports. Start with a monitoring policy (p=none) and tighten once your reports look clean. Hober's own transactional domains run the same SPF/DKIM/DMARC setup we ask of you.

4. Verify authentication from the dashboard​

Each email channel has a Sender domain deliverability panel on its channel detail page ("Verify DKIM and SPF records to ensure emails land in the inbox"). It checks your domain authentication status directly against SendGrid and shows the exact DNS records to verify:

  1. Open Channels, then click your email channel to open its detail page.
  2. In the Sender domain deliverability panel, paste your SendGrid API Key (the SG.xxxx... key from your SendGrid account) and click Check deliverability.
  3. The panel lists every authenticated domain on the SendGrid account with each DNS record — DKIM 1, DKIM 2, Mail CNAME, and SPF — showing the record type, host, and value to publish, and a per-record Verified / Pending status.
  4. Add any Pending records at your DNS host, wait for DNS propagation, then click Re-check. Use Change API key if you rotate the key.

The check runs on demand — it is not a background job, so re-check after any DNS change. An invalid key returns 401 with the message Invalid SendGrid API key — check your credentials. The domain counts as verified only when all of its records validate.

tip

Authenticate before anything else. Sending unauthenticated mail is the fastest way to teach providers to distrust the domain — see warming up a new domain.

5. Built-in compliance footers​

Mailbox providers now expect standards-compliant unsubscribe handling from senders. Hober adds this to outbound email automatically — you do not need to template it yourself:

  • One-click unsubscribe headers. Every email carries a List-Unsubscribe header plus List-Unsubscribe-Post: List-Unsubscribe=One-Click (the RFC 8058 mechanism), so Gmail, Yahoo, and other providers can render their native "Unsubscribe" button. One-click unsubscribes are recorded in your suppression ledger the moment they arrive.
  • A preference footer. HTML bodies get a footer with Manage your email preferences and Unsubscribe links; plain-text bodies get the same two links in text form. Preference links open the hosted preference center, where subscribers manage per-category consent without logging in — the links are individually signed and expire.

The footer is appended to email bodies that Hober renders. If you send through a SendGrid dynamic template, Hober does not inject the footer into the template — include your own unsubscribe and preference links in the template design.

Unsubscribes and preference changes feed the same suppression ledger as bounces and complaints, and suppression is enforced at send time. See Deliverability for the full picture, and Message Personalization for personalizing the email content itself.

6. Event webhook — bounces, spam reports, and unsubscribes​

Hober learns about bounces, spam reports, and list-unsubscribe events through SendGrid's Event Webhook. Without it, those signals never reach your suppression ledger — configure it before sending at scale.

  1. Open your email channel in the dashboard (Platform → Channels → your email channel). The Event webhook panel shows your account's URLs — they embed your workspace and channel IDs, so copy them from there rather than constructing them by hand:
    • Event webhook: https://<api-host>/v1/webhooks/sendgrid/<workspace-id>/events?channel=<channel-id>
    • One-click unsubscribe: https://<api-host>/v1/webhooks/sendgrid/<workspace-id>/unsubscribe
  2. In SendGrid, go to Settings → Mail Settings → Event Webhook, paste the event webhook URL, and enable at least Bounced, Spam Reports, and Unsubscribes.
  3. Enable Signed Event Webhook. SendGrid then shows a Verification Key — copy it back into the Signed webhook verification key field on the same dashboard panel and save. Hober verifies every delivery's ECDSA signature against this key; until it is set, event deliveries are rejected (the endpoint never accepts unauthenticated events).

Processed events land in the same suppression ledger described above and are enforced at send time.