Jorbox
Blog / email

Email setup for a small SaaS: SPF + DKIM + DMARC (2026)

· May 17, 2026 · 15 min read

In February 2024 Google began rejecting unauthenticated mail at scale. Microsoft followed in August 2024 with the 550 5.7.26 reject for missing alignment. Yahoo enforced the same a year earlier. If your SaaS is sending password resets, receipts, or onboarding email without SPF, DKIM, and DMARC properly configured, the deliverability rate to Gmail and Outlook is somewhere between 40% and 70%. The math on a SaaS funnel doesn't survive that. This is the 10-step setup we run on every product we ship — including the five SaaS brands jorbox.com operates — to keep deliverability above 99%.

What gets checked when your email lands in Gmail

In 2026 the major mailbox providers (Gmail, Outlook, Yahoo, Apple) run a chain of checks on every inbound message. The four that decide whether your email reaches the inbox vs the spam folder vs the bit bucket:

SPF (Sender Policy Framework) — a TXT record on your domain that lists the IPs and hostnames authorized to send mail "from" you. The receiving server looks up example.com's SPF record and checks: is the connecting server in the allow-list? If not, SPF fails. DKIM (DomainKeys Identified Mail) — every legitimate sender signs each message with a private key. The receiving server fetches the matching public key from a DNS TXT record on your domain and verifies the signature. If the message was tampered with in flight, or if no DKIM signature exists, the check fails. DMARC (Domain-based Message Authentication, Reporting, and Conformance) — a TXT record at _dmarc.example.com that tells receiving servers what to do when SPF or DKIM fails (none, quarantine, or reject). It also requests aggregate reports back to a mailbox you control. Alignment — DMARC requires that the SPF or DKIM signing domain matches the visible "From:" address domain. This is the rule that catches most legitimately-configured-but-still-broken setups.

All four need to pass for the message to be trusted unconditionally. SPF or DKIM alone (without DMARC alignment) means the message lands in spam at Gmail, or gets quarantined at Outlook, or never arrives at Yahoo. The good news: setting up the four checks correctly is a one-time engineering task. Once it is in place, it stays in place — for years.

Where to send transactional email from

Before configuring the authentication, pick the right sending infrastructure. Most SaaS deliverability problems start with sending through the wrong service. Four credible options:

Dedicated transactional email providers: Postmark, SendGrid, Resend, Mailgun, Amazon SES. These are the right choice for everything user-facing (password resets, receipts, magic links). They handle IP reputation, bounce processing, and abuse-report routing. Pricing starts around $15–$30/month for small volumes, scales linearly with sends.

Your hosting account's SMTP server. Most managed-hosting plans include outbound SMTP. This is OK for low-volume operational email (admin notifications you send to yourself) but wrong for user-facing email — shared sending IPs have variable reputation and your messages land in spam at Gmail. Workspace mail (Google Workspace / Microsoft 365). Use these for your team's human-to-human mail. Do not use them for transactional email — the rate limits and bulk-send policies are not built for it. Self-hosted MTA. Running your own Postfix or Exim is technically possible but operationally hostile in 2026. Major mailbox providers treat fresh IPs from non-major networks as untrusted by default; warming a sending IP takes weeks; bounce processing is its own subsystem. Almost never the right choice.

Deliverability rates by configuration (real numbers)

Approximate inbox-placement rates by authentication configuration, observed across the five Jorbox SaaS brands and ~20 client projects in 2025–2026. Numbers vary by recipient mix but the directional picture is consistent.

ConfigurationGmail inboxOutlook inboxApple Mail inboxYahoo inbox None (no SPF, DKIM, DMARC)~30%~40%~60%~10% (mostly rejected) SPF only~55%~70%~80%~40% SPF + DKIM, no DMARC~75%~85%~90%~75% SPF + DKIM + DMARC (p=none)~92%~92%~95%~90% SPF + DKIM + DMARC (p=reject) + aligned signing~99%~98%~99%~99% Above + BIMI + verified VMC~99% with logo in client~98%~99%~99% with logo

The conclusion is unsubtle: "SPF only" is not enough. You need all three plus alignment. The marginal cost of going from SPF-only to full DMARC alignment is roughly one afternoon of DNS work. The marginal benefit is a 20–40 percentage point lift in inbox placement.

The 10-step email authentication setup

Run these in order on a new domain. For an existing production domain, start at step 7 (deploy DMARC in p=none monitoring mode) so you have visibility into your current sending before tightening the policy. Estimated total time: 2–4 hours, plus 2 weeks of DMARC monitoring before flipping to p=reject.

  1. 01

    Inventory every system that sends email "from" your domain

    List every service that ever sends a message with your domain in the From: address. Common entries: your transactional email provider, your CRM (HubSpot, Pipedrive, Salesforce), your marketing email tool (Kit, ConvertKit, Mailchimp, Buttondown, Beehiiv), your support tool (Intercom, Help Scout, Zendesk), your accounting tool (Stripe receipts, QuickBooks invoices), your ATS if you recruit. Each needs to be authenticated, OR not allowed to send "from" your primary domain at all. The single biggest cause of broken setups is forgetting one service. A monthly newsletter that goes through Mailchimp without alignment will tank your domain's DMARC pass rate even if everything else is configured correctly.
  2. 02

    Pick a sending domain strategy

    You have two options. Single primary domain — every service sends from @yourdomain.com. Simple, but every service needs to be authenticated correctly or DMARC fails site-wide. Subdomain segmentation — transactional from @mail.yourdomain.com, marketing from @news.yourdomain.com, your humans from @yourdomain.com. Slightly more complex; isolates reputation so a bad email list cannot tank your password-reset deliverability. For SaaS over ~50K MAU, subdomain segmentation is the right choice. For smaller SaaS, single domain is fine if you stay disciplined about step 1.
  3. 03

    Configure SPF: one TXT record, every sender enumerated

    Add a single TXT record at the root of your sending domain. Format: v=spf1 include:_spf.provider1.com include:_spf.provider2.com -all. One include: per authorized sending service (Postmark, SendGrid, Google Workspace, etc.). The -all at the end is a "hard fail" — receiving servers should reject any mail from an IP not in the allow-list. Critical limit: SPF allows a maximum of 10 DNS lookups during evaluation. Some providers' include: records chain to others; if your record triggers more than 10 lookups, SPF fails entirely. Use a tool like MXToolbox SPF Survey to check.
  4. 04

    Generate DKIM key pairs at your transactional provider

    Each sending service generates its own DKIM key pair. The provider gives you a public key to publish as a DNS TXT record (typically at selector._domainkey.yourdomain.com where selector is the provider's chosen selector — Postmark uses 20240101pm, SendGrid uses s1, etc.). The private key never leaves the provider. Publishing the public key correctly — and never deleting it as long as the provider might still send — is the entire DKIM setup. Most providers walk you through this in their dashboard with a "Verify domain" wizard.
  5. 05

    Publish DKIM records correctly (the part that breaks)

    DKIM TXT records are long — often 200+ characters. Many DNS providers truncate, split, or escape them incorrectly. The most common failure: the published record is missing a few characters at the end, so the signature fails to verify. After publishing, use MXToolbox's DKIM lookup to fetch the public record from your domain and verify it matches what your provider gave you byte-for-byte. Do not skip this verification step. A silently-truncated DKIM record is the most common "deliverability is mysteriously bad" cause we see.
  6. 06

    Verify SPF and DKIM are signing real outbound mail

    Send a test message from your transactional provider to [email protected] or use mail-tester.com. The response will show SPF=pass, DKIM=pass, and crucially — DMARC alignment status. If DMARC alignment shows "fail" even though SPF and DKIM pass individually, you have a misalignment problem (the From: domain does not match the signing domain). Fix that before continuing.
  7. 07

    Deploy DMARC in monitoring mode (p=none)

    Add a TXT record at _dmarc.yourdomain.com. Initial format: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100. The p=none tells receiving servers to take no action when a message fails authentication — but still send aggregate reports to the rua= address. Leave this in place for 2 weeks. Aggregate reports come in daily as XML attachments; tools like Postmark's free DMARC monitor or DMARC Digests parse them into human-readable dashboards. The reports tell you every IP that is currently sending from your domain and whether each is aligned.
  8. 08

    Fix every misalignment surfaced in the DMARC reports

    The reports almost always reveal a service you forgot in step 1. Common culprits: an old marketing email account, a CRM nobody removed when you cancelled, a ticketing system using a noreply address that does not match the signing domain. For each: either authenticate it correctly (add to SPF, configure DKIM) or stop sending from your primary domain through it. Re-run for another week of monitoring; iterate until all aligned traffic is real and all unaligned traffic is suspicious.
  9. 09

    Flip DMARC to p=quarantine, then p=reject

    Once monitoring reports show clean alignment for ~95%+ of your legitimate sending, change p=none to p=quarantine (sends failing-DMARC mail to the spam folder at the recipient). Watch the reports for 1 more week. If clean, flip to p=reject (failing-DMARC mail is bounced outright). This is the configuration that gets you the ~99% inbox-placement rates in the table above. Once on p=reject, your domain is also protected against most phishing — bad actors spoofing your domain get their mail rejected by every major mailbox provider.
  10. 10

    Add BIMI for logo display in supporting clients

    BIMI (Brand Indicators for Message Identification) is the optional last step — it lets supporting clients (Gmail, Yahoo, Apple Mail, Fastmail) display your brand logo next to your messages. The setup: publish a TXT record at default._bimi.yourdomain.com pointing at a hosted SVG of your logo. For Gmail to display the logo, you also need a Verified Mark Certificate (VMC) from DigiCert or Entrust — currently $1,500–$2,000/year. For smaller SaaS, skip the VMC initially; Yahoo and Apple Mail display the logo without it.

Debugging the four most common failures

After running this setup on dozens of SaaS products, the same four problems show up repeatedly. Each has a specific signature.

One: emails land in Gmail spam, every other client fine. Gmail is the strictest of the major providers on DMARC alignment. The signature is "DKIM=pass, SPF=pass, but DMARC=fail" in your test message. Cause: the DKIM signing domain does not match the visible From: domain. Fix: ask your provider to set up the DKIM selector on a subdomain of YOUR domain (not theirs). Postmark and SendGrid both support this in setup.

Two: emails work fine for 6 months, then start failing. The signature is "everything was good, now it isn't, nothing changed." Cause: SPF lookup count crept over 10 because a service you use (often Google Workspace) added a new include: chain. Fix: run an SPF lookup-count check; flatten the SPF record by replacing include: entries with the actual ip4: ranges where possible.

Three: marketing emails fine, transactional emails go to spam. Cause: your marketing volume is high enough to warm the sending IP, but your transactional volume from a different IP (or different selector) has never built reputation. Fix: send transactional and marketing through the same provider, OR explicitly warm each sending path with a 4-week ramp.

Four: a specific recipient cannot receive your email. Usually a custom mail server with overzealous filtering. The signature is everyone else gets your mail, this one person doesn't. Cause: the recipient's mail admin has whitelisted a previous sending IP and your new one isn't on it, OR a corporate Mimecast/Proofpoint deployment is filtering you. Fix: ask the recipient to whitelist your sending domain on their end. Not something you can solve from your side.

Related reading on Jorbox

Three adjacent posts: Migrating WordPress to Next.js on Cloudflare covers the broader infrastructure replatform — email setup is step 8 of that playbook; GEO audit checklist: 20 things to ship on a new marketing site covers the AI-search readiness work; Why we still answer our own support tickets in 2026 covers what we do with the messages once they're delivered. The web hosting service page covers what working with Jorbox on email + DNS setup looks like.

What is the difference between SPF, DKIM, and DMARC?
SPF lists which IP addresses are authorized to send mail "from" your domain. DKIM cryptographically signs each message so the recipient can verify it was not tampered with. DMARC tells the recipient what to do when SPF or DKIM fails (no action, quarantine, or reject) and requests aggregate reports back to a mailbox you control. All three are required for full email authentication in 2026 — SPF alone is no longer sufficient at Gmail, Outlook, Yahoo, or Apple.
Do I need DMARC if I have SPF and DKIM?
Yes. As of February 2024 (Gmail) and August 2024 (Outlook), high-volume senders without DMARC have measurably worse deliverability. DMARC is also the only one of the three that gives you reporting — without it, you have no visibility into which services are sending mail "from" your domain or whether their authentication is passing. Even if you do not flip to p=reject, deploying DMARC in p=none monitoring mode is a free engineering win.
What happens if my SPF record exceeds 10 DNS lookups?
SPF evaluation fails entirely — recipients treat the message as if no SPF record existed. The 10-lookup limit is a defense against DDoS via SPF chains. Common cause: chaining many include: directives where each provider itself has multiple includes. Use an SPF flattening tool (or service like EasyDMARC) to convert problematic include chains into explicit ip4: / ip6: ranges. The flattened record stays valid as long as the underlying IPs do not change.
Can I use multiple email providers from the same domain?
Yes — that is the normal SaaS pattern. List each provider in your SPF record via include:, and configure each provider's DKIM separately under its own selector. The recipient verifies whichever DKIM signature is present on the inbound message and checks alignment. The key constraints: respect the 10-lookup SPF limit, and pick providers that let you set up DKIM on a subdomain of YOUR domain rather than theirs (required for DMARC alignment).
Does DMARC p=reject break my email entirely?
Only if you flip to it before the DMARC reports show clean alignment. The recommended path is p=none for 2+ weeks of monitoring, then p=quarantine for 1 week, then p=reject. Each step gives you visibility into who is still sending from your domain unaligned and a chance to fix it before mail starts bouncing. If you flip directly to p=reject without monitoring, you are likely to bounce legitimate mail from an authorized service you forgot in your inventory.
Where do DMARC aggregate reports come from and how do I read them?
Every major mailbox provider sends a daily XML report to the rua= address in your DMARC record. The XML lists every IP that sent mail "from" your domain in the last 24 hours, what authentication results they had, and how many messages each IP sent. The raw XML is unreadable by hand — use a dashboard tool (Postmark's free DMARC monitor, DMARC Digests, or a paid option like EasyDMARC) to parse them. The dashboard shows you which IPs are aligned (good), which are unaligned-but-legitimate-services-you-forgot (need to fix), and which are spoofing attempts (which p=reject blocks for you).
Should I use a subdomain for transactional email?
For SaaS over ~50K monthly active users, yes — separate transactional (@mail.yourdomain.com) from marketing (@news.yourdomain.com) and human (@yourdomain.com) sending. Each subdomain has its own reputation. A bad marketing email list cannot tank your password-reset deliverability if they are on different subdomains. For smaller SaaS, single-domain sending is fine — the operational complexity of subdomain segmentation is not worth it until volume justifies.
Can I send transactional email through Gmail / Google Workspace?
Technically yes, practically no. Google Workspace has rate limits (2,000 outbound messages per day per user) and content policies optimized for human-to-human mail. SaaS transactional email — password resets, magic links, receipts — sent through Workspace will hit rate limits, get throttled, and eventually flagged for "bulk-sending behavior." Use a dedicated transactional provider (Postmark, Resend, SendGrid, SES) for anything user-facing. Use Workspace for your team's human-to-human mail only.
What is BIMI and do I need it?
BIMI (Brand Indicators for Message Identification) is an optional DNS record that lets supporting mail clients (Gmail, Yahoo, Apple Mail, Fastmail) display your brand logo next to your messages. It has zero direct deliverability impact — a properly-configured BIMI-less domain hits the same inbox rates. The benefit is recognition and trust signaling. For Gmail to display the logo, you need a Verified Mark Certificate (VMC) at $1,500–$2,000/year. For Yahoo and Apple Mail, the logo displays without a VMC. Most small SaaS skip the VMC initially.
How long does it take to set up SPF, DKIM, and DMARC?
On a new domain with one transactional provider: 30–60 minutes of DNS work plus 24 hours for the records to propagate. On an existing production domain with multiple senders: 2–4 hours of inventory and setup, plus 2 weeks of DMARC monitoring before flipping to p=reject. Most of the time is monitoring, not engineering — the records themselves are short and the providers have setup wizards.
Does this matter if I only send a few emails per month?
Yes. Mailbox providers do not have a "low-volume sender" exemption — they apply the same authentication rules to a 10-message sender and a 10-million-message sender. The difference is that low-volume senders without authentication have less data feeding their reputation, so any failed delivery is more visible. If you send password resets to your users, those messages need to authenticate or they will go to spam.
Does Jorbox set this up as part of the hosting service?
Yes — every hosting engagement includes SPF, DKIM, and DMARC setup, plus a 30-day DMARC monitoring period before we flip you to p=reject. See the web hosting service page for what working with us on hosting looks like end-to-end. For domain-only setups, we handle SPF and DMARC as part of domain registration; DKIM lives at the sending-email-provider layer, which is configured separately.
Keep reading

More notes from the work.

All posts