Marketing Cloud Deliverability Checklist
Work through authentication, sending reputation, list hygiene, content and monitoring checks before your inbox placement becomes a problem rather than after.

Most deliverability problems in Marketing Cloud Engagement are not caused by one big mistake. They build up from small gaps: a sending domain that was never fully authenticated, a data extension that keeps mailing people who bounced months ago, an unsubscribe link that takes three clicks. This checklist is meant to be worked through line by line, either before a new sending programme goes live or as a quarterly review of an existing one.
How to use this checklist
Each table below covers one area. For every row, record whether it is in place, who owns it, and the evidence you checked (a DNS lookup, a message header, a query result). A row you cannot evidence counts as not done. If you find several gaps in the authentication section, fix those first: mailbox providers increasingly treat unauthenticated bulk mail as untrustworthy regardless of content.
Exact DNS values for SPF, DKIM and return-path depend on how your account was provisioned, so take them from your account configuration and Salesforce Help rather than copying them from another org. Our guide to SPF, DKIM and DMARC for Marketing Cloud explains how the three fit together.
Authentication and sending domain
| Check | Why it matters | How to verify |
|---|---|---|
| Sending domain is a subdomain you own (for example mail.example.com) | Keeps marketing reputation separate from corporate mail | Review the From addresses in every Sender Profile |
| SPF record includes the Marketing Cloud sending infrastructure | Lets receivers confirm the sending IP is authorised | Look up the TXT record and send a test to a mailbox that shows authentication results |
| DKIM signing is active for the sending domain | Proves the message was not altered and ties it to your domain | Check the DKIM-Signature header and its d= value in a test message |
| DMARC record published with a policy you have chosen deliberately | Major mailbox providers expect DMARC for bulk senders | Look up _dmarc on the organisational domain and confirm reports are being received |
| From domain aligns with the DKIM or SPF domain | DMARC passes only when the authenticated domain aligns with the visible From | Compare the From header with the d= value and return-path domain |
| Reply-to mailbox exists and is monitored | Replies and complaints sent by humans should reach someone | Send a reply to a test message and confirm it lands |
| Private domain or Sender Authentication Package configuration is documented | Rebuilding settings later is slow without a record | Store the DNS records and account settings in your runbook |
Lists, consent and hygiene
| Check | Why it matters | How to verify |
|---|---|---|
| Every sendable audience has a documented consent source | Mailing people who never opted in drives complaints | Trace each audience back to its capture point and consent field |
| Held and bounced subscribers are not being reintroduced by imports | Re-adding bad addresses damages reputation quickly | Compare import files against All Subscribers status before each load |
| Inactive subscribers are suppressed or moved to a re-engagement track | Long-term non-openers drag down engagement signals | Query engagement data views for subscribers with no opens or clicks in your chosen window |
| New dedicated IPs were warmed gradually | Sudden volume from a new IP looks like a spammer | Check the warm-up plan and actual daily volumes per domain |
| Suppression and exclusion lists are applied to every send type | One unsuppressed send can undo months of care | Review send definitions, journeys and triggered sends for exclusions |
| Purchased or rented lists are not used | They contain spam traps and people with no relationship to you | Confirm the source of every list in the audience inventory |
Spotting bounce patterns by domain
Bounce totals hide the most useful signal, which is where mail is failing. A spike at one mailbox provider usually points to a reputation or authentication issue with that provider, while bounces spread across many domains suggest a data quality problem. The query below summarises the last 30 days of bounces from the _Bounce data view by receiving domain and bounce category.
Assumptions: you run it in a Query Activity that writes to a target data extension named Bounce_Summary_DE with fields Domain, BounceCategory and Bounces. Data views hold a limited rolling window of history, so check current retention in Salesforce Help before relying on long look-backs.
SELECT
b.Domain,
b.BounceCategory,
COUNT(*) AS Bounces
FROM _Bounce b
WHERE b.EventDate >= DATEADD(day, -30, GETDATE())
GROUP BY b.Domain, b.BounceCategoryContent, unsubscribe and monitoring
| Check | Why it matters | How to verify |
|---|---|---|
| One-click unsubscribe headers are present on marketing sends | Large mailbox providers expect List-Unsubscribe with one-click support | Inspect the raw headers of a live test message |
| The unsubscribe or preference page works without a login | Friction turns unsubscribes into spam complaints | Click through from a test send on mobile and desktop |
| Every email has a plain, recognisable From name | Recipients complain about mail they do not recognise | Review From names across Sender Profiles |
| Images have alt text and the HTML is not one large image | Image-only mail is hard to read and often filtered | Preview with images off |
| Links point to domains you control or trust | Link domains with poor reputation affect placement | List tracked and untracked link domains in recent sends |
| Complaint and bounce rates are reviewed per send and per domain | Problems are cheaper to fix early | Use data views or a scheduled report and record the review |
| Postmaster or feedback tools from major mailbox providers are set up | They show reputation as the provider sees it | Confirm access and who checks them |
Questions we hear
Do we need a dedicated IP?
What DMARC policy should we start with?
Why are emails reaching spam when authentication passes?
How often should we run this checklist?
Related reading
- Email deliverability consulting if you want an independent review
- Marketing Cloud email deliverability audit checklist for a deeper audit method
- Using data views for engagement reporting
- Building a preference center with CloudPages and AMPscript
Inbox placement slipping?
We can review your authentication, data hygiene and sending patterns and give you a prioritised list of fixes.




