DOCS · GETTING STARTED · QUICK START

Forward your first email in three minutes.

arc-relay is a managed email-forwarding service with an AI auto-reply layer. You point your domain's MX records at us, create aliases, and we handle the rest.

Add your domain

In the dashboard, click "+ Domain" and enter the domain you own. We'll generate the DNS records you need to add.

Update DNS

Add three records at your registrar — MX, TXT (SPF), and TXT (DKIM). Most registrars apply changes within minutes.

◇DNS

ZONE

; you.dev — DNS zone
@        IN MX  10 mx1.arc-relay.com.
@        IN MX  20 mx2.arc-relay.com.
@        IN TXT "v=spf1 include:_spf.arc-relay.com ~all"
arc._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0…"

Verify and create your first alias

Once verification clears (we ping your DNS every 30 seconds), create an alias and point it at your real inbox.

Send a test

Email [email protected] from any account. It should land in your real inbox within a couple of seconds, with the original sender preserved.

◇Next steps

◇ 01

Set up AI Auto-Reply

Calibrate the assistant on five sample replies

◇ 02

Add routing rules

Move invoices, alerts, and noise out of your inbox

◇ 03

Connect the API

Provision aliases programmatically

DOCS · GETTING STARTED · CORE CONCEPTS

The pieces, in plain English.

Skim this once and the rest of the docs read faster. Each term below is something the dashboard, your DNS zone, or a log line will mention by name.

◇

Aliases

A receiving address on your domain — [email protected], [email protected], [email protected] — that you map to a real inbox. Create as many as you need. Each one is independent and can be paused, renamed, or deleted without touching the others.

◇

Catch-all

Forwards every address on your domain that isn't already an explicit alias. Useful for one-off signups ([email protected], [email protected]) without pre-creating each one. You can blocklist specific patterns on the rules page if a particular address starts attracting noise.

◇

Reply-from-domain

When you reply through arc-relay, the outgoing message is sent from your domain — not your real inbox. The recipient sees [email protected], the message is DKIM-signed by your domain, and your real address never leaks. Conversations stay on your brand even when you're answering from Gmail.

◇

ARC and SRS

Two pieces of plumbing that keep forwarded mail authenticating at the recipient.

SRS (Sender Rewriting Scheme) rewrites the envelope sender so SPF still passes when we relay. Without it, forwarded mail fails SPF at the recipient and gets dropped or quarantined.

ARC (Authenticated Received Chain) is a signed record of the original SPF/DKIM result before we touched the message. ARC is what tells the recipient that the message was legitimate at the source — even though the IP and Return-Path changed in transit.

◇

DKIM (per-domain)

We sign every outgoing message with your domain's private DKIM key. The matching public key sits in your DNS at arc._domainkey. That signature is what proves the message really came from a server you authorized — and what survives every hop to the recipient. Each domain you add gets its own key; nothing is shared across customers.

◇

DMARC alignment

When your domain has a DMARC policy, both SPF (via SRS) and DKIM (via your domain key) align with the From: header. That alignment is the only reason forwarded mail consistently reaches the inbox at the major receivers. If you don't have a DMARC record yet, start with p=none while you confirm signing is healthy, then tighten it.

DOCS · HELP · TROUBLESHOOTING

When something isn't right.

The handful of things that actually go wrong, what each one looks like, and the fix.

Domain stuck on "verifying"

We poll DNS every 30 seconds and verify within a couple of minutes once the records are live. If it's been more than ten minutes, check that the records were saved at the apex (@ or your bare domain), not on a subdomain. If your registrar's UI asks for a host like arc._domainkey, enter it exactly that way — not arc._domainkey.you.dev; the registrar appends your domain automatically.

Forwarded mail isn't arriving

First check logs — every relayed message shows up there with delivery status. If it shows delivered but you don't see it, look in spam or a tab folder. If it shows rejected or deferred, the recipient is likely greylisting, or your domain doesn't have a DMARC record yet. Add a permissive DMARC (v=DMARC1; p=none; rua=mailto:[email protected]) and try again.

Replies are landing in spam

This almost always means DKIM isn't signing. Open domains, find the affected domain, and confirm DKIM shows green. If it's yellow or red, the public key in DNS doesn't match the key we're signing with. Re-copy the DKIM TXT value from the dashboard — some registrars truncate TXT values at 255 characters and need the value split across multiple quoted strings.

AI Auto-Reply isn't triggering

Auto-Reply only runs on aliases that have it explicitly enabled and a calibrated tone. Check auto-reply and confirm the alias is in the active list. By default we draft only — you have to flip a rule (or "auto-send everything") for replies to leave on their own. If a rule says auto-send and nothing's going out, look for ai-skipped entries in logs; the row includes the reason (low confidence, missing tone calibration, attachment present).

Domain health score dropped

The score reflects DNS, deliverability signals, and recent bounce rate. Open the domain detail page and we list each failing check with a fix link. Common causes: a missing DMARC record, MX records reverting after a registrar UI change (their default record can come back during an unrelated edit), or a recent spam complaint. Fix the failing check and the score updates within an hour.

Recipient returns "550 5.7.1 policy"

This is the recipient's mail server rejecting, not us. Almost always it's because your domain is in p=reject mode but DKIM isn't aligned, or the recipient demands DMARC and you haven't published one. Add a p=none DMARC record, confirm DKIM is green on the domains page, then re-tighten the policy once you see clean reports for a few days.

◇ STILL STUCK

We answer support directly.

If the fix above didn't resolve it, email [email protected] with the affected domain and a recent log timestamp. We answer most threads inside a few hours.

DOCS · SECURITY · DNS RECORDS

Every DNS record you need.

Copy these into your registrar's DNS zone editor. We'll generate the values for your domain; just swap in the ones shown on the dashboard.

◇

MX (Mail eXchange)

Points your domain's incoming mail to arc-relay. Add both records with the exact hostnames shown.

Host: @ (or your domain)

@  IN MX  10  mx1.arc-relay.com.
@  IN MX  20  mx2.arc-relay.com.

◇

SPF (Sender Policy Framework)

Tells receivers that arc-relay is authorized to send mail on behalf of your domain. Enables SRS rewriting to pass SPF.

Host: @

@  IN TXT  "v=spf1 include:_spf.arc-relay.com ~all"

◇

DKIM (DomainKeys Identified Mail)

Cryptographically signs messages sent from your domain. The public key proves to receivers that messages really came from you.

Host: arc._domainkey

arc._domainkey  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDj..."

The value shown in the dashboard is the complete public key. If your registrar truncates at 255 characters, split it into multiple quoted strings: "part1" "part2"

◇

DMARC (Domain-based Message Authentication)

Sets a policy for how receivers should treat mail that fails SPF or DKIM. Start with p=none to observe without rejecting.

Host: _dmarc

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Three policies: p=none (observe only), p=quarantine (flag suspicious), p=reject (hard fail). Once you confirm DKIM and SPF align, move from none to quarantine, then reject.

DOCS · EMAIL API · AUTHENTICATION

API key setup in three steps.

Generate a persistent key from your account and use it in the Authorization header on all API requests.

Go to Settings → API Keys

Log in to your dashboard. Under Settings, choose API Keys. Give the key a name (e.g., "CI pipeline", "mobile app") and click Create.

Copy the key immediately

We only show it once. Copy the full value (starting with ar_live_) and store it in your password manager or CI/CD secrets. Never commit it to version control.

Use it in the Authorization header

Pass the key as a Bearer token on every request:

Authorization: Bearer ar_live_your_key_here

◇ API QUOTAS

Monthly request limits by plan: Free 100 · Pro 5,000 · Business 50,000 · Enterprise custom. Check your usage on the Settings page. Requests reset on the first of each month.

DOCS · EMAIL API · ENDPOINTS

REST endpoints for alias management.

Programmatically create, read, update, and delete aliases on any of your domains.

◇

List aliases

Fetch all aliases for a domain.

GET https://arc-relay.com/api/domains/:domain/aliases
Authorization: Bearer ar_live_...

# Response (200 OK)
{"aliases": [{"address": "[email protected]", "destination": "[email protected]", "active": true}]}

◇

Create an alias

Add a new forwarding address on your domain.

POST https://arc-relay.com/api/domains/:domain/aliases
Authorization: Bearer ar_live_...
Content-Type: application/json

{"address": "[email protected]", "destination": "[email protected]"}

# Response (201 Created)
{"address": "[email protected]", "destination": "[email protected]", "active": true}

◇

Delete an alias

Permanently remove a forwarding address. This cannot be undone.

DELETE https://arc-relay.com/api/domains/:domain/aliases/:address
Authorization: Bearer ar_live_...

# Response (204 No Content)

◇ RATE LIMITS

100 requests per 10 seconds per API key. Exceeding the limit returns 429 Too Many Requests. Respect the Retry-After header if you hit the limit.

DOCS · EMAIL API · WEBHOOKS

Real-time callbacks for email events.

Get HTTP POST requests when mail is forwarded, bounced, or blocked. Useful for alerting, logging, and workflow triggers.

Create a webhook endpoint

Go to Settings → Webhooks and add the URL where you want to receive callbacks (e.g., https://your-app.com/webhooks/arc-relay). You can register up to 10 endpoints per account.

Webhook events

We send events as soon as they happen: email.forwarded (success), email.bounced (rejected), email.blocked (rule blocked).

Payload signature

Every webhook is signed with HMAC-SHA256. Verify the signature by computing sha256(body, secret) and comparing to the header:

X-ARC-Relay-Signature: sha256=abc123def456...

{"event": "email.forwarded", "domain": "you.dev", "from": "[email protected]", "to": "[email protected]", "timestamp": "2026-05-01T14:23:45Z"}

Your webhook secret is shown in Settings → Webhooks. Reject unsigned or mismatched webhooks.

◇ RETRIES

Failed deliveries (non-2xx response) are retried up to 3 times with exponential backoff: 5 seconds, 5 minutes, 30 minutes. After 3 failures, the endpoint is disabled. Re-enable from Settings.

DOCS · INTEGRATIONS

Connect your workflow.

Use webhooks or the API to tie arc-relay into your existing toolchain.

◇

GitHub Actions

Use the API to provision project-specific email aliases in your CI/CD pipeline. Store your API key in GitHub Secrets.

- name: Create project alias
  run: |
    curl -X POST https://arc-relay.com/api/domains/you.dev/aliases \
      -H "Authorization: Bearer ${{ secrets.ARC_RELAY_API_KEY }}" \
      -d '{"address":"proj-${{ github.run_id }}@you.dev"}'

◇

Webhook alerting

Post webhook events to Slack, PagerDuty, or a custom alert system. Example Node.js receiver:

app.post('/webhooks/arc-relay', (req, res) => {
  if (req.body.event === 'email.bounced') {
    slack.send(`⚠️ ${req.body.from} → ${req.body.to} bounced`);
  }
  res.sendStatus(200);
});

◇

Audit & logging

Use webhooks to log every mail event to your application database, data warehouse, or log aggregator. Each webhook includes a messageId for correlation.