Email Deliverability Guide: SPF, DKIM, DMARC Explained

Three DNS records decide whether your marketing email lands in the inbox, the spam folder, or nowhere at all. Misconfigure them and your delivery rate quietly collapses — usually you find out via a dashboard going red, not via an error message. Here is what each record does, why it exists, and how to set them up without breaking your existing mail.

The 30-second model

When you send email from your domain, receiving servers (Gmail, Outlook, Yahoo) ask three questions:

1. Is this server allowed to send for this domain? — answered by SPF.
2. Has this message been tampered with in transit, and does the sender control the signing key? — answered by DKIM.
3. What should happen if SPF or DKIM fails? — answered by DMARC.

You publish all three as DNS TXT records. Gmail and Yahoo have required SPF + DKIM + DMARC for bulk senders since 2024; without them, even legitimate mail lands in spam.

SPF: Sender Policy Framework

SPF lists the servers (by IP or hostname) authorised to send email on behalf of your domain. The receiver looks up your SPF TXT record at send time and checks whether the sending IP is on the list.

Minimal SPF record for a domain sending via Google Workspace and an ESP:

v=spf1 include:_spf.google.com include:_spf.reachbell.com ~all

• v=spf1 — version, always this.
• include:... — hand off the check to the listed domain. Use the include given by each provider you send from.
• ~all — soft-fail anything not matched. Use `~all` while ramping; move to `-all` (hard-fail) once you are confident the list is complete.

Common SPF mistakes that cause delivery problems:

• Multiple SPF records — you can only have ONE TXT record starting with `v=spf1`. Combine includes if you switch providers, do not stack records.
• Too many DNS lookups — SPF allows max 10 nested lookups. Hit 11 and the whole check fails. Track your includes.
• Forgetting transactional sends — your billing system, CRM, support tool, all probably send email too. Each needs to be in the SPF record.

DKIM: DomainKeys Identified Mail

DKIM signs each outgoing message with a private key. The matching public key lives in DNS. The receiver verifies the signature with the public key — proving the message came from someone with the private key (you) and was not modified in transit.

Each sending service generates a DKIM key pair for you and provides a DNS record to publish. The record name uses a selector — a label you choose so you can rotate keys without breaking the world:

Host:    reachbell._domainkey.yourdomain.com
Type:    TXT
Value:   v=DKIM1; k=rsa; p=MIIBIjANBgk...QAB

You can have multiple DKIM records — one per selector per service. Google Workspace, ReachBell, your CRM, each get their own. They do not conflict because they live under different selector subdomains.

• Selector naming — keep it descriptive (`google2024`, `reachbell`, `mailchimp1`). Future you will thank current you when rotating.
• Key length — use 2048-bit. 1024 still works but is deprecated.
• Rotation — generate a new key every 6-12 months, publish under a new selector, switch the sending service, leave the old record up for 30 days.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC tells receivers what to do when SPF or DKIM fails — and asks them to report back to you. It is the policy layer over the other two.

Minimum DMARC record:

Host:    _dmarc.yourdomain.com
Type:    TXT
Value:   v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• p= — policy: `none`, `quarantine`, or `reject`. Start at `none` (monitor only), move to `quarantine` (spam folder), then `reject` (drop the message) once your reports are clean.
• rua= — aggregate report address. Receivers send daily JSON reports of every send they saw; you process these to find unauthorised senders or misconfigurations.
• ruf= (optional) — forensic report address; receivers send individual failure reports. Higher volume; many providers do not honour it.
• sp= — subdomain policy. Default is to inherit `p=`; override if you want stricter rules for subdomains.
• pct= — percentage of mail to apply policy to. Use `pct=10` while ramping to `quarantine`/`reject` for safety.

Alignment: the subtlety that breaks people

DMARC requires that SPF and/or DKIM pass AND that the domain checked aligns with the visible From: header. Strict alignment means exact match; relaxed alignment means same organisational domain.

This is where third-party senders trip up. If your From: header is `hello@yourdomain.com` but your ESP sends via `bounces@esp.com`, SPF will check `esp.com` and pass — but DMARC will fail alignment. Fix by using a custom sending domain (most ESPs offer this) so the Return-Path also lives under yourdomain.com.

A working rollout plan

1. Week 0 — inventory every service that sends email from your domain. Make a list.
2. Week 1 — publish or update SPF to include all senders. Use `~all`. Test with `dig TXT yourdomain.com` and an external SPF checker.
3. Week 1 — enable DKIM for every sender. Each gives you a DNS record to publish.
4. Week 2 — publish DMARC at `p=none` with `rua` to a monitored mailbox.
5. Week 3-4 — process DMARC reports daily. Identify any sender failing alignment; fix sender config or update SPF/DKIM.
6. Week 5 — move DMARC to `p=quarantine; pct=10`. Watch reports for collateral damage.
7. Week 6-8 — ramp `pct=` to 100, then move to `p=reject`. SPF moves from `~all` to `-all`.

How to read DMARC reports

Raw DMARC reports are XML — readable but tedious. Pipe them into a parser (free tools: Postmark, EasyDMARC, dmarcian free tier). You are looking for:

• Unknown sources passing SPF/DKIM — usually you forgot a service. Add it to SPF.
• Known sources failing alignment — usually a third-party sender needs a custom domain set up.
• High-volume unknown sources failing — could be spam impersonating you. DMARC at `reject` blocks them once it ramps.

BIMI and the visual upgrade

Once DMARC at `p=quarantine` or stricter is enforced and your brand has a Verified Mark Certificate (VMC), you can publish a BIMI record to display your logo next to messages in Gmail, Yahoo, Apple Mail. It is the visible reward for getting the rest right. Not required, but a nice trust signal once the boring work is done.

Common-sense checks

• Send a test email to a Gmail address, click "Show original" — confirm SPF: PASS, DKIM: PASS, DMARC: PASS.
• Use `dig` or `nslookup` to verify TXT records propagate. DNS changes can take 24+ hours.
• Avoid editing DNS during a major send. Schedule changes for low-volume windows.

When you send marketing email through ReachBell, SPF includes, DKIM keys, and a custom sending domain are part of the onboarding — we walk you through each DNS record with copy-paste values. See the email channel page for the full feature list, or check pricing for transparent per-send rates.