Open rates fall. Someone suggests new subject lines or a shorter newsletter, and a month later the numbers haven’t moved.
When I get asked to look at it, I don’t open the emails first. I open the DNS.
Mail providers decide where your email goes before anyone reads the subject line. They look up your domain and check whether the server sending this message is one you’ve said can send for you, and if the answer isn’t clear, the email goes to spam or nowhere at all.
HubSpot’s reports still count it as delivered. That’s why it can go unnoticed for so long.
What SPF, DKIM and DMARC do
There are 3 records involved, and each one answers a different question.
SPF answers “is this server allowed to send for this domain?” It’s a single TXT record listing every service that sends email as you. For an organisation on Microsoft 365 that also uses HubSpot, it looks something like this:
v=spf1 include:spf.protection.outlook.com include:<the one HubSpot gives you> ~all
With DKIM, every message carries a signature, and the receiving server checks it against a public key published in your DNS. If anything changed on the way, the check fails.
DMARC covers the question the other two leave open: what should happen when a check fails? It’s also the only one that reports back, so once it’s on you get daily reports of every service sending in your domain’s name, which is often a longer list than anyone in the building could have written down.
Google and Yahoo have required DMARC from bulk senders since February 2024. If your newsletter goes to a few thousand people, you’re in that group or close to it.
Connecting the sending domain in HubSpot
HubSpot walks you through this when you connect an email sending domain in its settings. It gives you 2 CNAME records for DKIM, and the include to add to your SPF record.
Until those records are in, HubSpot signs your email with its own domain, so it can’t pass DMARC for yours. Once your DMARC policy tightens, that’s the email that gets blocked first.
I manage most of my clients’ DNS in Cloudflare, and it has one setting that catches people out. Every CNAME record has a small cloud icon next to it: orange means Cloudflare proxies the record, grey means DNS only.
DKIM records have to be grey. Proxied, the lookup hits Cloudflare instead of HubSpot’s key, so the signature can’t be checked.
Nothing warns you. HubSpot usually shows the domain as unverified, which is the clue, and the fix takes about 2 seconds once you know where to look.
The mistakes I find most often
The commonest is 2 SPF records. Someone adds HubSpot by creating a new TXT record instead of editing the one that’s already there, which looks tidy in the DNS panel. Receiving servers see 2 SPF records, call it an error, and carry on as if there were none.
Then there’s the 10-lookup limit. Every include in an SPF record costs DNS lookups, and some cost several, so an organisation running Microsoft 365, HubSpot, Xero sending its invoices, a payroll system and an old Mailchimp account can go over the limit without anyone adding anything unusual. The record still looks fine in the DNS panel.
Old services come next. The mailing tool an organisation stopped paying for years ago is often still in the record, using up lookups and still allowed to send as them.
And then there’s the DMARC record set to p=none years ago and never opened since. Its reports go to an inbox that may not exist any more.
Moving DMARC on, slowly
A DMARC record usually starts life looking like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.co.uk
p=none means receiving servers change nothing and send you reports. I point those reports at EasyDMARC, because the raw files are XML and unreadable in any quantity. EasyDMARC turns them into a list of every service sending as you, and whether each one passes.
In my experience there’s a surprise in the first week: an invoicing system that wasn’t on anyone’s list, or a website contact form sending from the main domain (I find DMARC reports more interesting than I probably should).
Once every genuine sender passes, the policy moves to p=quarantine, which sends failures to spam. A few weeks later, if the reports stay clean, it moves to p=reject.
I don’t rush that last step. Reject means failing email doesn’t arrive at all, and if a supplier’s system was sending your invoices, you find out when someone rings to ask why they haven’t been paid.
Checking the setup
MXToolbox is my first stop. Its SPF check shows how many lookups the record uses and whether it parses, and its blacklist check covers the other way email goes missing.
For a real send, I email a HubSpot test to a Gmail address and open “Show original”. It lists SPF, DKIM and DMARC with a pass or fail next to each.
After the DNS, the email itself
Once the records pass, the content matters again, and it’s a shorter list than people expect.
Emails that are mostly one big image are harder for spam filters to read and easier for them to distrust. Some email clients still hold images back until the reader allows them, so the message has to work as text.
Plain emails from a named person tend to do better than designed newsletters for the organisations I work with. I’d test it on your own list before taking my word for it.
DNS is part of the job
I’ve looked after DNS for clients since long before HubSpot existed, and most of it lives in Cloudflare now. Connecting a HubSpot sending domain properly is one of the quicker jobs I do, and checking an existing setup is quicker still.
If your emails are going missing, book a call and I’ll go through your records with you.
