Emails going to spam
Invoices, password resets and newsletters landing in junk — or rejected outright since Google and Yahoo started enforcing their bulk-sender rules.
[ Servers & DevOps ]
Mail in the inbox. Site always reachable.
DNS is a handful of records nobody touches for years, until an email campaign lands in spam, a registrar transfer takes the site offline, or a forgotten CNAME gets taken over. I audit it, fix it and move it without anything breaking.
Every record checked · TTLs planned ahead · $20/hr or fixed price
[ Why you're here ]
Almost every DNS emergency comes back to one of these six.
Invoices, password resets and newsletters landing in junk — or rejected outright since Google and Yahoo started enforcing their bulk-sender rules.
Every tool added its own include until the record passed the 10-lookup limit and started failing with a permerror.
No DMARC policy, so anyone can send phishing mail that looks like it came from you, and you have no reports to show it is happening.
DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL, or a site that loads for you but not for customers after a record or nameserver change.
Changing registrar, DNS provider or email platform, with no complete list of which records exist or which ones matter.
CNAMEs pointing at deleted Heroku apps, S3 buckets or Azure resources — exactly what subdomain takeover attacks look for.
[ How it works ]
Every record in the zone listed and explained: what it points at, whether it is still used, and whether it is a risk. Email authentication checked against real message headers and DMARC reports, not guesses.
TTLs lowered well before any change, a record-by-record migration map written, and a rollback defined. For DMARC, a staged path from p=none to quarantine to reject, based on what the reports show.
Changes made in a quiet window and checked from multiple resolvers worldwide. Test mail sent to Gmail, Outlook and Yahoo, with headers confirming SPF, DKIM and DMARC pass and align.
[ What actually changes ]
DNS and email authentication are covered together, because most deliverability problems are really DNS problems.
[ Example engagement ]
A small company whose invoices and password resets were landing in Gmail spam. SPF had 14 lookups and was failing, two sending tools had no DKIM, and there was no DMARC record. Fixed the records, then moved DMARC to p=reject over six weeks.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
[ Free · quick check ]
Send me your domain. I will check your SPF, DKIM, DMARC and MX records and tell you what is wrong in plain language, whether or not you hire me to fix it.
[ Pricing ]
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Hourly rate $20/hoursmall jobs and ongoing work · fixed price for defined projects
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
For a single bug, a short task or ongoing tweaks, where writing a full scope would cost more than simply doing the work. Billed in real time, reported in writing.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Small fixes, like an SPF record or adding DKIM for a new sending tool, are billed at $20 per hour and usually take an hour or two. Migrations and full deliverability projects get a fixed price, agreed in writing before any work starts.
The most common causes are an SPF record that fails or exceeds 10 lookups, missing DKIM for one of your sending services, no DMARC record, or a From domain that does not align with the domain actually signing the mail. Sometimes it is content or reputation, but authentication is where I look first because it is the easiest to prove and fix.
Anyone sending around 5,000 or more messages a day to Gmail or Yahoo needs SPF and DKIM, a DMARC record, alignment with the From domain, one-click unsubscribe on marketing mail and a spam complaint rate kept below 0.3%. Smaller senders still need SPF or DKIM, and in practice should have both.
Yes. I lower TTLs a few days in advance, recreate every record at the new provider and verify it before changing nameservers, and leave the old zone in place until propagation is complete. MX, SPF and DKIM records get checked twice, because they are what usually breaks.
Not the way I do it. DMARC starts at p=none, which only collects reports. Once the reports show every legitimate sender passing, the policy moves to quarantine and then reject. Jumping straight to reject is how companies stop their own invoices.
Usually a cached answer: your resolver still has the old record, or theirs does. It can also be a DNSSEC mismatch, a missing www or AAAA record, or nameservers at the registrar that do not match the zone you are editing. I check from multiple public resolvers to find out which.
If a DNS record points at a cloud resource you have deleted, such as a Heroku app, S3 bucket or Azure site, someone else can often create that resource and serve content on your subdomain. The audit lists every record like that so it can be removed.
Yes. I work remotely with clients in the US, UK, Germany, Canada, Australia and elsewhere. DNS changes are scheduled for your quiet hours, not mine.
[ Related services ]
[ Guides on this topic ]
[ Let's talk ]
Describe the problem in a few lines and you'll get a real reply from the person who'd do the work — same working day, no discovery call required.