Deliverability: SPF, DKIM, DMARC & warmup

SubsiMail doesn't send mail from its own servers or its own IP — every message goes out through your connected Gmail, Outlook, or SMTP account. That's good for avoiding shared-IP reputation problems, but it means the usual authentication setup (SPF, DKIM, DMARC) and sending discipline (warmup, volume ramp, list hygiene) are entirely your responsibility, same as they would be for any tool relaying through your own mailbox. This page is the practical guide for getting that right before you send real volume.

Why this is on you, not us

Authentication records live in your domain's DNS, not in SubsiMail. We control pacing (daily caps, randomized send intervals) and reply-stop — we can't sign your mail or configure your DNS for you, because we never touch either. If you skip this page and start sending, the most likely outcome isn't a SubsiMail problem at all: it's your own provider (Gmail, Microsoft 365, or your SMTP host) flagging or throttling you, independent of anything in this app.

SPF

SPF (Sender Policy Framework) is a DNS TXT record on your sending domain that lists which mail servers are allowed to send as you. A receiving server checks it against the server that actually delivered the message.

Google Workspace	v=spf1 include:_spf.google.com ~all
Microsoft 365	v=spf1 include:spf.protection.outlook.com ~all
Amazon SES	v=spf1 include:amazonses.com ~all
Other SMTP providers	Check their docs for the exact include: mechanism — it's almost always one line they publish directly.

A domain can only have one SPF record. If you already have a TXT record starting with v=spf1 (from a website contact form, another tool, etc.), add the new include: into that same record rather than creating a second one — two SPF records is a common misconfiguration and causes SPF to fail entirely, not just partially.

DKIM

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key; a public key published as a DNS record lets the receiving server verify the signature wasn't tampered with. Unlike SPF, DKIM is set up per-provider, not written by hand:

• Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email → generate a DKIM key for your domain → add the TXT record it gives you (selector like google._domainkey) → wait for DNS to propagate, then click "Start authentication."
• Microsoft 365: Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → DKIM → select your domain → enable, and add the two CNAME records it generates.
• Amazon SES / other SMTP: your provider's dashboard generates the DKIM records (usually 2–3 CNAMEs) for the specific domain you verify with them.

DNS propagation for DKIM can take anywhere from a few minutes to 24–48 hours. Don't start real sending until your provider's console shows DKIM as verified/active, not just "pending."

DMARC

DMARC ties SPF and DKIM together: it tells receiving servers what to do with mail that fails both, and (optionally) where to email aggregate reports. It lives at _dmarc.yourdomain.com, also as a TXT record.

Start permissive, not strict:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

p=none monitors without rejecting or quarantining anything — it just gets you the reports so you can confirm SPF and DKIM are actually passing for your real mail flow. Once you've watched clean reports for a couple of weeks, move to p=quarantine, and eventually p=reject once you're confident nothing legitimate is failing. Jumping straight to p=reject on a new setup is the most common self-inflicted deliverability wound we see recommended elsewhere — if SPF or DKIM alignment is even slightly off, you silently lose your own legitimate mail with no warning.

Warming up a domain or inbox

Correct DNS doesn't buy you sending reputation on day one. A brand-new domain, or an old domain that's never sent bulk mail, has no history for spam filters to trust — and blasting your target volume immediately, even with perfect SPF/DKIM/DMARC, reads as suspicious regardless.

• Ramp gradually. Start around 15–30 emails/day for a new inbox and increase over 2–4 weeks rather than jumping straight to your target volume. There's no single "correct" curve, but roughly doubling every few days (not every day) is a reasonable default.
• Use SubsiMail's built-in caps to enforce it. Each connected account (Accounts page) has a daily send limit and a randomized send-interval range — set the daily cap low for the first couple of weeks on a new inbox, then raise it as the domain builds reputation.
• Keep your list clean. High bounce rates hurt reputation fast, especially during warmup. Verify or at least sanity-check a new list before enrolling it, and let SubsiMail's suppression list do its job on unsubscribes and bounces — don't re-add suppressed addresses.
• Old, previously-inactive domains aren't automatically safe. A domain that's existed for years but never sent mail still benefits from the same gradual ramp as a brand-new one.

Checking your setup

Before sending anything real, verify each record is actually live:

dig TXT yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short
dig TXT google._domainkey.yourdomain.com +short   # or your provider's DKIM selector

Or skip the command line and use one of these:

• mail-tester.com — send a real test email to the address it gives you, get back an instant SPF/DKIM/DMARC/spam-score report.
• Google Postmaster Tools — a reputation dashboard for domains sending to Gmail recipients, useful during warmup to watch spam-rate trends over time.
• MXToolbox — standalone SPF/DKIM/DMARC record checkers if you'd rather not read raw dig output.

Checklist before a real send

• One SPF TXT record (not two), including your provider, ending in ~all or -all
• DKIM shows as verified/active in your provider's console, not pending
• A DMARC record exists at _dmarc.yourdomain.com, starting at p=none
• Sent yourself a test through mail-tester.com and confirmed SPF/DKIM/DMARC all pass
• Daily send cap set low on the Accounts page for any new or previously-unused inbox
• List has been sanity-checked, not just uploaded and enrolled