A deliverability audit that ends with a list of who fixes what.
We audit why your email is not landing, in the order a receiving server evaluates it, and hand back findings split into what we fix, what your ESP fixes and what your own IT has to publish. Most items are twenty-minute jobs. The one that takes two weeks is the one everybody skips.
The first thing an audit reads.
Not a dashboard. The raw header of one real message, sent through the path you actually use. This one passes both checks it is given and is still rejected, which is the single most common finding we write up.
Authentication-Results: mx.google.com; spf=pass (google.com: domain of bounce@sendingplatform.com designates 203.0.113.9 as permitted sender) smtp.mailfrom=sendingplatform.com; dkim=pass header.i=@sendingplatform.com header.s=s1; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourcompany.com
- spf=passThe envelope sender is allowed to use that IP. Nothing to do with your domain.
- dkim=passThe signature is valid. It is signed by the platform, not by you.
- dmarc=failNeither domain matches
header.from, so the message is treated as a forgery. Two passes and a rejection.
- Right for you if
- Replies have gone quiet, bounces have climbed, or you are about to start sending properly and would rather find the broken record now than after the first campaign.
- What it includes
- The sender inventory, header analysis on live mail, SPF, DKIM and DMARC review, unsubscribe and suppression testing, complaint and reputation data, and a written fix list with an owner against every item.
- What it does not include
- We do not take control of your DNS, we do not resell you a monitoring platform, and we do not guarantee inbox placement, because nobody who understands the system can.
Alignment is what breaks, not authentication.
Nearly every tool in this area reports passes, and passing is not the test. Google's own sender guidance is that the domain in the From header must align with either the SPF domain or the DKIM domain, and that is what is required to pass DMARC.
Fails
- SPF domain
- sendingplatform.com
- DKIM d=
- sendingplatform.com
- From header
- yourcompany.com
SPF passes. DKIM passes. Neither domain is the one in the From header, so DMARC fails and a message you really sent is treated as a forgery.
Passes
- SPF domain
- bounce.yourcompany.com
- DKIM d=
- yourcompany.com
- From header
- yourcompany.com
The same two checks pass, and now they are on your domain. That is the entire difference between arriving and being rejected.
The detailClose
The common shape: you send through a platform, the envelope sender is the platform's bounce domain, SPF passes for that domain, and the From header says yours. SPF passed. It did not align. If DKIM is also signing with the vendor's domain, DMARC fails, and the only reason the mail is still arriving is that your policy is not enforcing yet. That is a state that looks healthy right up to the week it does not.
Publishing a record is not the same as fixing the problem, and this is the single most common finding we write up.
What we fix, what your ESP fixes, and what your IT has to do.
Findings come back in three columns, because a fix list with no owner against each line is a document that gets filed and admired.
We do
The inventory, the header analysis, the record drafting, the unsubscribe and suppression testing, reading the aggregate reports rather than filing them, the copy and cadence changes that bring complaint rate down, and the sequencing of the policy move.
Your ESP does
The branded sending domain and the DKIM key pair, PTR records on the sending IPs, TLS on the connection, and feedback loop registration. Most of this is a support ticket and a setting, and we write the ticket for you to send.
Your IT does
Publishes the records. We hand over the exact TXT values with a line each saying what it does and what breaks if it is wrong, and your team puts them in the zone. We do not ask for control of your DNS, and you should be suspicious of anyone who does.
Nobody does
There is no configuration that fixes a list which should not be mailed. If the finding is that a third of the addresses have not engaged in a year, the answer is to stop sending to them, and that is a decision rather than a task.
The rest of it.
The parts that are an argument rather than a mechanism. Open whichever one you are actually weighing.
The audit, in the order we would actually run it.
The order is the method. Each step depends on the one before it, and running them out of sequence produces findings you cannot act on: a DNS record drafted before the sender inventory exists will be missing a service, and a policy moved before the reports are clean will stop legitimate mail. This is about a week of small jobs, most of them twenty minutes.
- Find out what you actually send
- How many messages leave each domain in a day at peak, counting every system, and which systems those are. The list is always longer than marketing thinks: the CRM, the ESP, the invoicing tool, the helpdesk, the applicant tracking system, the scheduler, the survey, somebody's automation. You cannot authorise senders you have not enumerated.
- Read one real message's headers
- Before touching DNS. Send through the actual sending path, open the raw source, and read the Authentication-Results header. Alignment failures show up here and nowhere else, which is why the audit starts with a message rather than with a lookup tool.
- SPF: one record, inside the lookup budget
- One record at the apex, listing only the senders from the first step. Every include, a, mx and redirect counts against a cap of ten DNS lookups, and going over returns permerror, which fails the whole check. Two SPF records on one hostname fail it as well.
- DKIM signed with your domain
- A key pair generated by the sending platform and a selector published in your DNS, so the signature's d value is your domain rather than your vendor's. The setting is usually called a branded or authenticated sending domain, and it is a support ticket and a checkbox more often than it is a project.
- DMARC at p=none, with a real reporting address
- It proves nothing on the day you publish it, and that is the point. It turns on the aggregate reports that name every system sending as you, which is how the four services missing from the first step get found.
- One-click unsubscribe, tested the way a recipient would
- The RFC 8058 header pair and an endpoint that accepts an anonymous POST with no login screen behind it. Then the actual test: use the provider's own unsubscribe control, watch for the POST in the logs, and confirm the address is gone from the next send.
- PTR, forward-confirmed DNS and TLS
- Usually your platform's job, verified anyway, and verified carefully if anything sends from your own infrastructure. These are refusals at connection time rather than spam-folder placements, so nothing downstream will ever show you the failure.
- Read the complaint numbers
- Google Postmaster Tools and Yahoo's Sender Hub. This is the only opinion that decides delivery; everything upstream is a prerequisite for being judged at all. If Postmaster Tools is empty, that is itself a finding, because it only populates for domains that have published DMARC.
- Then, and only then, move the policy
- Quarantine, and later reject, after two weeks of aggregate reports showing legitimate mail authenticating cleanly. It is the only step in the list that can break something, which is exactly why it is last.
The complaint rate is the number with the hard ceiling.
Google asks senders to keep spam rates reported in Postmaster Tools below 0.10% and to avoid ever reaching 0.30%. Those requirements apply to senders of more than 5,000 messages a day to Gmail accounts and took effect on 1 February 2024, and Microsoft's own version rejects non-compliant bulk mail to its consumer domains outright rather than junking it.
A small program should care about a bulk rule for two reasons, and neither of them is the threshold. Rejection is evaluated against your organisational domain, so the ESP blasting a newsletter and the sales rep writing to eleven people share one reputation: a disciplined program can be refused because a different department is not. And 0.10% is one complaint per thousand messages, so a program sending six hundred messages in a month has no headroom inside that ratio at all. Providers compute over a rolling window rather than a calendar month, so one bad week is not the whole picture, but the direction is clear. Small high-intent programs have less room for a careless send than a large list does, not more.
What actually moves the number: sending to people who have not engaged in ninety days, consent nobody remembers giving, a subject line that overstates what is inside, and an unsubscribe that is harder work than the spam button.
Campaign operations, for after the audit.
An audit is a snapshot, and deliverability drifts because nobody owns it between campaigns. So the second half of this service is the ongoing part, if you want it, and it is the work the site used to call campaign operations.
That means ESP setup and hygiene: the suppression list, the unsubscribe endpoint, the seed addresses, the sending schedule, the templates in the account. It means reading the DMARC aggregate reports every fortnight and moving the policy when they say it is safe, which is the step almost everyone publishes a record and then never takes. And it means a reporting line that says what happened rather than what looks good.
What that report does not lead with is an open rate. Apple's Mail Privacy Protection downloads remote content in the background by default, regardless of whether the recipient engages with the email, so a share of every open figure is a proxy rather than a person. We report sends, bounces by class, complaint rate, unsubscribes, replies and meetings, and we say which of those we think moved for a reason and which is noise.
What an audit will not do.
It will not guarantee inbox placement, and any consultant who offers that is selling something. Authentication is necessary and not sufficient: passing all three checks gets your mail judged rather than refused, and the judgement is made on your sending behaviour over weeks.
It will not repair a reputation quickly. A domain that has been mailing a stale list at a high complaint rate needs weeks of clean sending, not a DNS change, and the honest version of that timeline is one of the less popular things we say.
And it will not make a bought list work. If the finding is that the list is the problem, we will write that down, and nothing else on this page fixes it.
The long version.
We write these up properly, with the sources in line, so you can check the reasoning rather than take our word for it.
Questions.
How long does the audit take?
About a week, most of which is waiting rather than working: DMARC aggregate reports need a day or two to start arriving, and they are what turn an inventory you wrote down into an inventory that is true. The written findings follow within a week of that.
Do you need access to our DNS?
No. We write the exact records and the reason for each one, and your own team publishes them. Handing DNS control to an agency is a risk with no matching benefit, and we would rather not be able to break your mail by accident.
We are nowhere near 5,000 messages a day. Do these rules apply to us?
The threshold does not, and the consequences do. The gates are evaluated against your organisational domain, so another team's newsletter and your sales mail share one reputation. And a small program has less complaint-rate headroom than a large one, not more, because 0.10% of six hundred messages is less than one complaint.
Can you guarantee we will land in the inbox?
No, and nobody can. Authentication decides whether you are judged at all; sending behaviour over weeks decides where you land. What we can do is remove every reason to be refused before the judgement, and tell you honestly which findings are ours to fix and which are yours.
Our open rate dropped. Is that a deliverability problem?
Sometimes, and the open rate is a poor instrument for finding out. Apple downloads remote content in the background whether or not anyone reads the message, so the number is part machine. A sharp drop is still worth investigating as a system health signal, but we would look at bounce classes, complaint rate and reply rate before concluding anything.
Do you do this without running our campaigns?
Yes, and most of this work is bought that way. The audit and the fix list stand on their own, and plenty of teams take them and do the sending themselves. If you want somebody to own it between campaigns afterwards, that is the ongoing half and it is optional.
Sources on this page: Google, email sender guidelines, PowerDMARC, bulk email sender requirements, Red Sift, bulk email sender requirements, MarTech, new rules for bulk email senders, RFC 8058, one-click unsubscribe, Apple, Mail Privacy Protection.
Start a conversation.
Tell us what you are trying to fix. If we are the wrong people for it, we will say so in the reply and point you at what we would do instead.
- A reply from a person, within one working day.
- If it sounds like a fit, a thirty minute call. No deck.
- A written plan within a week of that call, and no retainer until you have read it.
If a form is not your thing, hello@draftship.io reaches the same inbox.