Cold outreach: what an audit fixes, and what it doesn't
Read this part before you buy, because cold outreach is where this audit is most often bought for the wrong reason. I can fix your infrastructure. I cannot make people want your email, and no DNS record has ever done so.
What this usually looks like
- New sending domains burning out within weeks
- Mail rejected outright rather than filtered
- Everything landing in spam regardless of what the copy says
- Deliverability that collapsed after volume went up
What the audit checks for this
Every audit covers the same ground. These are the parts that decide this one.
- Authentication on every sending domain: SPF, DKIM, DMARC, and whether they align
- Reverse DNS, sending IP history, and whether the pool is shared with senders you would not choose
- Domain and subdomain structure, so a burned domain does not take the rest of the business with it
- Whether the technical setup is the constraint at all — which, for cold outreach, it often is not
The part people don't want to hear
- Reputation earned by sending to people who did not ask cannot be configured away. If recipients are reporting you, the filters are working as designed and the audit will say so.
- I will not help you evade filters, rotate domains to stay ahead of blocks, or make unsolicited mail look like something else.
- Unsolicited email to individuals in the EU is restricted by law, separately from whether it is delivered. That is a question for your lawyer, not for me.
- If the diagnosis is "your infrastructure is fine and your approach is the problem", that is what the report will say. Some people find that worth €179 and some do not — decide now rather than after.
Forward-confirmed reverse DNS, in three commands
This is the first thing a receiving server checks and the first thing a burned sending setup fails. It costs nothing to verify and it is wrong on most cold outreach infrastructure I am shown.
$ dig +short MX sslcanary.com10 mail.cyborg.ovh.
The host that handles mail for the domain.
$ dig +short A mail.cyborg.ovh15.235.80.115
Forward: the name resolves to an address.
$ dig +short -x 15.235.80.115mail.cyborg.ovh.
Reverse: the address resolves back to the same name. The two agree, which is what "forward-confirmed" means and what a receiver is testing.
When these disagree — a generic PTR from the hosting provider, or no PTR at all — some receivers reject on that alone and others quietly weight it against you. On a rotated sending domain it is usually the second thing wrong, after the fact that the mail is unsolicited. Fixing it is a support ticket with the host. It will not make unwanted mail wanted, and this page has already said what that means.
Questions people ask about this
- Can a deliverability audit fix cold email going to spam?
- It can fix the infrastructure: authentication, alignment, reverse DNS, domain structure, and whether your sending IPs have a history. It cannot fix reputation earned by sending to people who did not ask. If recipients are reporting you, the filters are working as designed and no DNS record changes that.
- Why do my cold email domains keep burning out?
- Because reputation is being consumed faster than it is built. Rotating to a fresh domain resets the counter without changing the cause, which is why it keeps happening. An audit will tell you whether the technical setup is contributing — it often is — but it will also tell you if the setup is fine and the approach is the constraint.
- Is cold email legal in the EU?
- Unsolicited email to individuals is restricted under the GDPR and the ePrivacy rules, and the position for B2B differs by member state. That is a question for a lawyer, not for a deliverability audit. Whether mail is delivered and whether it is lawful are separate questions and this service only answers the first.
- Will you help me get past spam filters?
- No. I will tell you whether your infrastructure is broken and how to fix it. I will not help anyone evade filters, rotate domains to stay ahead of blocks, or disguise unsolicited mail as something else. If that is what you need, this is not the right service and you should not buy it.
Where this comes from
Everything above is checkable against the specifications that define it. These are the documents, not a summary of them.
- RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
- RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Google Email sender guidelines
One domain, one report, by email within 48 hours of your intake. No account, no call.
Not sure it covers your setup? Ask before you buy: audit@strictmx.com