DKIM, SPF, DMARC and BIMI explained

Four acronyms, wildly different importance. Solstral ranks them for you in Settings → Email rather than presenting four equal-looking chores, but it is worth knowing what each one actually does.

DKIM — required

DKIM cryptographically signs every message you send, so a receiving server can prove it genuinely came from your domain and was not altered in transit. This is the one that matters most, and nothing sends from a domain until its DKIM records resolve. Solstral sets this up when you turn on sending; you publish three CNAME records.

SPF — recommended

SPF lists which servers are allowed to send for a domain. Out of the box your mail is already SPF-authenticated, but against Amazon's domain rather than yours — which means SPF does not align with the address recipients see, and DMARC has only DKIM to rely on.

Turning on the bounce address option fixes that. It sets up a dedicated subdomain (bounce.yourdomain.com) as the technical sender, so SPF lines up with your From address and DMARC can pass on either signal instead of one. It needs two records on that subdomain: exactly one MX record and one TXT record.

Two things worth knowing. The subdomain must have exactly one MX record — Solstral checks before setting anything up and tells you if there are already others. And this only ever touches a dedicated subdomain, never your root domain, so it cannot disturb the SPF record covering your everyday business email.

DMARC — recommended, and yours to own

DMARC tells receiving servers what to do with mail claiming to be from you that fails authentication: nothing (p=none), treat it as suspicious (p=quarantine), or reject it outright (p=reject).

Solstral reads your DMARC record and explains what it means, but never publishes or changes it. That is deliberate: your DMARC policy governs every system that sends as your domain — payroll, invoicing, your own mail — not just Solstral. Getting it wrong breaks all of them at once.

If you have no record, Solstral offers a p=none starting point to copy. That monitors without changing how any of your mail is handled, so it is safe to publish today. Move to quarantine, then reject, once your reports look clean.

A trap worth knowing about: a sending subdomain such as mail.yourbrand.com almost never has its own DMARC record — it inherits the one on yourbrand.com. And if that record includes an sp= tag, that tag governs subdomains instead. So you can be at p=reject on your root domain and effectively unprotected on the subdomain you actually send from. Solstral says which record it found and where, so this is visible rather than something you discover later.

BIMI — optional

BIMI displays your logo beside your emails in supporting inboxes. It is purely cosmetic — it does not improve deliverability — and it has a strict chain of prerequisites, which is why Solstral treats it as an extra rather than a step.

You need, in this order: DMARC at quarantine or reject covering all of your mail (a partial pct= does not qualify, and this is the usual reason a BIMI setup silently never appears); a square logo in the restricted SVG Tiny P/S format, which a normal export from a design tool will not satisfy; and, for most providers, a certificate.

On certificates: Gmail shows a logo with either a VMC or a CMC and reserves its verified checkmark for a VMC, which requires a registered trademark and costs a meaningful annual fee. A CMC does not require a trademark. Yahoo is the most permissive and will show a logo without a certificate at all, given DMARC at enforcement. Solstral validates your logo and builds the record; certificates are always something you obtain yourself.