Main area
Agency
marketing

Understanding email deliverability — SPF, DKIM, DMARC and why mail lands in spam

Redaktion ·

Why email deliverability matters

A sent email is not a delivered email. Between your “Send” click and the recipient’s inbox sit at least three filtering stages, a reputation database, and a handful of DNS records that either work or do not. If any of those wobbles, the message lands in spam — or gets dropped silently. The sender sees nothing, the recipient sees nothing, and the business that depended on that message simply does not happen.

The topic is awkward because there is no single “it works” signal. Instead, dozens of small indicators decide whether you count as a legitimate sender or as background noise. Once you understand SPF, DKIM, and DMARC, you have the bulk of it. The rest is reputation, list hygiene, and a setup you do once properly and then leave alone.

This article walks you through how delivery actually works, the DNS records in the right order, the typical traps, and concrete scenarios — from a first newsletter to transactional mail from your own application.

The basic mechanics: how email gets delivered

An email travels over SMTP (Simple Mail Transfer Protocol) from one mail server to the next. The crucial point: SMTP itself has no built-in identity check. It was designed in the early eighties when the internet was a trusted place between universities. Any server can claim to send on behalf of any domain — and that is exactly what spammers have been doing since the nineties.

The modern email world has built three authentication layers on top, each verifying via DNS whether a server is allowed to send on behalf of a given domain. Receiving servers (Gmail, Outlook, iCloud, large mail providers) check those layers on every inbound message and then make a decision: inbox, spam, or rejected.

The three filter stages on the receiving side

When a message lands at Gmail, it roughly passes through three stages.

Stage one: authentication. SPF, DKIM, and DMARC are checked. If DMARC fails and the domain has a reject policy in place, the message is gone right there. Nobody sees it; the sender may or may not get a bounce notice.

Stage two: reputation. The receiver checks whether the sending IP and the sending domain are known and what kind of history they have. This is about track record: how many messages came from here, how often they got marked as spam, how often they got deleted unread, how often they got replied to. Reputation is kept per receiving provider — Gmail does not trust you just because Outlook does.

Stage three: content. Only once the first two stages are clean does the filter actually look at the content. Spammy words, odd link structures, misleading headers — these matter, but they are secondary. A technically clean message from a sender with good reputation gets through, even if it contains the word “winner.”

SPF — who is allowed to send for you

SPF (Sender Policy Framework) is the oldest of the three layers. Through a TXT record in your domain’s DNS you publish a list of servers allowed to send mail with your domain in the sender field. The receiving server fetches that record and compares it to the IP address of the server delivering the message.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all

In plain English: authorized are all servers listed in Google Workspace’s SPF, all of Sendgrid’s, plus the single IP 203.0.113.5. Everything else should be rejected (-all = hard fail).

Trap: the 10-lookup limit

SPF allows at most 10 DNS lookups during evaluation. Every include: counts — and includes can themselves contain more includes. If you send mail through five different services (newsletter, transactional, CRM, helpdesk, marketing), you blow that limit fast. Result: SPF evaluation fails with permerror, and all your mail gets treated as if you had no SPF record at all.

Fix: SPF flattening (tools like EasyDMARC or Cloudflare resolve includes into static IP lists) or deliberately consolidating sending services.

Trap: SPF does not survive forwarding

When a recipient forwards a message from their own address to another (e.g. info@company.com → boss@gmail.com), the delivering server changes. The original IP is no longer in the sender’s SPF. Result: SPF fail. This is exactly where DKIM rescues the message.

DKIM — the cryptographic signature

DKIM (DomainKeys Identified Mail) cryptographically signs each message. The sending server computes a hash over selected headers and the body, then signs it with a private key. The matching public key is published in DNS by the domain owner — as a TXT record under a selector such as s1._domainkey.yourdomain.com.

The receiving server fetches the public key, verifies the signature, and now knows two things: first, the message really was signed by a server holding the domain’s private key. Second, the signed parts have not been altered in transit.

Unlike SPF, DKIM survives forwarding — the signature travels with the message. That is the main reason DKIM is now the more important of the two classic standards.

Practice: one selector per service

Each sending service (Google Workspace, Sendgrid, Mailgun, your own server) typically gets its own selector and therefore its own DNS record. Example: google._domainkey.yourdomain.com for Workspace, s1._domainkey.yourdomain.com for Sendgrid. Benefit: you can rotate or disable individual services without touching the others.

DMARC — the bracket around SPF and DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer on top of SPF and DKIM. It tells receiving servers three things:

  1. What to do when neither SPF nor DKIM confirms that a message comes from your domain — none (do nothing), quarantine (spam folder), reject (drop).
  2. Where to send the reports — daily aggregated reports listing who is sending in your name and whether authentication works.
  3. How strict “alignment” must be — the domain in SPF/DKIM has to match the domain in the visible From: header.

A DMARC record sits at _dmarc.yourdomain.com and looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r

The alignment angle — often overlooked

DMARC passes only if at least one of the two checks both works AND is aligned:

  • SPF passes AND the domain in Return-Path matches the From: domain (SPF alignment)
  • OR DKIM passes AND the signing domain matches the From: domain (DKIM alignment)

Plenty of newsletter tools send technically SPF-compliant mail — but with their own domain in the Return-Path. SPF passes, alignment fails, DMARC fails. Fix: configure a custom Return-Path / custom DKIM domain on your own domain (Mailchimp, Sendgrid and friends all offer this).

Setup order: do not start with reject

A hard DMARC policy without warm-up is the fastest way to block your own legitimate mail. Recommended sequence:

  1. Week 1–2: p=none; rua=... — collects reports, blocks nothing. Read the reports, find every service that sends on your behalf, set up SPF/DKIM for each.
  2. Week 3–6: p=quarantine; pct=10 — ten percent of unauthenticated mail goes to spam. Watch reports and complaints.
  3. Week 7+: ramp pct up to 100, then move to p=reject.

BIMI — the logo next to your sender

BIMI (Brand Indicators for Message Identification) is the youngest layer and is about display, not delivery. If you have a strong DMARC policy (quarantine or reject) and publish your brand logo as a special SVG in DNS, that logo shows up next to the sender in the inbox — at Gmail, Apple Mail, Yahoo, and a few others.

Effect: more recognition, more trust, in tests typically a 5–15 % bump in open rate. Cost: a VMC (Verified Mark Certificate) at roughly USD 1,500 per year, plus an SVG file in a very restrictive subset (SVG Tiny PS).

BIMI pays off for brands with high mail volume and a recognizable logo. For a three-person agency it is more vanity than ROI.

Reputation and IP warm-up

Authentication is the entry ticket — reputation decides whether you go to the inbox or to spam. Receiving providers maintain internal scores for every sending IP and every sending domain. Scored are:

  • Volume consistency. Suddenly jumping from 100 to 10,000 mails a day is suspicious. Spammers do that.
  • Engagement. How many recipients open, read, reply? How many mark as spam, delete unread?
  • Bounce rate. A high share of undeliverable addresses is a clear spam signal — spammers often work with old leaked lists.
  • Spam traps. Specially placed addresses that no one should ever have subscribed. Hitting one means the list is poorly maintained or bought.
  • Complaint rate. Clicks on “Mark as spam” — over 0.3 % is a warning, over 0.5 % is a red line.

IP warm-up — the first weeks count most

If you start on a fresh IP or a fresh domain, you have no reputation. Receivers treat that as “suspicious by default” — and rightly so. Fix: ramp up volume gradually.

Typical plan: day 1 — 50 mails to your most engaged recipients. Day 2 — 100. Day 3 — 200. Doubling every one to two days. And only send to addresses you know will open and react. Bad addresses (old, never opened, prior bounces) stay out for the first four weeks — early impressions weigh disproportionately.

For dedicated IPs used for newsletter sending, a full warm-up takes four to eight weeks. Skipping that burns the IP and costs months to recover.

List hygiene — bounce rate and spam traps

A clean list is not a “nice to have”, it is reputation-relevant. Three mechanics determine list quality.

Bounces are undeliverable addresses. Hard bounce (address does not exist) must be removed immediately and permanently. Soft bounce (mailbox full, temporary) gets two or three retries, then it goes too. A bounce rate above 2 % is noticeable, above 5 % becomes critical.

Spam traps are addresses whose only purpose is to catch spammers. Two kinds: pristine traps were never actively used — sending to them means you bought or scraped your list. Recycled traps are old, long-abandoned addresses that a provider reactivated after years — sending to them means you do not maintain your list.

Engagement hygiene is the voluntary version: regularly remove recipients who have not opened anything in six or twelve months. Painful in feel, healthy in effect. Inactive recipients drag down engagement and weaken reputation for the active ones.

Setup order in practice

When setting up a new domain for sending mail, work through these steps in order:

  1. MX record — where mail to the domain should go (Google Workspace, your own server, Mailgun receiving etc.).
  2. SPF record — list every authorized sending service, with ~all (soft fail) initially, later -all.
  3. DKIM keys — enable at every sending service, publish the selectors they hand you as TXT records in DNS.
  4. DMARC — start with p=none; rua=..., collect reports for two weeks.
  5. Tighten DMARC — step up to quarantine, then reject.
  6. Optional: BIMI — once DMARC is at quarantine/reject and the brand matters.

The real insights happen between steps 4 and 5: which services send in your name that you did not know about? Typical finds are an old helpdesk tool, a forgotten newsletter account from a predecessor, a server belonging to the marketing agency. Only when all of those are cleanly authenticated will DMARC reject actually hold.

Three typical scenarios

Scenario 1: Mailchimp newsletter, looks clean, still hits spam

DNS check shows: SPF and DKIM green, DMARC p=none. The DMARC reports say SPF passes (Mailchimp domain), DKIM passes (Mailchimp selector) — but alignment fails. The From: domain is company.com, the signature is on mail.mailchimp.com. DMARC scores that as unaligned, Gmail gets cautious.

Fix: in Mailchimp, set up “Domain Authentication”, which makes DKIM sign with company.com. SPF additionally needs include:servers.mcsv.net. Within 24 hours you usually see a visible jump in inbox placement.

Scenario 2: Transactional mail from your own app lands in spam

The app sends directly via sendmail from the web server. SPF does not know the IP (it is not in DNS), DKIM does not exist at all. Receiving providers see: no authentication, IP from a hosting platform — high spam suspicion.

Fix: do not send through your web server. Plug in a transactional provider (Postmark, Sendgrid, Mailgun, Amazon SES), authenticate the domain there (SPF + DKIM), send via their API. The provider has established IP reputation and correct authentication. Effort: one afternoon.

Scenario 3: DMARC report shows unknown senders

In the weekly report a Russian IP shows up sending in your name — and failing both SPF and DKIM. First reaction: panic. Realistic diagnosis: someone is spoofing your domain. This happens constantly, especially for known brands.

DMARC with p=reject solves exactly that. The spoofed mails do not get through, your brand reputation stays clean. Reports keep showing the attempts — that is informative, not alarming.

FAQ

How long until a DNS change takes effect?
The record itself is live within minutes at most DNS providers. The TTL (time-to-live) controls how long caches keep old values — typically 1–24 hours. Before important changes, lower TTL to 5 minutes, change, then raise it again.
Is SPF alone enough?
No. SPF does not survive forwarding, only covers the envelope sender (Return-Path), and offers no content integrity. DKIM complements both. Both together are required for DMARC.
Do I need a dedicated IP for sending?
Only above roughly 100,000 mails per month. Below that, the shared reputation of an established provider beats your own IP, which you would still have to warm up.
What do I do if my domain ends up on a blocklist?
First check which list — Spamhaus, SORBS, Barracuda all have different lists and different delisting processes. Find the cause (compromised mailbox? hacked form? bought list?), fix it, then request delisting from the list operator.
How do I measure deliverability without specialty tools?
Seed lists via GlockApps, Mailtrap or similar. Sending to their test addresses shows, per provider, whether the message lands in inbox, spam, or nowhere. Costs USD 30–80 per month and gives a clear diagnosis.

Conclusion

Email deliverability is not a marketing topic, it is an infrastructure topic. Once SPF, DKIM, and DMARC are set up cleanly — with the staged DMARC rollout — you are over 80 % of the hurdles. The rest is list hygiene and volume consistency.

The most common mistakes: jumping to p=reject too quickly, sending mail through your web server instead of a transactional provider, and not configuring domain alignment in newsletter tools. All three are fixable in an afternoon — provided you know what to look for.

If you send heavily, both transactional and marketing, scan the DMARC reports once a week. Tools like Postmark, EasyDMARC or Valimail Monitor parse the XML reports into readable dashboards. That is the only ongoing maintenance the setup really needs.

Themenuebersicht

Marketing