Email Deliverability and Domain Setup: SPF, DKIM, and DMARC

A new domain with no email history starts at zero trust. Receiving mail servers have no prior signal that your domain sends legitimate email. Without the right DNS records, even transactional messages (password resets, receipts, notifications) will land in spam or be rejected outright.

The Three Records That Matter

SPF (Sender Policy Framework)

SPF is a TXT record on your domain that declares which mail servers are authorised to send email from your domain.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

Breaking this down:

v=spf1 — SPF version
include:_spf.google.com — Google's mail servers are authorised (use your mail provider's SPF include)
~all — soft fail for all others (email from other sources is suspect but not rejected outright)
Use -all for hard fail if you're confident all legitimate sending is covered

Common mistakes:

Multiple SPF records (only one TXT record with v=spf1 is permitted — combine them into one)
Missing include for transactional email services (Postmark, SendGrid, Mailchimp — each has its own SPF include)
SPF permerror from too many DNS lookups (10 max; include directives each count)

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages. The receiving server looks up the public key in your DNS and verifies the signature.

The DKIM record is a TXT record with a selector prefix:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public key>"

Your mail provider generates the key pair and gives you the DNS record to add. You don't generate the keys manually — you copy what they provide.

Selectors allow multiple DKIM keys (for different sending systems). The selector (google in the above) is specified in the email header by the sender and used to look up the right DNS record.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC builds on SPF and DKIM. It tells receiving servers what to do with messages that fail both checks, and where to send reports.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Policy values:

p=none — monitor only; don't take action on failures (use this when starting out)
p=quarantine — move failures to spam folder
p=reject — reject failures outright (most protective, use once you're confident your setup is complete)

DMARC requires that the domain in the From: header aligns with either the SPF-authenticated domain or the DKIM-signed domain. Both checks can pass technically but still fail DMARC alignment if the domains don't match.

Setup Order

Set up your mail provider (Google Workspace, Fastmail, Postmark, etc.)
Add SPF record as directed by your provider
Add DKIM record(s) as directed — wait 24–48 hours for propagation before testing
Start with p=none DMARC pointing to a report inbox you control
Monitor DMARC reports for 2–4 weeks to confirm all legitimate sending sources are covered
Advance to p=quarantine, then p=reject

Domain Age and Email Deliverability

New domains have no sending reputation. Even with correct SPF/DKIM/DMARC, a brand-new domain sending bulk email will hit spam filters.

For new domains sending transactional email:

Start with low volume and increase gradually
Ensure recipient lists are clean (no invalid addresses)
Monitor bounce rates — anything above 2% signals a problem
Use a dedicated transactional email service (Postmark, SendGrid) rather than your primary mail server

For marketing email from a new domain, warm up the sending volume over 4–6 weeks. Many ESPs (Email Service Providers) have automated warmup programs.

Checking Your Setup

After adding records, verify with:

MXToolbox (mxtoolbox.com) — validates SPF, DKIM, DMARC
DMARC Analyser — parses DMARC aggregate reports
mail-tester.com — sends a test message and scores your deliverability setup

These tools show exactly what is configured, what is missing, and what receiving servers will see.