A self-hosted tool that sends notification emails needs three DNS records, SPF, DKIM and DMARC, that prove those emails really came from your domain. Without them, mail providers treat the message as unverified and often bin it. Running your own mail server to send it is almost always the wrong answer; a transactional email provider, correctly configured, is the practical one.
This page is one part of a larger guide. For the whole subject in one place, see self-hosting a feature request board.
Why does email even matter for a self-hosted tool?
Most self-hosted tools eventually need to send something: a notification that someone replied, a password reset link, a digest of activity. The moment a tool sends mail from your domain on your behalf, deliverability stops being someone else's problem. A hosted product solved this once, for every customer, on a domain and IP reputation it has spent years maintaining. Self-hosting hands that job back to you, one domain at a time.
Not every self-hosted tool needs this from day one. Docket's free edition sends no email at all, so there is no SMTP server anywhere in its runtime, which is static files plus two small endpoints. The paid tiers add email notifications, voter notifications, and Slack and Discord alerts, and that is the point at which this problem becomes real for a Docket site too.
Fider, the best-known self-hosted feature request board, is more direct about it: its own setup instructions list "your own SMTP or Amazon SES" as a requirement, alongside Docker and PostgreSQL. There is no version of Fider that avoids the decision.
What do SPF, DKIM and DMARC actually do?
All three are DNS records, not settings inside the mail server itself, and a receiving mailbox checks all three independently before deciding whether your message looks legitimate.
| Record | What it is | What it proves | What breaks without it |
|---|---|---|---|
| SPF | A DNS text record listing which servers are allowed to send mail for your domain | The message came from a server you actually authorised | Any server can claim to send as your domain, and receivers have no way to check, so genuine mail looks the same as spoofed mail |
| DKIM | A cryptographic signature attached to each message, checked against a public key published in DNS | The message was not altered in transit and was signed by a holder of your private key | There is nothing to verify the message's integrity, so a forwarded or modified copy is indistinguishable from the original |
| DMARC | A DNS record stating what a receiving server should do when SPF or DKIM fail, and where to send reports about it | Your domain has an explicit policy for unauthenticated mail, rather than leaving it to each receiver's guess | Every mailbox provider applies its own judgement to failures, inconsistently, and you get no visibility into who is sending mail claiming to be you |
Get all three right and a receiving mailbox has a consistent, checkable reason to trust the message. Get one wrong and the message is not necessarily rejected outright, but every provider now has a plausible reason to route it to spam instead of the inbox, which for a notification email is functionally the same as it never arriving.
Should you run your own mail server?
Almost always no. The DNS records are the easy part; the difficulty is what happens after the message leaves your server. A new sending IP has no history with any mailbox provider, and providers judge unfamiliar senders harshly by default. Address ranges from common cloud hosts frequently arrive at a receiving server already carrying a poor reputation from other tenants on the same range, entirely outside your control. Building a clean sending reputation from nothing takes sustained, careful sending, and a single mistake, an open relay, a compromised script, a burst of retried notifications, can undo weeks of it.
None of that is specific to self-hosting a feature request board or a support tool. It is true of running a mail server for any purpose, which is exactly why almost nobody who is not in the business of sending email chooses to run one.
What does a transactional email provider cost?
A transactional email provider sends mail on your behalf using infrastructure and a domain reputation it already maintains at scale. You still publish the SPF, DKIM and DMARC records, pointed at the provider's servers instead of your own, but you are no longer responsible for the reputation underneath them.
The most honest published number for this line item comes from UserJot's own costing of a self-hosted Fider deployment, in a comparison page arguing against self-hosting: transactional email runs $10 to $35 a month, as one component of a total infrastructure bill they put at $70 to $125 a month before any engineering time. That range covers the gap between a low-volume tool sending a handful of notifications a day and one sending enough that a provider's free allowance no longer covers it.
One payment, no subscription, unlimited products.
How do you test deliverability before you rely on it?
Do this before a real customer's password reset silently lands in spam, not after.
Check the DNS records are actually published and correctly formed, using a dig or nslookup lookup against your own domain for the SPF TXT record, the DKIM selector your provider assigned, and the _dmarc TXT record. A typo in a DNS record is invisible until something checks it.
Send a real test message to a real address at each major provider you care about, typically Gmail and Outlook, and open the message headers rather than just the inbox. Both show whether SPF, DKIM and DMARC passed for that specific message, which is a more reliable signal than whether it happened to land in the inbox this one time.
Use one of the free mail-testing services that exist specifically for this: you send a message to an address they generate, and they return a report on your SPF, DKIM, DMARC and general spam-scoring in one pass. Run it after every change to the DNS records or the sending provider, not just once at setup.
What actually breaks if you skip this?
Nothing breaks loudly. That is the trap. Authentication failures do not usually bounce a message back to you with an error; they get silently filed into spam, or delivered late in a batch, or accepted and then never surfaced to anyone. A self-hosted tool with broken email looks, from the operator's side, exactly like a self-hosted tool with working email, right up until a customer says they never got a reply and you go looking.
Patching is the first thing that quietly goes wrong when a team self-hosts a customer-facing tool. Email deliverability is the second, and it gets far less attention because a broken database migration throws an error and a broken DMARC record just makes mail vanish.
Frequently asked questions
Do I need SPF, DKIM and DMARC, or is one enough?
All three, for a self-hosted tool sending real notification email. SPF and DKIM are the two independent checks a receiving server runs on each message; DMARC is the policy that tells the receiver what to do when either check fails, and it is also the only one of the three that gives you visibility into failures through its reporting. Publishing just one leaves the others' gaps open.
Can I use my personal or work email account's SMTP settings for this?
Not for a tool sending on behalf of other people. Consumer and workplace mail accounts are rate-limited, are not built for automated sending, and a support tool's notification traffic can look like exactly the pattern those providers throttle or flag. A transactional email provider is built for this traffic pattern specifically.
Does a static-site self-hosted tool avoid this problem entirely?
Only if it never sends email. Docket's free edition has no SMTP server anywhere in its runtime and sends nothing, so the question does not apply. The moment any self-hosted tool, static or not, adds notification emails, the same SPF, DKIM and DMARC requirements apply regardless of how the rest of it is built.
How long does it take to get SPF, DKIM and DMARC set up properly?
The records themselves are a handful of DNS entries and, for most transactional providers, take an afternoon including propagation time and verification. The part that takes longer is testing: sending real messages to real accounts at the providers you care about and checking the headers, rather than assuming the DNS is correct because it was accepted.
What happens if I get DMARC wrong?
A DMARC record set to reject unauthenticated mail before SPF and DKIM are both reliably passing can cause your own legitimate messages to be rejected outright, which is worse than not having DMARC at all. The safer path is to publish a DMARC record with a monitoring policy first, confirm SPF and DKIM are passing consistently using the reports it generates, and only then move to a stricter policy.