Email channel

The email channel works with no account anywhere. Outbound is SMTP submission to a relay you already have, inbound arrives from the MTA on your own box, and fikadesk generates and holds the DKIM keys. DKIM is signed by fikadesk, not by your relay, so the signature survives you swapping relays.

A workspace sends and receives at <email key>@<domain>, where the email key is twelve Crockford base32 characters generated per workspace. Adding a domain is the step that makes a customer address usable: the wizard generates a DKIM selector and keypair and writes the five records to publish.

Add a domain

Create the domain through the settings screen or the API. The API route is POST /api/email/domains, with a purpose of sending or receiving. A receiving domain claims the address globally, so no other workspace can receive mail for it.

curl -X POST http://127.0.0.1/api/email/domains \
  -H 'content-type: application/json' \
  -H 'x-fikadesk-workspace: <workspace-id>' \
  -H 'authorization: Bearer fk_<key>' \
  -d '{"domain":"acme.example","purpose":"receiving"}'

The five DNS records

Creating the domain writes one row per record, so the wizard can say which of the five is wrong rather than asking you to re-check them all. The DKIM selector is fd plus six hex characters, generated at creation.

DKIM

The private key never leaves the database; it is sealed with AES-256-GCM under a subkey of FIKADESK_EMAIL_SECRET, and the outbound MIME builder is its only reader. The public key goes in the TXT record above.

SPF

SPF is never a record to paste. fikadesk gives you one mechanism to add inside the v=spf1 record your domain already publishes, because a domain may only have one such record and a second makes every SPF check return permerror. When FIKADESK_EMAIL_SPF_INCLUDE is set, the mechanism is include:<token>; otherwise it is the FIKADESK_EMAIL_EGRESS_IPS addresses written as ip4: or ip6:.

v=spf1 include:_spf.google.com include:<fikadesk include> ~all

DMARC

DMARC is reported and never required. Any v=DMARC1 record counts as found, and the policy it names is surfaced in the domain row, so you can see whether a reject policy is quarantining mail without being asked to publish one.

Verification

The scheduled check looks up every record together, then marks the domain verified when each required record is found. A failed check counts against the domain; it moves to unverified only after three consecutive misses, because a DNS blip that stopped a customer's support mail on the first would be fikadesk's outage rendered as your misconfiguration.

An unverified domain keeps sending for twenty four hours. sendableUntil is computed rather than stored, so the grace period has one definition and cannot drift.