Email

Every Floot app can send and receive email through Floot's own mail service — no provider account and no API key. Ask your assistant for the feature ("email me when someone books", "let customers write to support@") and it wires it in. This page covers what you set up yourself, and the limits worth knowing.

Verify a sending domain before you go live

Until your project has a verified sending domain, your app's mail goes out from Floot's shared domain, and anything addressed to someone other than you is delivered to you instead, with [target: …] in front of the subject and a notice in the body explaining why. That is handy while you test and wrong for a live app: nothing errors, so it is easy to miss that no customer ever received a signup email. Bulk sends are refused outright until a domain is verified.

Before then, mail leaves from noreply@emailservice.floot.com under the display name your app set, from the preview as well as from the published app. Mail addressed to your own Floot account email arrives normally, with no prefix and no notice.

1. 1

   Open the Email tab

   Open your project on floot.com, go to Services → Email, and click Add email domain. Adding a domain requires a paid plan.

2. 2

   Enter the domain to send from

   If your main domain already serves your website or has mailboxes, use a subdomain such as mail.yourdomain.com — Floot suggests one when it spots a likely conflict. Your app can then send from any address at that domain.

3. 3

   Add the DNS records

   Set up automatically connects to your DNS provider and adds the records for you; Set up manually shows them so you can copy them yourself. Verification usually takes minutes but can take up to 24 hours, and Floot keeps checking while the Email tab is open.

   Sending needs five records: three DKIM CNAME records, one SPF TXT record, and one DMARC TXT record, all on or under the name you entered. None of them is an MX record, so mailboxes you already have on that domain keep working. A floot.app address cannot be a sending domain.

Send from an address at the verified domain

Verifying a domain does not change the address your app sends from. Floot looks at the From address of each email: if it is at your verified domain, the email goes to its real recipient. If it is at any other domain, including a placeholder address the app started with, it still leaves from Floot's shared domain and still lands in your own inbox. If mail keeps coming to you after verification, ask your assistant to change the From address to one at the verified domain, exactly as you entered it (mail.yourdomain.com and yourdomain.com are different domains here).

If verification does not finish

The domain shows Verifying DNS until all three DKIM records can be looked up. One missing or mistyped record is enough to keep it there.

• See which record Floot is still waiting for. Click Check DNS records on the domain in the Email tab (or View DNS records in its ⋮ menu). Each record is marked Found, Missing, Wrong value or Wrong name, and the window names the nameservers that answer for your domain. Records only count when they are added at the provider that runs those nameservers, which is not always where you bought the domain.
• On Cloudflare, turn the proxy off for the DKIM records. Set each of the three CNAME records to DNS only (the grey cloud).
• Keep one SPF record and one DMARC record per name. If the name already has an SPF TXT record, add include:amazonses.com to it instead of publishing a second one. Two DMARC records on the same name cancel each other out.
• Restart the check once the records are right. If the setup window says it is taking longer than usual, click Restart verification, then check the records it shows against your DNS once more, in case they changed.
• Not sending: verification stopped. The mail service checks a new domain's DKIM records for about three days, then stops and does not look again by itself, however correct your DNS is now. Put all three records in place, then click Restart verification on the domain in the Email tab.

If a verified domain stops sending

The mail service keeps checking the DKIM records after verification. If they disappear from your DNS, the domain shows Sending: DKIM records missing: email still goes out for about three days, then the domain turns to Not sending: verification failed and every email from it is refused. Click Check DNS records to see what is missing, add it back at your DNS provider, and use Fix DNS records if the domain has stopped sending.

A deliverability checker that reports SPF as "not aligned" is describing normal behaviour: mail sent through Floot passes DMARC on its DKIM signature.

Changing your DMARC policy

Floot sets up your domain's DMARC record as p=none, which only reports: mail that claims to come from your domain but fails SPF and DKIM is still delivered. If your domain already has a valid DMARC record when you set up email automatically, Floot keeps it instead of writing p=none over it.

To make it stricter, for example because verified brand logos (BIMI) need it, open the domain's ⋮ menu in the Email tab and choose DMARC policy. The window shows the DMARC record in your DNS now and offers Report only (p=none), Quarantine (p=quarantine: failing mail goes to spam, which is enough for BIMI) and Reject (p=reject: failing mail is refused). Update automatically connects to your DNS provider and changes only the policy of the record that is there, keeping its other settings. The item appears once the domain is verified, for people who can manage domains.

• Check your other senders first. Before you switch to quarantine or reject, make sure every other service that sends as your domain, such as Google Workspace or a newsletter tool, passes SPF or DKIM for it. Floot's own mail does. Mail from a service that does not goes to spam or is refused.
• Domains set up automatically: use the button. At some DNS providers, editing by hand one of the records an automatic setup added switches off the whole setup, your website's records included. Update automatically changes the record without that.
• Changing it by hand. The window also shows the record to copy. Edit the existing TXT record at _dmarc rather than adding a second one: two DMARC records cancel each other out, and the window says so when it finds more than one.

Receiving email

Your app can also receive email at its domain — a support inbox, replies to notifications, mail that turns into tasks. Sending has to be verified first. Then open the domain's ⋮ menu in the Email tab, choose Set up receiving emails, and add the one MX record it shows. A subdomain is the safe choice: receiving on your root domain takes over mail for any mailboxes already there. When your domain already receives mail somewhere else, Floot names that provider and suggests a subdomain such as mail.yourdomain.com.

Your assistant writes the code that handles incoming mail. Mail that the spam or virus scan flags is never handed to it; it shows in the Email tab as rejected, with the reason.

A received email marked Not handled was received and kept, but your app has no code for incoming mail yet, so it was not passed on. Ask your assistant to handle incoming email, and publish if your app is live. The emails waiting there are then passed to your app automatically within about 6 hours.

There is no inbox

The Email tab is a log, not a mailbox. It lists what arrived and what happened to it, but floot.com has no screen to read mail in, write a new message, or reply. If you want that, ask your assistant to build it into your app: an inbox page that stores incoming mail in your database and sends replies from your domain.

Limits and cost

1,000 emails a day

Per project, counted separately for the preview and the published app, per UTC day, on every plan. If a legitimate app needs more, contact support.

Bulk sending

For the same email to many people, your assistant uses a bulk send: one template, up to 200 recipients per call, with per-recipient details and unsubscribe headers. It is paced by the mail system, so a long list takes a while.

Cost

Email is metered as hosting usage: about $0.30 per 1,000 emails sent and $0.40 per 1,000 received.

Bounces and delivery status

The Email tab keeps a log of what your app sent and received. Your app can also read the status of the email it sent — delivered, bounced, complained, or rejected — for 30 days after each send. That is not a permanent history: if you want a record, such as a per-contact bounce flag, ask your assistant to save it in your app's own database.

In the log, each sent email shows one of these statuses:

Sent is not proof of arrival; Delivered is the status to look for. Sent mail stays in the log for 30 days, and mail from the preview and from the published app is listed together.

Sending health

The Email tab's Sending health row, under Email logs, says whether your project's sending is normal, at risk or paused. Open it to see the project's hard-bounce rate and spam-complaint rate over the last 30 days, each beside the policy line (under 4% and under 0.08%). They are counted the same way as the daily check that emails you, so the tab shows a rate as over the line exactly when you would get that email. Links under each rate open the log filtered to the bounced emails or the complaints.

A rate only counts once there is enough mail for it to mean something: the bounce rate from 100 emails in 30 days, the complaint rate from 3 complaints. Below that the tab shows the numbers so far but does not hold them against the policy. The row appears once your project has an email domain or has sent email in the last 30 days.

The pane also shows what the email service itself reports for a project with its own email domain: whether its sending is paused, and whether its mail is affecting its sender reputation. A paused project's email is refused, and the domain's chip in the Email tab says so; contact support to have it reviewed. If the email service cannot be asked, the pane says the state could not be read rather than guessing.

An address that bounced is blocked

Because the mail system is shared, an address that hard-bounced is blocked for every Floot app, and sends to it are refused without being attempted. If the address works now — say the mailbox was just created — open that email in the Email tab's log, click Allow sending to <address> again, and send it again. You can do this once per address every 30 days, and five times a day per project. An address blocked because its owner marked your mail as spam needs support.

Sharing a domain with your other projects

A verified domain belongs to one project, but other projects you own can send from it too: open the domain's ⋮ menu and choose Share with project…. Their mail goes out under that domain's reputation and appears in the owning project's email log; receiving stays with the owning project. The share stops working if the two projects end up with different owners.

If adding a domain fails because it is already verified for email in another project, that project holds it. When that project is yours, the message names it: either share the domain from it as above, or remove it there (⋮ → Disable email) and add it here. If you deleted the project that held it, just add the domain to the new project: Floot moves it over, and the DNS records you already published keep working.

Using your own provider

Floot email is optional. If you already use Resend, SendGrid, Mailgun, Postmark, Amazon SES, or Mailchimp, your app can use that instead — see Connecting external services.

The two do not mix on their own. Floot's mail service sends only from domains verified in the Email tab, with the records Floot shows. A domain that carries only another provider's records is sent from through that provider's API, with your own key.