Go to articles

Improving email deliverability: SPF, DKIM and DMARC are only the start

CategoryGuide
Published20 Sept 2026

Deliverability is not a setup task

Most advice on email deliverability treats it as a checklist: set three DNS records, tick the box, move on. The records matter, and they come first. But deliverability is not something you configure once. It is a reputation that mailbox providers recalculate every day from how your mail is received, and it has to be monitored and defended like one. What follows is how we handle it at Waer Waters, where both marketing and transactional mail go out through HubSpot.

First, authentication

SPF lists which servers may send mail for your domain. DKIM signs every message, so the receiver can check it really came from you and was not altered on the way. DMARC tells receivers what to do when those checks fail and, just as important, where to send reports about it. Without all three in place and aligned with the domain you send from, nothing else in this article helps. Google and Yahoo have required them from bulk senders since 2024, and Microsoft followed for Outlook.com in 2025, so this is no longer good hygiene but the entry ticket. Start DMARC at p=none, read the reports, and tighten it once they are clean.

; SPF: one record, listing every service that sends as you
example.com.                        TXT    "v=spf1 include:<sending-service> -all"

; DKIM: the keys come from HubSpot when you connect the sending domain
<selector>._domainkey.example.com.  CNAME  <value from HubSpot>

; DMARC: monitor first, enforce later (p=quarantine, then p=reject)
_dmarc.example.com.                 TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Warm up a dedicated IP

On shared IPs, part of your reputation belongs to whoever else is sending from them. A dedicated IP in HubSpot makes the reputation yours alone, which is only good news if you build it properly. A new IP has no history, and mailbox providers treat a stranger suddenly sending large volumes as a spammer until it proves otherwise. So you warm it up: start with small volumes to your most engaged contacts and build up over several weeks, rather than sending the full list on day one.

Two IPs: one for transactional, one for marketing

Take two dedicated IPs rather than one: one for transactional mail, such as booking confirmations, invoices and password resets, and one for marketing. Marketing mail is where the complaints and unsubscribes happen. If both share an IP, a newsletter that lands badly drags down the reputation your confirmations depend on, and those are the messages customers actually need to receive. Most articles stop at the DNS records and never get to IP strategy, which is often exactly where the difference between inbox and spam folder is made.

Monitor every source you can get

No single report shows the whole picture. DMARC aggregate reports tell you who is sending mail as your domain and whether it passes. Google Postmaster Tools shows how Gmail rates your domain and how often recipients mark you as spam. Microsoft SNDS does the same for your IPs at Outlook and Hotmail, and only for IPs you control, which is one more reason to have your own. If your DNS sits at Cloudflare, it can collect and summarise your DMARC reports too. The more feeds you watch, the earlier you catch a dip in reputation, before it turns into an inbox problem your customers notice.

You need a tool to read the reports

Raw DMARC reports are XML files, one per provider per day, and nobody reads them by hand for long. Switching reporting on is not the same as knowing what it says. Use something that parses and visualises them: Cloudflare's DMARC management is one option, and dedicated DMARC analysers go further. The lesson is simple. Do not only switch the reports on; make sure they turn into something a person actually looks at.

Never send to a list by hand

We never send a manual newsletter or a one-off mail to our lists. Everything goes out through a workflow. That sounds like extra work for a newsletter, but it is what lets you control who receives a send, in which order and at what pace, and with the reporting above in place you can see whether it is working. The workflow has three parts, laid out below.

enrol       newsletter list
branch 1    opened or clicked in the last <n> days?   no -> leave out
branch 2    email domain
  gmail.com                          -> throttle -> go to newsletter
  outlook.com, hotmail.com, live.com -> throttle -> go to newsletter
  telenet.be                         -> throttle -> go to newsletter
  everything else                    -> throttle -> go to newsletter
throttle    custom coded action with no logic, rate limited
newsletter  one automated email, maintained once

Segment on engagement first

The first branch only lets through contacts who opened or clicked recently. Everyone else is held back rather than mailed. Sending to the whole list every time means hitting dead addresses and people who will mark you as spam, send after send, and both count against your reputation. Weigh clicks above opens where you can, since privacy features in mail apps load messages in the background and inflate open rates. A smaller list that engages does more for your deliverability than a large one that does not.

Branch per provider, and throttle each branch

After the engagement branch, split again by mailbox provider: gmail.com for Google, outlook.com, hotmail.com and live.com for Microsoft, telenet.be, and whichever other domains matter in your list. In each branch, add a custom coded action with no logic in it. It does nothing except carry a rate limit, which is the point: it becomes a throttle, so each provider receives your send at a controlled pace rather than all at once. A steady stream looks more natural to a spam filter than a spike, and it keeps you under the volume thresholds that invite extra scrutiny. Custom coded actions need Data Hub Professional, formerly Operations Hub.

Bring the branches back together

After the throttles, every branch uses a go-to action to jump to one and the same automated email. Do not put a copy of the email under each branch. That leaves you with five emails to keep in sync, and sooner or later one of them goes out with last month's link. The branches exist to control timing and pace, never content. When you want to send a newsletter, you update that one email and run the workflow.

Defended, not configured

The records get you through the door, the IP strategy protects the mail that matters most, the monitoring tells you when something shifts, and the workflow makes every send a controlled one. None of it is difficult on its own. What makes the difference is doing all of it, and keeping it up after the first month, when everything looks fine.

Let's build something remarkable and grow your business.

Get In Touch →