Domains and DNS

A domain is the unit everything else hangs off: mailboxes live on it, sending reputation is earned by it, and outbound access is granted to it. A workspace can hold any number of domains on every plan. The domain page (Domains → the domain) has four tabs: DNS Configuration, Sending, Outbound and Usage.

Claiming and ownership

Adding a domain creates a claim and issues a verification token. Publish it as a TXT record at _foundermail.yourdomain.com, or, if your DNS panel refuses names starting with an underscore, as a TXT record on the domain itself. Until the token is found:

  • the domain is not yours as far as FounderMail is concerned, and other accounts may hold claims on the same name;
  • no mail is accepted for it, whatever the MX record says;
  • mailboxes can be created on it, but they receive nothing.

The first account to publish its token keeps the domain. Other claims on the same name are marked failed and their mailboxes disabled. The token is never reused, so a domain that is removed and added again gets a new one.

Receiving

Receiving needs two records, plus one that every large provider expects:

TypeNameValuePriority
MX@smtp.foundermail.mx10
TXT@v=spf1 include:foundermail.mx ~all—
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com—

Verification checks ownership first, then the MX record. It succeeds when smtp.foundermail.mx is among the domain's MX records. The DNS Configuration tab also reports things verification does not gate on but you should know about: other MX records that will keep taking part of your mail, an SPF record without our include, a second SPF record (only one is allowed by the standard), and a missing DMARC record.

Checks run every ten seconds while the domain page is open and can be triggered with Verify domain. A lookup that fails on our side is reported as "could not check", never as a missing record.

SPF

If the domain already sends through another service, keep that service's include and add ours: v=spf1 include:foundermail.mx include:_spf.example.com ~all. A domain may have only one SPF record; a second one causes receivers to apply neither.

DMARC

The suggested record is monitor-only (p=none) and sends aggregate reports to dmarc@yourdomain.com. Create that mailbox if you want the reports. Once the reports show only legitimate mail for a couple of weeks, move to p=quarantine and later p=reject. Never publish two _dmarc records.

Sending

Sending is enabled per domain from the Sending tab and is separate from receiving. Enabling it registers the domain with the delivery provider and issues records that are unique to your domain, so they are not printed here; copy them from the page.

TypeNameValuePurpose
CNAME × 3<selector>._domainkeyissued per domainDKIM. Lets us sign mail with a key published under your domain, so receivers can verify it came from you.
MXbounceissued per domainBounce subdomain. Delivery failures come back to the provider and are handled.
TXTbouncev=spf1 include:amazonses.com ~allSPF for the bounce subdomain, so the envelope sender aligns with your domain.

Verify DNS on the Sending tab asks the provider for each record's status. Sending is verified when the three DKIM records are found; the bounce records are recommended and are not a condition. Until sending is verified, mailboxes on the domain cannot send from the dashboard or over SMTP.

Outbound access

A domain verified for sending starts in reply-only mode: it can answer any address that has written to one of its mailboxes, and nothing else. The Outbound tab shows the state and has the request form. The full rules, what is checked and what happens to a refused message are in Sending and outbound access.

The Cloudflare one-click setup

When the domain's name servers are Cloudflare's, the domain page offers to write the records for you. It needs an API token that can edit the zone's DNS:

  1. In Cloudflare, open My Profile → API Tokens → Create Token and use the Edit zone DNS template.
  2. Under Zone Resources, include the domain, then create and copy the token.
  3. Paste it on the domain page. FounderMail lists what it would add and what it would remove (other MX records, a conflicting record at a name we need), each with a checkbox. Untick anything you want left alone, then apply.

The token is used for that request only and is not stored. Records belonging to other services are left alone unless they are MX records, which would keep taking your mail.

Provider notes

The domain page detects the DNS provider from the name servers and writes record names the way that provider's form expects: @ for the domain itself, _foundermail rather than _foundermail.yourdomain.com where the panel appends the domain, and MX values with priority and host in one field where required. A "copy all as zone file" button gives the records in zone-file form for providers that import one.

Statuses on the domains list

StatusMeaning
PendingClaimed; ownership or MX not yet found.
VerifiedOwnership proved and MX pointing at FounderMail. Mail is accepted.
FailedAnother account proved ownership of this name first. Mailboxes on this claim are disabled.
SuspendedSuspended by FounderMail; mailboxes cannot be added. Contact support.
Sending: Not enabled / Pending / VerifiedWhether the DKIM records have been issued and found.
Outbound: Reply only / Requested / Approved / SuspendedWhether the domain may write to addresses that have not written first. See Sending.

Removing a domain

Deleting a domain deletes its mailboxes and their messages. Point the MX record elsewhere and copy the mail out over IMAP first if you need it.

Say hello

Say hello

A question before you sign up, or something that is not working: write it here and a person answers by email.

A person answers by email, usually within a day.