Email deliverability
Emails going to spam? Let us find out why.
Deliverability problems are almost never one thing. A domain can authenticate perfectly and still be filtered because of complaint rates, a shared IP neighbour, or a sending pattern that looks automated. We work through the evidence in order — headers, DNS, bounce logs, reputation signals — until the actual cause is identified, then fix what is in your control.
You might need this if
- Transactional mail (password resets, order confirmations) reaches Gmail but lands in Junk at Outlook and Microsoft 365.
- Delivery was fine until you changed sending platform, added a new subdomain, or moved to a new provider.
- Your DMARC aggregate reports show failures you cannot interpret.
- Bounce messages mention “550 5.7.1”, “spamhaus”, “unauthenticated”, or a provider-specific block page.
- Open rates dropped sharply with no change to the content or the list.
- Mail from one department or one application is filtered while the rest of the domain is fine.
What the work covers
Not every engagement includes all of this. The scope is agreed in writing before anything starts.
Authentication and alignment audit
We verify SPF, DKIM and DMARC the way a receiving server evaluates them: not just “is there a record”, but whether the From domain aligns with the signing domain and the envelope sender, and which of your sending sources currently fail.
SPF record repair
Resolving the ten-DNS-lookup limit, removing duplicate records, replacing deprecated mechanisms, and consolidating includes so every legitimate sender is covered without overrunning the budget.
DMARC reporting and policy progression
Setting up aggregate reporting, reading the XML, identifying every source sending as your domain, and moving from p=none to quarantine or reject only once the legitimate traffic is covered.
Bounce and complaint analysis
Classifying hard bounces, soft bounces, blocks and feedback-loop complaints, because the fix for a reputation problem looks nothing like the fix for a list-hygiene problem.
Reputation investigation
Checking sending IPs and domains against the major public blocklists, reviewing Google Postmaster Tools and Microsoft SNDS data where you have access, and separating domain reputation from IP reputation.
Sending-behaviour review
Volume ramp, list acquisition, unsubscribe handling, List-Unsubscribe headers, and the separation of transactional from marketing streams onto different subdomains.
How we approach it
- 01
Collect evidence
Raw message headers from a filtered message at each affected provider, recent bounce logs, DMARC aggregate reports if any exist, and a list of every system that sends as your domain.
- 02
Reproduce and measure
We send test mail through your real sending path to seed addresses we control, and read the resulting Authentication-Results headers rather than relying on a third-party score.
- 03
Separate the causes
Authentication failures, reputation damage and content filtering produce different symptoms. We rule them in or out one at a time instead of changing six things at once.
- 04
Fix and re-test
Changes are applied in an agreed order, with DNS TTLs lowered beforehand, and each change is verified against the same seed path before the next one is made.
- 05
Hand over monitoring
You get a DMARC reporting address that someone actually reads, and a written description of what normal looks like for your domain, so the next regression is noticed early.
What you end up with
- A written findings report naming each cause found, with the evidence for it
- Corrected SPF, DKIM and DMARC records, with the exact DNS values to publish
- A per-sender inventory: every system sending as your domain and its current authentication status
- A prioritised fix list separating what we changed from what needs a decision on your side
- A DMARC policy progression plan with the conditions for each step
- A re-test showing authentication results before and after
Technologies involved
Tools and standards this work is carried out with — listed because they are what the job uses, not as a claim of vendor partnership.
- SPF (RFC 7208)
- DKIM (RFC 6376)
- DMARC (RFC 7489)
- ARC
- MTA-STS
- TLS-RPT
- Google Postmaster Tools
- Microsoft SNDS
- Postfix
- Cloudflare DNS
What this will not do
No one can guarantee inbox placement. Receiving providers make filtering decisions using signals we cannot see or control, including recipient engagement. What we can do is remove every technical reason to filter your mail, and give you the monitoring to see what happens next.
On client examples: we do not publish case studies, logos or testimonials without written permission from the client, and we have none cleared for publication yet. If you need evidence of relevant work before engaging, ask — we will share what we can, appropriately redacted, and say plainly where something was a lab build rather than a client engagement.
Questions about this service
How long does a deliverability investigation take?
The diagnosis is usually a few days once we have the evidence — headers, bounce logs and DNS access. Fixing what it finds depends on what it is: a broken SPF record is an afternoon; recovering a damaged sending reputation is weeks of changed behaviour, because reputation only improves through sustained good sending.
Will you need access to our email platform?
Often not for the diagnosis. DNS is public, and message headers and bounce logs are things you can export and send us. For implementation we need access to the DNS provider, and sometimes the sending platform to configure a signing domain. We ask per system and tell you how to revoke it afterwards.
Our emails only fail at Microsoft. Is that different?
Usually yes. Microsoft 365 and Outlook.com weigh sender reputation differently from Gmail and are stricter about new or low-volume senders. Provider-specific filtering is a real pattern and points at reputation rather than authentication, since authentication either passes everywhere or fails everywhere.
Can you fix this if we send through HubSpot, Klaviyo or Mailchimp?
Yes. Platform-sent mail is one of the most common sources of alignment failures, because the platform signs with its own domain by default. The fix is configuring a custom sending domain and publishing the DKIM record in your DNS, which all of those platforms support.
What if the problem turns out to be our content or our list?
We tell you, and we say so in the report. Purchased lists, misleading subject lines and no working unsubscribe are not DNS problems and cannot be fixed with DNS. We would rather lose the implementation work than take payment for changes that will not help.
Not sure where your mail is being lost?
Run the free email health check on your domain first — it will tell you whether SPF, DKIM and DMARC are the problem. If the DNS looks fine and mail is still filtered, tell us what you are seeing and we will look at the headers.