How to Audit Your Email Marketing Program
A twenty-two point audit covering authentication, list health, automation drift and the sequences still describing a product you no longer sell.
On this page
The short version
- Most audits find the same three things: authentication that was never completed, automation describing a product that changed, and a segment nobody has mailed in a year.
- Run it in the order below. Authentication first, because a fault there makes every downstream measurement unreliable.
- Give each check a pass condition before you start, or the audit becomes an opinion.
An audit is only useful if it can fail. That means writing the pass condition before you look, rather than inspecting each area and forming a view. The twenty-two checks below each have one, and most take a few minutes.
The order matters. Technical faults distort every metric above them, so an audit that starts with creative review ends up drawing conclusions about subject lines from data that was never sound.
Part one: technical foundation
Authentication and DNS
Check that SPF resolves within the ten-lookup limit, that DKIM is signing with a key you control rather than your provider's shared domain, and that DMARC exists with a policy and a reporting address that someone reads.
The common failure is a DMARC record published at p=none years ago as a first step, with nobody ever returning to it. That is not a fault exactly, but it means you have been collecting reports nobody opens while remaining unprotected against spoofing.
- SPF record exists and stays under ten DNS lookups
- DKIM signs with a domain-aligned key, not a shared one
- DMARC record exists, with rua reports going somewhere monitored
- Return-path domain aligns with the from domain
- Sending domain has a valid MX record and can receive replies
Reputation and delivery
Look at bounce rate over the last six sends, complaint rate per send and per segment, and placement across at least two major providers. Any segment above the complaint ceiling is an emergency regardless of what the overall figure says.
- Hard bounce rate under 2% on recent sends
- Complaint rate under 0.1% overall and per segment
- Not listed on any blocklist that affects major providers
- Bounce suppression is automatic and verified working
Part two: list health
The question here is not how many subscribers you have but how many are contributing. Break the list into engagement tiers and look at the size of the never-opened group, because that group is paying no rent and costing you delivery.
Check consent records too. Not because anyone is likely to ask this week, but because the audit is the only time anyone will look, and a list segment with no recorded consent source is a liability you want to know about deliberately rather than discover under pressure.
- Every subscriber has a recorded source and consent date
- Engagement tiers exist and someone can state the size of each
- Never-opened segment is under a fifth of the list
- A sunset rule exists and has actually been run
- Duplicates have been checked in the last quarter
- Suppression list is respected across every sending tool
Part three: automation drift
Every automated flow should be opened, read end to end as a subscriber would receive it, and checked against current reality. This is tedious and it is where audits find the most embarrassing problems, because automation is invisible by design.
Pay particular attention to exit conditions. A nurture sequence that does not exit when someone buys keeps selling to customers, and a re-engagement flow with no defined end keeps mailing people who have made their position clear.
- Every live flow has been read end to end in the last six months
- Prices, names, features and links in flows are current
- Each flow has an exit condition and it has been tested
- No subscriber can be enrolled in two conflicting flows at once
- Welcome sequence still matches the promise on the opt-in form
Part four: content and measurement
Finally, the parts most audits start with. Render the last six sends on a phone and in dark mode. Check that every send had a stated purpose and one action. Confirm the reporting matches what is actually being decided.
- Recent sends render correctly on mobile and in dark mode
- Each send has one primary action, not three
- Alt text exists and says something useful
- Unsubscribe is one click and visible without scrolling the footer
- Reported metrics match the three the programme is judged on
- UTM parameters are consistent enough to group in analytics
- Someone can state the programme's success metric without looking
What to do with the findings
| Severity | Definition | Timeline |
|---|---|---|
| Blocking | Distorts every other measurement or risks delivery | This week |
| Structural | Wrong by design, will recur if not changed | This quarter |
| Drift | Was right once, has aged | Next scheduled review |
| Improvement | Working, could work better | Backlog |
Anything in the technical section that fails is blocking by definition, because you cannot trust the numbers you would use to prioritise everything else.
Frequently asked questions
How often should this be run?
Fully once a year, with the technical section quarterly. The technical checks take under an hour and catch the faults that silently invalidate months of data.
Who should run it?
Ideally not the person who built the programme, because drift is hardest to see in your own work. If that is not possible, run it against the written pass conditions rather than by judgement.
What if we fail most of the technical section?
That is common and fixable in a few days. Do them in order — authentication, then suppression, then hygiene — and re-baseline your metrics afterwards rather than comparing against the contaminated history.