E-mail deliverability in 2026: SPF, DKIM, DMARC and the inbox you earn

Every few months a client calls with the same sentence: "our invoices aren't arriving." Sometimes it's a shop whose order confirmations stopped reaching Gmail. Sometimes it's an accountant whose reminders land in Junk at exactly the customers who owe the most. The diagnosis is nearly always the same, and it's never the copy: the receiving side can no longer tell whether the mail is really from you, and in 2026 "can't tell" is decided against you.

That is the actual shift. Ten years ago authentication was a nice-to-have that improved your odds. Since February 2024, when Google and Yahoo turned their bulk sender requirements on, it has been a gate — and Microsoft followed in May 2025 for anyone sending meaningful volume to Outlook, Hotmail and Live addresses. What used to be "best practice" is now the minimum to be considered at all, and clearing it buys you nothing more than the right to be judged on your behaviour.

The triad, in the order the receiver checks it

Three records, three different questions. Most of the confusion we untangle comes from people thinking they're three versions of the same thing.

SPF answers: is this IP allowed to hand over mail for this domain? It's a TXT record listing the servers permitted to send. The critical detail almost everyone misses: SPF validates the envelope sender — the Return-Path, the address in the SMTP MAIL FROM — and not the From: header your recipient actually sees. A perfectly valid SPF pass can sit on a message whose visible sender is a domain you have never heard of. That gap is the whole reason DMARC exists.

SPF also has a hard, unforgiving limit: ten DNS lookups. Every include: costs one, and every include: inside that one costs another. Add your mail host, your ERP, a CRM, a helpdesk, a marketing tool and an e-signature service, and you cross ten without noticing. The record doesn't fail loudly — it returns permerror, which most receivers treat as no SPF at all. We have seen a company add one small SaaS tool on a Tuesday and lose Gmail delivery on Wednesday, with nothing in any interface to explain it.

DKIM answers: has this message been tampered with, and does the signer hold the key? A private key on the sending server signs a set of headers plus the body; the public key sits in DNS under a selector. Unlike SPF it survives a hop — a forwarded message keeps its signature as long as the content isn't rewritten. Use 2048-bit keys, give each sending system its own selector, and rotate. A selector per platform means you can retire a tool by deleting one DNS record instead of renegotiating the whole zone.

DMARC answers: does the domain the human sees actually vouch for this? This is the one that matters, and it does two things people tend to conflate. It publishes a policy for what to do with mail that fails, and — the part that gives it teeth — it requires alignment: the domain in the visible From: header must match the domain that SPF or DKIM authenticated.

That distinction is where most half-finished setups die. SPF passing is not the same as SPF aligned. A marketing platform that sends with its own bounce domain in the Return-Path will pass SPF all day long while failing DMARC alignment completely, because the From: your customer reads says yourcompany.be and the authenticated domain says bounces.some-saas.com. The fix is a custom bounce domain — a CNAME you delegate to the platform — plus DKIM signed with your domain. Not one or the other: platforms churn, and having both means a broken SPF chain doesn't take you down on its own.

codeagency.be.            TXT  "v=spf1 include:_spf.example-mta.com -all"
sel1._domainkey           TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc                    TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@codeagency.be; adkim=s; aspf=s"

Note -all rather than ~all. A softfail is a statement that you don't quite trust your own list of senders, and receivers read it that way. If you can't write -all with a straight face, your inventory of who sends as you is incomplete — which is the real problem, and it will bite you somewhere else too.

What the 2024–2025 rules actually require

The bulk sender requirements are short enough to check in an afternoon, and the thresholds are public. For anyone sending more than roughly 5,000 messages a day to a given provider:

• SPF, DKIM and DMARC, with alignment. A DMARC record of p=none clears the bar. It is also the weakest thing you can publish, and treating it as the finish line is the most common mistake we're asked to fix.
• One-click unsubscribe on marketing mail — a real List-Unsubscribe-Post header per RFC 8058, honoured within two days. Not a link to a preference centre that asks the recipient to log in.
• A spam complaint rate below 0.3%, measured in Google Postmaster Tools. Read that number carefully: 0.3% is where enforcement starts, not where you should live. Above roughly 0.1% you are already drifting, and by the time you touch 0.3% the damage is weeks old.
• Valid forward-confirmed reverse DNS on the sending IP — a PTR that resolves back to the name that resolves to the IP.
• TLS on transmission, and a From: header that isn't impersonating the receiving provider's own domain.

Microsoft's version, enforced from May 2025 on high-volume senders to consumer Outlook domains, is the same triad with the same alignment requirement; non-compliant mail goes to Junk rather than bouncing, which is arguably worse because nothing tells you it happened.

None of this is exotic. What makes it consequential is that these five providers are most of the consumer inbox in Belgium, and the B2B mailbox increasingly runs on Microsoft 365 too. There is no meaningful "everyone else" left to fall back on.

p=none is a measurement tool, not a destination

The nervous version of a DMARC rollout is to publish p=none and stop. It's understandable — nobody wants to be the person who made the invoices disappear — but p=none protects nothing. Anyone can still send as your domain, and the whole point of the exercise is that they can't.

The rollout that works is boring and takes about six weeks:

1. Publish p=none with a rua= address, and actually read the reports. Aggregate reports are XML, they arrive daily from every major receiver, and they tell you exactly which IPs are sending as you and whether each one aligns. This is the inventory step. It always finds something — a forgotten monitoring server, a payroll tool, an old shop plugin, an office scanner mailing PDFs through a residential IP.
2. Fix everything that should be sending and isn't aligned. Custom bounce domains, DKIM keys per platform, the sending domain corrected in the tool nobody remembered owning.
3. Move to p=quarantine with pct= and ratchet it. Start at pct=25, watch the reports for a week, then 50, then 100. The percentage tag is the safety valve: it limits the blast radius while you're still learning.
4. Then p=reject. By this point the reports are quiet and the change is a non-event, which is exactly how it should feel.

Two tags earn their place in the final record. adkim=s and aspf=s switch alignment from relaxed to strict, so mail.yourcompany.be no longer counts as yourcompany.be — worth doing once you know your own senders, because relaxed alignment covers every subdomain including the ones an attacker might invent. And sp= sets the policy for subdomains independently, which matters if you send bulk mail from one.

Skip ruf= (forensic reports). It sends copies of failing messages, most receivers don't emit it for privacy reasons, and the ones that do will fill a mailbox with personal data you didn't want to be responsible for.

Split the streams at the domain level

Your order confirmations and your newsletter should not share a reputation. A campaign that goes out to a stale segment and collects complaints will drag the password-reset mail down with it, and the password-reset mail is the one where failure is a support ticket within minutes.

The separation we set up is at the DNS level, which is where it's cheapest:

mail.codeagency.be     → transactional: receipts, resets, invoices, alerts
news.codeagency.be     → bulk: newsletters, campaigns, product announcements
codeagency.be          → p=reject, sp=reject — the root sends nothing but person-to-person mail

Each subdomain gets its own DKIM selector and its own SPF record, so each accumulates its own reputation and a bad week on one doesn't bleed into the other. It also keeps the root domain's SPF record short, which is how you stay under the ten-lookup limit as tools come and go.

A caveat worth stating plainly: subdomain reputation is not a clean firewall. Receivers do consider the organisational domain, and a truly sustained complaint problem on news. will eventually be felt everywhere. The split buys you isolation for ordinary variance and a fast, surgical response when something goes wrong — not immunity from your own behaviour.

Warmup: reputation is earned daily, and it's per-IP and per-domain

New IP, new domain, or a domain that hasn't sent in a year — all three look identical to a receiver, which is to say: unknown, and therefore suspect. The failure mode we get called about is always the same shape. A company migrates platform on a Monday, sends 40,000 mails on Tuesday from an address with no history, and spends the next two months digging out.

Our schedule for a new sending domain, roughly:

Two rules matter more than the numbers. Send to your most engaged people first — early opens and replies are the positive signal that builds the reputation, and starting with your least engaged segment builds the opposite one just as efficiently. And keep the cadence steady: a domain that sends 5,000 a day for a month and then jumps to 50,000 for a Black Friday campaign has just told every receiver that something changed. Ramp into peaks; plan the ramp before the campaign calendar is set, not after.

Transactional streams warm themselves, because the volume follows real activity and the engagement is genuine. Bulk streams need the discipline.

The metrics that predict trouble

By the time delivery visibly breaks, the cause is four to six weeks in the past. These are the leading indicators, in the order we look at them:

• Complaint rate. The single most predictive number. Under 0.1% is healthy; 0.1–0.3% means act this week; above 0.3% means stop the campaign, not tune it. Complaints come back through feedback loops and Postmaster Tools, and they are a lagging measure of a list problem that started earlier.
• Hard bounce rate. Above 2% on a send says your list hygiene has failed, and receivers read repeated delivery to dead addresses as a strong signal that the list wasn't collected honestly. Suppress on the first hard bounce, permanently, everywhere.
• Domain and IP reputation in Google Postmaster Tools. Free, and the only direct view into how the largest receiver sees you. Watch the trend line, not the day.
• Authentication pass rate from your DMARC aggregate reports. A slow drift downward means a tool started sending unaligned — usually because someone connected a new integration. This is the metric that catches the problem before the complaint rate does.
• Delivered versus inbox-placed. Your platform reports "delivered", which only means the receiving server accepted the message. Junk folder counts as delivered. Seed lists and Postmaster Tools are how you see the difference.

One number to demote: open rate. Since Apple Mail Privacy Protection started pre-fetching tracking pixels, a large and unknowable share of your opens are a proxy server, not a person. Open rate is still useful as a relative trend on a stable audience, and it is useless as an absolute measure of engagement. Clicks, replies and conversions are what we actually segment on now.

What breaks after everything works

A deliverability setup is not a project you finish. The recurring failures, in rough order of how often we see them:

• Someone connects a new tool. Marketing signs up for a mail-merge plugin, it sends as you@yourcompany.be from its own infrastructure, and either your SPF record grows past ten lookups or the mail fails alignment. This is the number one cause of a healthy setup degrading, and the DMARC reports catch it in days if anyone is reading them.
• Forwarding. A customer auto-forwards work mail to a personal address; the forwarding server sends from its own IP, so SPF fails on arrival. DKIM survives — which is precisely why you need both, and why DKIM-only alignment is the more robust half of the pair.
• Mailing lists. Discussion lists rewrite subjects and append footers, breaking the DKIM body hash. ARC exists to let the list vouch for the original result, and support is good but not universal. It is a known, accepted crack in the model.
• A key that quietly expired. A DKIM selector removed during a DNS cleanup, or a certificate on the MTA that lapsed. Monitor your own records the same way you monitor uptime.
• A list someone bought. Nothing on this page survives it. Purchased and scraped lists generate complaints and spam-trap hits at rates that torch a domain in a single send, and the recovery costs more than the list did.
• The CEO's address in a campaign. Sending bulk mail with a person's real From: address means their reputation, their replies, and their signature on an unsubscribe complaint. Use a role address on a bulk subdomain.

What we actually run

The record set above, per client, with the streams split across subdomains and each platform on its own DKIM selector. DMARC at p=reject with strict alignment, aggregate reports parsed into a dashboard rather than a mailbox nobody opens. Complaint and bounce rates alerted on rather than reviewed monthly. A warmup schedule for anything new, and a suppression list that no campaign tool can override.

Then the tier above the triad, which is cheap once the basics hold: MTA-STS and TLS-RPT, so a receiver won't silently downgrade to plaintext and you find out when it tries. BIMI last — your logo next to the message in supporting clients — with the honest caveat that Gmail and Apple require a Verified Mark Certificate, which means a registered trademark and a real annual cost. It's a marketing decision, not a deliverability one, and it requires p=quarantine or p=reject first anyway.

The reason we do this ourselves rather than pointing clients at a form is that the failure is invisible from the inside. Your own mail to your colleagues always arrives; the sales mail that never reached a prospect generates no bounce, no alert and no complaint — just a quiet gap in the pipeline that looks like the market went soft. The fix is dull DNS work, a rollout with a safety valve, and someone actually reading the reports.

If you'd rather not own that: we run transactional e-mail and SMTP and a newsletter and mailing platform on our own infrastructure, with the authentication, the warmup and the monitoring handled as part of it — which is also why the cart recovery flows we build send from a domain that has already earned the inbox, and why the invoices coming out of a client's Odoo go through the same authenticated path as everything else.