Email Deliverability Audits: Check Authentication, List Quality and Sending Practice

Email deliverability audits work best when they begin with a precise failure. A password reset that never leaves a queue, a newsletter rejected by one provider and a promotion accepted into a spam folder require different investigations. Changing every DNS record at once makes those investigations harder and can interrupt mail that was working.

This guide gives Canadian marketing and operations teams a practical audit sequence: define the symptom, inventory the sending paths, collect authentication evidence, examine audience practices, test unsubscribe handling and stage a recoverable fix. The outcome is an evidence register with accountable actions. Authentication does not guarantee inbox placement, and it does not establish permission to email someone.

Requirements checked: 8 October 2026. Provider policies can change. Follow the linked primary documentation when carrying out an audit. All businesses, domains, message samples and numerical examples below are fictional. The companion templates contain no customer data.

1. Define the email deliverability problem before changing anything

Write a one-sentence incident statement that another person could verify: “Since Tuesday’s newsletter launch, messages from our campaign platform to personal Gmail addresses have returned an authentication rejection; order confirmations through the store platform appear unaffected.” Record the date, timezone, message stream, platform and evidence behind each clause. “Our email is broken” is too broad to assign or test.

Separate four stages. Submission means your application handed a message to a sending service. Acceptance means a receiving server accepted responsibility for it. Placement describes where the message appeared, such as the inbox or spam folder. Recipient action means someone read, replied or completed another action. A dashboard label such as “delivered” needs its vendor’s definition before you use it as placement evidence.

Choose a comparison window that matches the symptom. For a sudden incident, retain the last known working send and the first affected send. For a gradual decline, compare several similar campaigns and note changes in audience, volume, provider mix and content. Do not compare a sale sent to your entire database with a receipt sent to recent purchasers and attribute every difference to infrastructure.

For each branch, write what remains unknown. One screenshot of a spam folder demonstrates that recipient’s experience, not a universal placement rate. One successful message demonstrates a working path at that time, not a healthy domain. This discipline keeps your conclusions proportional to the evidence and makes later remediation easier to assess.

2. Inventory every legitimate sending path

Start with the people who own the work: marketing, customer support, sales, finance and whoever maintains the website. Ask each to identify systems that send email using the organisation’s identity. Common omissions include quotation software, booking reminders, form notifications, billing tools, help desks and older automations that nobody remembers until they stop working.

Create one inventory row per stream and sending path. Record the visible From domain, envelope sender domain, DKIM signing domain and selector where available, platform owner, purpose, usual schedule and criticality. Add who can approve changes and who can restore the previous configuration. A marketing manager may own the campaign while a hosting provider controls the sending IP’s reverse DNS.

Classify messages by their real purpose. A requested password reset, a receipt and a subscribed newsletter should have separate rows even if the same supplier sends them. A receipt with a prominent promotional offer deserves a content review; a template category called “transactional” is not conclusive. Keep essential service communications operational while correcting marketing practices.

Use evidence references instead of pasting private messages into a broadly shared spreadsheet. “Restricted message sample S-014” is enough for the register if authorised reviewers can retrieve it. Redact personal addresses, order details, message bodies and unsubscribe tokens from public examples. Assign a retention date to the underlying records and keep access limited to people doing the audit.

Write the permitted scope explicitly. Reviewing exports supplied by the mail administrator is different from changing DNS, sending test messages or calling an unsubscribe endpoint. Agree on test recipients and message types before any live test. The supplied files support offline planning; they do not discover domains, connect to accounts or send email.

If your real question is how a team should assign conversations, Canada Create’s shared inbox tools guide covers that workflow. Here, the inventory exists to establish which sending paths must survive a technical change. Software selection is a separate decision.

3. Apply the right provider requirements to the right traffic

Do not apply one provider’s threshold to every mailbox. Record destination-provider volumes for each relevant period, then determine applicability using that provider’s definitions. Keep an “unknown” value when your exports cannot establish the count. Splitting a campaign between tools does not necessarily split the identity that a receiver evaluates.

Google’s FAQ defines bulk senders as reaching close to 5,000 or more messages to personal Gmail accounts in 24 hours, aggregates the same primary domain and its subdomains, and retains that classification once reached. Its guidelines also require TLS, appropriate forward/reverse DNS and compliant formatting. Google requires spam rates below 0.3% and recommends a reported spam rate below 0.1%, never reaching 0.3% or higher. Google sender guidelines and bulk-sender FAQ provide the detail.

Yahoo does not publish a numeric bulk threshold. Its FAQ excludes transactional messages from the one-click requirement and distinguishes Yahoo-hosted brands from Yahoo Japan. Yahoo requires spam rates below 0.3%, calculated against inbox-delivered mail. Its policy accepts the mailto header method, while strongly recommending RFC 8058 POST. Gmail does not accept mailto alone for its one-click requirement. Use the stricter applicable implementation when serving both audiences. See Yahoo’s requirements and Yahoo’s FAQ.

Microsoft’s updated announcement specifies rejection for authentication non-compliance beginning 5 May 2025 and identifies error 550 5.7.515. Do not repeat the superseded “Junk first” rollout wording. The announcement concerns the consumer service; it is not a complete policy description for every Microsoft 365 tenant. It does not establish an RFC 8058 mandate or a universal two-day deadline. See Microsoft’s sender requirements announcement.

For your audit, store the source URL, check date and applicability decision alongside the finding. “Required by Gmail for this stream” and “recommended operational improvement” are different statements. This prevents a sensible preference from becoming an unsupported claim about provider enforcement.

4. Inspect authentication as a chain of evidence

SPF: identify the envelope domain and authorised sender

SPF evaluates whether the connecting sender is authorised for the relevant envelope identity; a record on the visible From domain may not be the record being evaluated. Check the actual envelope domain for each platform. Under RFC 7208, multiple SPF records at the same name are invalid, and SPF limits DNS-querying terms during evaluation to ten, including nested processing. Counting visible include statements alone is insufficient.

Ask the technical owner for the current record, its evaluated dependencies and the receiving system’s result for a representative message. Record whether the platform manages its own return path or uses a configured domain belonging to your organisation. If an undocumented sender appears, investigate its owner before removing it. If it is unauthorised, contain it through the appropriate incident process.

A proposed SPF correction should say exactly which legitimate source it restores and which existing sources must remain authorised. Do not use an unrestricted policy to make an error disappear. Do not replace an established record with a vendor example that omits finance or support systems. Keep the proposed change and the prior value together for review.

DKIM: check a received signature, not just a setup badge

DKIM associates a message with a signing domain and protects signed content. The selector identifies which public key a verifier retrieves. A provider can display “domain verified” while a particular route sends unsigned mail or uses a different signing identity. Compare actual received-message results with the configured signing domain and selector. RFC 6376 describes signatures, selectors and key transitions.

Ask which system adds signatures and whether anything modifies the message afterwards. Footer insertion or another relay may deserve a separate test. For a planned key rotation, the owner should account for queued messages signed with the previous key and retain the appropriate overlap. Deleting an old selector immediately after switching new mail can undermine messages already in transit.

DMARC: check alignment with the visible From domain

DMARC needs a passing, aligned SPF identity or a passing, aligned DKIM signature. Relaxed alignment compares organisational domains; strict alignment requires identical domains. A pass belonging only to an unrelated vendor domain does not authenticate your visible From identity. The current base specification is RFC 9989, published in May 2026, which replaces RFC 7489.

For the fictional Alder Workshop, suppose From is news@alder.example, SPF passes for bounce.vendor.example and DKIM passes for alder.example. The aligned DKIM path can support DMARC. If both passing identities belong only to vendor.example, the visible Alder identity remains unaligned. These are teaching observations, not signatures that have been cryptographically verified.

Record the policy actually applicable to the message’s From domain, including subdomain behaviour, rather than assuming the organisational domain’s record tells the whole story. Keep authentication results, alignment conclusions and requested policy disposition in separate fields. “p=none” describes a policy choice; it is not the same as “DMARC passed.”

Use results added by the trusted receiving system and preserve how you obtained them. A pasted header labelled Authentication-Results can be forged or copied from another message; its presence alone is not proof. RFC 8601 discusses that trust boundary. A genuine audit ties each result to a specific authorised sample and receiving path.

5. Protect forwarding, mailing lists and essential messages

A direct message and a forwarded copy may have different authentication outcomes. Forwarding changes the connecting server, which can affect SPF. Changes to signed content can affect DKIM. Authenticated Received Chain, or ARC, provides a way for intermediaries to convey authentication assessments along a chain; receivers still decide how much to trust it. ARC is not a universal delivery override.

Add an indirect-mail branch to the inventory when the organisation uses forwarding addresses, distribution lists or gateways. Ask the mail administrator to identify a representative path and explain which system changes the envelope, headers or body. Compare a direct sample with an authorised forwarded sample only when both are available. If you cannot observe the path, record that limitation before proposing a stronger domain policy.

Do not solve a newsletter problem by imposing a blanket reject policy across an incompletely inventoried domain. Equally, do not routinely weaken an established protective policy because one sender is misconfigured. The repair may belong at the sender: an approved signing identity, a corrected return path or a supported relay. The right action depends on which legitimate traffic would be affected.

A useful change proposal names three things: the intended benefit, the potentially affected legitimate streams and the evidence needed to proceed. For example, a fictional team might require passing samples from invoicing, booking and support before changing policy for its main domain. That is a local acceptance criterion, not a provider rule.

Record essential communications separately in the stop conditions. A marketing complaint should suppress applicable marketing. It should not automatically disable a password reset that a customer requests later. At the same time, “essential” cannot become a label for sending offers after someone opted out. Give ambiguous templates to the relevant business and compliance owners before designing technical suppression rules.

6. Audit list quality and permission before increasing volume

Authentication answers an identity question. Permission answers whether you may send a particular message to a particular person. The CRTC identifies consent, sender identification and an unsubscribe mechanism as the core requirements for commercial electronic messages under CASL, subject to applicable exceptions. Its consent guidance also emphasises retaining proof and recognising that implied consent can expire.

Build a source-by-source audience review. For each acquisition source, record what recipients were told, the collection date, the permission basis, the scope of messages covered and where evidence is retained. A “subscribed=true” field with no history is a claim to investigate. An email address copied from a sales record does not, by itself, tell the auditor what that person agreed to receive.

Group records by evidence quality rather than inventing a single deliverability score. One group may have recent, retrievable subscription records. Another may have incomplete imports needing review. A third may contain explicit opt-outs or invalid recipients that should already be suppressed. Assign an owner to each exception and prevent uncertain records from being casually reintroduced through a later upload.

Check the mechanics of suppression across systems. When someone unsubscribes in the campaign platform, does a CRM sync mark them appropriately? If sales exports a fresh list tomorrow, does the import preserve that decision? If a recipient makes a broader marketing opt-out request, does a list-specific preference accidentally leave other marketing streams active? Test these as distinct scenarios.

Classify bounces using the actual response. A permanent nonexistent-recipient failure supports suppressing that destination. A policy rejection caused by your authentication does not prove every affected address is invalid. An overloaded server or temporary rate limit should not trigger automatic deletion of legitimate contacts. Keep the reason and original event accessible so someone can explain the decision later.

Review inactivity cautiously. Use signals appropriate to your business, such as requested communications, recent replies or relevant purchases, alongside permission records. Do not treat a missing open as proof that an address is abandoned. Google itself notes that third-party open rates are not a reliable standalone indicator of delivery trouble. If you define an inactivity rule, document the window and exceptions rather than calling it a universal industry cutoff.

For Canadian teams, the operational label “transactional” is not a legal exemption by itself. The CRTC’s CASL FAQ considers a message’s content and purposes. Obtain qualified advice where the permission basis or exception is uncertain. A deliverability audit should surface the question with its evidence, not manufacture a legal conclusion from a template name.

Audience acquisition and content planning have their own workflow, covered in Canada Create’s audience-building guide. The deliverability audit starts where those practices create operational evidence: who joined, what they expected, what they receive and how their choices are honoured.

7. Test one-click unsubscribe as an end-to-end process

A visible footer link and a standards-based one-click header are different mechanisms. Gmail requires the latter for applicable bulk marketing traffic and excludes transactional messages from that specific requirement. It recommends processing requests within 48 hours; its FAQ also makes timely processing relevant to mitigation eligibility. Yahoo requires applicable requests to be honoured within two days. Use a shorter internal processing target where practical.

In RFC 8058, the message has a List-Unsubscribe header containing an HTTPS URL and a List-Unsubscribe-Post header with the specified value. The receiving service sends an HTTPS POST. A valid DKIM signature must cover both headers. The endpoint must work without a login, cookies or another confirmation step, and must not redirect the POST. Its request must not depend on HTTP authorization or other browser-session context. The standard permits non-HTTP/S alternatives such as mailto alongside its single HTTPS URI; the kit intentionally checks only a narrower single-HTTPS fixture.

This fictional header fragment illustrates the two fields. It is incomplete email, contains a fake token and cannot unsubscribe anyone:

List-Unsubscribe: <https://preferences.alder.example/u/fictional-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Ask the platform owner to test the full journey using an authorised test subscriber. Confirm that the correct headers are present on the received message, that the DKIM signature covers them, and that the endpoint processes the request. Then inspect the stored subscription state and attempt the next controlled marketing selection. A successful web response alone does not prove suppression reached the system that sends tomorrow’s campaign.

Include a repeated-request case. The same legitimate unsubscribe may arrive more than once, and handling it should not restore the subscription or produce conflicting state. Include a list-scope case and a broader opt-out case. Use fake subscribers in an isolated test environment first; use a controlled live test only under the mail owner’s approved procedure.

Test safe fetching behaviour too. The purpose of the POST design is to avoid accidental unsubscribe actions caused by software fetching links. A GET request should not perform the one-click unsubscribe action. Protect tokens as sensitive capability links; do not publish real examples, paste them into tickets with broad access or let an audit tool follow them indiscriminately.

Finally, inspect the reader-facing footer at a normal mobile text size. A functional machine endpoint does not make an invisible body link usable. Record whether a recipient can find the link and understand the preference that will change. Do not promise that the mailbox provider will display its own unsubscribe button merely because the headers exist; display eligibility is a separate decision.

8. Examine sending practice and interpret errors precisely

Make a simple timeline of changes: a list import, a new supplier, a different From address, a new tracking domain, a campaign burst, a template change or an authentication update. Put each change beside the first observed symptom. Sequence does not prove cause, but it identifies useful comparisons and prevents a recent infrastructure change from disappearing into a general discussion about copy.

Compare traffic within a stream and destination provider. Record attempted messages, accepted messages, temporary deferrals and permanent failures using a documented counting rule. For retries, decide whether a row represents a unique message or a delivery attempt. Mixing these units can make a queue incident look like a sudden expansion of the audience.

Preserve the complete SMTP response, not just a dashboard’s “bounce” label. Google’s current SMTP reference distinguishes SPF rejection 5.7.27, DKIM rejection 5.7.30 and several different reasons under 5.7.26. Read the diagnostic text to choose the next check. A code family is a clue, not permission to apply a generic fix.

Yahoo’s error guidance describes 421/451 responses as temporary and 553/554 as permanent. Temporary failures may warrant a later retry through the sending platform’s queue policy. Permanent failures should not be repeatedly resent unchanged. Distinguish invalid-recipient cases from authentication and content-policy cases before deciding whether to suppress a contact or repair the sender.

For Microsoft’s 550 5.7.515, collect SPF, DKIM and DMARC evidence for the affected route and compare it with the high-volume requirements. A passing DMARC result alone does not establish that both SPF and DKIM met that policy. Escalate with a sanitised sample, timestamps, the sending identity and the full response. Do not frame adding recipients to a safe-sender list as the authentication repair.

Manage a ramp as an observation process. Choose an initial authorised audience and a sending pace that the platform and operational team can support. Review the next step only after the agreed evidence window. There is no universally safe “double every day” schedule. If deferrals, complaints or critical-message failures worsen, stop expansion and inspect the affected stream.

A new domain or dedicated IP is not an audit conclusion by default. It introduces configuration, history and operational responsibilities of its own. Ask what concrete problem the proposed move solves and what evidence would show success. Moving an unwanted audience to a different identity does not address the reason recipients objected.

9. Build a measurement sheet with honest denominators

For each rate, store the numerator, denominator, period, provider and source definition. “Three complaints” is incomplete. Three complaints among 900 inbox-delivered messages is about 0.333%; three among 1,200 attempted messages is 0.25%. In this fictional example, changing the denominator changes the result without changing a single recipient’s response.

The companion rate function returns no rate when the denominator is zero and rejects negative counts, fractional counts and a numerator larger than the denominator. These checks catch spreadsheet mistakes; they do not determine which provider denominator is correct. Use the definition from the report you are interpreting, and retain missing observations as unknown.

Keep provider-reported complaint rates separate from a rate calculated from feedback events in your own system. Some evidence may be delayed, incomplete or unavailable for your volume. “No data” and “zero complaints” are different observations. Ask the administrator for the report’s scope and coverage before using it to approve an expansion.

Authentication reports also have a bounded purpose. DMARC aggregate reporting describes evidence about evaluated traffic, authentication and disposition. It is not a complete inbox-placement census. Report availability depends on participating receivers, and external report destinations raise data-handling considerations. Set an owner for reports rather than publishing an unattended collection address.

Use a small decision panel: current incident, affected stream, authentication evidence, unresolved list-quality issues, unsubscribe test status, provider response trend and next review. Add the customer impact alongside the technical metric. For a booking business, delayed confirmations may require more urgent attention than a modest decline in newsletter engagement, even when the newsletter sends far more messages.

10. Turn findings into staged remediation with rollback

Prioritise by demonstrated harm and dependency. An opt-out that is ignored needs containment. An essential message that is failing needs incident ownership. An incomplete sender inventory blocks confidence in domain-wide changes. A cosmetic reporting issue can wait if it does not change the decision. Do not turn every observation into an urgent task with the same deadline.

Give each finding a status: not checked, unknown, pass, fail or not applicable with a reason. “Pass” requires a dated evidence reference. “Unknown” is a useful result when the relevant platform owner has not supplied evidence. Do not silently convert it into a pass because the domain has a record somewhere.

A rollback plan is more than “undo.” Record the exact prior configuration, who can restore it, the trigger, verification steps and expected delay. DNS caches and queued messages mean restoration is not instantaneous. Ask the technical owner to explain how the change’s TTL and message lifecycle affect recovery. Never promise an exact recovery time without evidence from the actual system.

Some actions must not be rolled back in the usual way. Do not restore unsubscribed recipients from an old export. Do not re-enable an unauthorised sender merely because it appears in a backup. Treat consent withdrawals and incident containment as current facts that survive restoration of application or configuration state.

Before proposing stronger DMARC policy, review legitimate senders and indirect paths. RFC 9989 advises against p=reject for general-purpose email domains because of interoperability risks; a restricted-purpose sending domain requires its own assessment. This is a reason for administrator-led scope review, not an instruction to remove an existing protective policy. RFC 9989 removes the old pct tag; do not describe pct=10 as a dependable contemporary ten-percent safety valve. Stage operationally through validated sender paths and carefully reviewed policy scope, with the administrator checking receiver and supplier behaviour. A published specification does not prove every implementation has adopted it.

Define acceptance before testing. For example: the corrected campaign path must show the intended identities on controlled samples; the unsubscribe test must block the next matching marketing selection; and the invoice path must retain its previously verified behaviour. Add a named review time and the evidence that would stop expansion. These are auditable decisions even before you have enough data to discuss broader trends.

11. Worked example: a fictional workshop with two separate faults

Alder Workshop is a fictional Canadian business. It uses one platform for newsletters, another for order receipts and a shared inbox for customer replies. Its team reports that a new campaign is being rejected and that one test subscriber remains eligible after using the preference link. None of the following events describes a client or a live test.

The auditor first splits the incident into two findings. The campaign’s fictional received sample records SPF passing for an unrelated vendor domain and DKIM failing. That combination does not provide a passing aligned path for the visible From domain. The receipt fixture records a passing aligned DKIM identity. This does not prove every receipt works; it identifies a route that must be protected during the campaign repair.

The second finding concerns suppression. In the imagined test, the preference system marks the newsletter subscription inactive, but a later CRM import recreates eligibility. Fixing DNS would not repair this fault. The plan therefore assigns authentication to the mail administrator and preference propagation to the CRM owner, with separate tests and evidence references.

The marketing owner pauses the affected newsletter audience while investigation continues. The team preserves the source export, current settings and a redacted sample. It does not erase every rejected address, move the audience to another domain or change the receipt stream simply to make the incident look smaller.

The proposed authentication change uses the campaign provider’s supported configuration for the organisation’s approved identity. Before any real release, the administrator would need to verify the actual DNS, signatures and receiver results. The fictional fixtures cannot do that. For suppression, the proposed change prevents a routine import from overriding an existing withdrawal and checks the final audience selection.

The worksheet includes the hypothetical count example of three complaints and 900 inbox-delivered messages. The resulting 0.333% is arithmetic, not a measurement or a forecast. It teaches why the denominator matters and why a comparison with 1,200 attempts would answer a different question. No improvement in complaints, placement or sales is claimed.

The case ends with a reviewed plan and a list of tests still needed. A realistic audit can be useful before it declares a fix complete. Its value is that the next operator knows what to inspect, which route to protect and what evidence would justify reopening the campaign.

12. Use the companion files and understand what their tests prove

The companion kit includes blank and fictional CSV registers, blank and example JSON, a field dictionary, test fixtures and a reusable validator. Begin with the blank files for your own audit. Keep the example files unchanged as training references so that hypothetical observations are not mistaken for your organisation’s evidence.

Download the email-deliverability audit kit (ZIP)

1. In the evidence register, add one row for each stream, check and destination context. Set status to not_checked until you have reviewed the evidence.
2. Record a concise observation, the restricted evidence reference, date, owner and next action. Keep personal information and live unsubscribe tokens out of the register.
3. In the remediation register, connect each proposed change to its finding. Fill in dependencies, acceptance criteria, a stop condition and a recovery plan before considering execution.
4. Use the JSON version when you need structured exchange between reviewers. The dictionary defines the same statuses and scope fields; it does not configure an email platform.
5. Run the validator against the supplied fixtures first. Review failures and limitations before adapting it to your records.

The included checks exercise CSV round-tripping, required evidence for a passing finding, rate edge cases, educational alignment decisions and the structure of a one-click test observation. Additional cases reject malformed inputs, impossible review dates, whitespace-only evidence and incomplete signature or interaction observations. Organisational domains are supplied explicitly in the fixtures. The validator does not guess them from the last two labels or implement a live DMARC discovery algorithm.

A structural header check cannot validate a DKIM signature. A recorded HTTP success cannot prove that a recipient was suppressed. A valid CSV cannot prove the evidence entered in it is true. The test results label these boundaries so that a green local check is never presented as a completed integration audit.

Close the audit with a concise handoff: what failed, the affected streams, changes approved or still proposed, tests actually completed, known limitations and the next review date. Retain the supporting evidence securely. Revisit the inventory whenever a new sending tool, domain, integration or message purpose is introduced; otherwise the next audit starts by rediscovering the same dependencies.

Need help connecting email preferences and sending workflows to your CRM? Discuss your implementation requirements with Canada Create.