SPF DKIM DMARC setup: mail that lands in inboxes
"Why does my own business email go to spam?" is rarely about anything you wrote. It's about three DNS records nobody told you to set up: SPF, DKIM and DMARC. With them, mailbox providers can verify your mail is really yours; without them, a perfectly legitimate message is — to an automated filter — indistinguishable from someone forging your name.
Three records, three different jobs
SPF — who may send as you — a TXT record published at your domain listing the mail servers allowed to send email claiming to be from you. A receiving server checks the actual origin against the list; a mismatch is a strong signal — though not on its own an instant rejection — that the message might not really be yours.
DKIM — proof nothing was tampered with — the sending server cryptographically signs each message with a private key only it holds; the matching public key is published in your DNS. A valid signature proves both that a holder of your key sent the message and that nothing was altered in transit after signing.
DMARC — the policy that ties them together — states whether SPF and DKIM must align with the domain in the visible "From" address, tells receiving servers what to do when a message fails both checks (nothing, quarantine, or reject), and asks for periodic reports on what's being sent under your name, pass or fail.
Where these records actually come from
1
Know what actually sends your mail
Not your website host — whichever mailbox or sending service the message really leaves from: Google Workspace, Microsoft 365, Zoho, Proton, or similar.
2
Publish SPF for that sender
Your mail provider publishes its own exact SPF line in its setup documentation; you paste it into your domain's DNS, in the same panel you use for any other DNS record.
3
Turn on DKIM signing at that provider
Most providers generate the key pair for you and give you the exact DNS record to publish — DKIM setup is provider-driven, not something you construct by hand.
4
Add a DMARC record, starting at monitor-only
Write one DMARC TXT record yourself, starting at p=none, and only tighten it once reports confirm every real sender is passing cleanly.
How Olmira handles this
Per-tenant SMTP is Olmira's answer to exactly this: connect your own mail account for each purpose — transactional, marketing, support, billing and more — so a message genuinely leaves through an account you already control, with the "from" address you set. Your deliverability then rides on the SPF, DKIM and DMARC that account's own domain already has: connect a real business mailbox you already send from, and its existing authentication covers your Olmira-sent mail too.
One rule matters most: set a purpose's "from" address on the same domain the connected account is actually authorised to send from — mismatching the two is the most common cause of a spoofed-looking failure, on any platform. A purpose you leave unconfigured simply falls back to Olmira's own relay rather than failing to send. The rest of what Integrations covers: Integrations.
Technically the mail will send, but a consumer webmail provider's own SPF and DKIM authenticate their domain, not a custom one you put in the "from" field — mail claiming to be from your business domain but sent through somebody else's authenticated servers tends to fail alignment. A real mailbox on your own domain is worth setting up before you need to look credible at scale.
SPF and DKIM are close to mandatory now — several major mailbox providers already require at least one for bulk senders. DMARC is what actually ties the two together and tells receivers what to do on failure; skipping it doesn't break anything immediately, but it's the part that turns "authenticated" into "enforced".
Authentication proves the message is genuinely from you; it doesn't exempt it from ordinary spam filtering. Content, sending volume, recipient engagement and domain reputation all still matter on top of authentication passing cleanly.
The same DNS propagation delay as any other record — see connect domain DNS records for what's actually happening while you wait, and why "not yet" isn't the same as "wrong".
Every genuine sending source — your everyday inbox, a marketing platform, a website contact form — needs to be included in the same SPF record and, where the provider supports it, its own DKIM signature. Missing one out is the single most common reason a legitimate tool starts failing checks after everything "was already set up".