Email Deliverability Audit: Find Out Why Messages Are Rejected or Sent to Spam

Start an email deliverability audit with one affected message. Find out whether your sending platform submitted it, the receiving server accepted it, and the recipient could find it. Those are separate events. A campaign dashboard that says “delivered” may establish server acceptance without telling you where the message landed.

That distinction decides your next move. A rejection needs its complete error response. An accepted message found in spam needs its received headers and sending context. A lower open rate, by itself, does not establish either problem.

If unwanted marketing is still going out, pause the affected campaign or audience while you investigate. Preserve necessary customer communications wherever they can continue safely. Stopping every receipt, appointment update and customer reply can create a second problem before you understand the first.

Choose the branch that matches the symptom

Choose one row first. If several apply, keep their evidence separate. A platform can have an authentication problem on one sending service and an audience problem on another.

You can use the email deliverability audit kit to keep the investigation together. It contains a checklist, blank records and fictional worked examples. It does not send messages or run a live inbox-placement test.

Read one message before changing your whole setup

Consider Alder Workshop, a fictional furniture business. Its marketing coordinator, Maya, sends a monthly care newsletter through a campaign platform. Order confirmations leave through a different service. A subscriber says the newsletter arrived in spam. Another customer says they received a newsletter after unsubscribing.

These are two specific reports. Maya saves the affected messages and pauses the newsletter. She checks that order confirmations are still leaving their own service and asks the mail administrator to examine the newsletter’s authentication. She also asks the CRM owner to trace the unsubscribe.

The following is a synthetic diagnostic header excerpt, using reserved example domains. It is deliberately limited to the fields needed for this explanation. It is not a complete email, a valid cryptographic test message or evidence from a client system.

From: Alder Workshop <news@alder.example>
To: Reader <reader@recipient.example>
Date: Thu, 08 Oct 2026 10:00:00 -0400
Message-ID: <newsletter-oct-2026@alder.example>
Return-Path: <campaign-482@bounce.vendor.example>
Authentication-Results: mx.recipient.example;
    spf=pass smtp.mailfrom=bounce.vendor.example;
    dkim=fail header.d=alder.example;
    dmarc=fail header.from=alder.example

Read the excerpt in this order:

1. From identifies the address shown to the reader. Here, the business presents itself as news@alder.example.
2. Return-Path shows a different address associated with the delivery’s envelope sender. Its domain is bounce.vendor.example. A campaign service can legitimately handle returned mail for a customer; different addresses alone do not prove abuse.
3. The SPF result passes for the vendor’s envelope domain. It does not say that the visible alder.example identity passed SPF.
4. The DKIM result fails for the signature associated with alder.example. The reported signature failed verification, but this excerpt does not identify why. Inspect the full result before blaming a message change or signing error. Key-lookup problems may instead appear as temperror or permerror.
5. The DMARC result fails for the visible From domain. In this example there is no passing, aligned authentication path: the passing SPF identity belongs to the unrelated vendor domain, and the aligned DKIM identity failed.

The practical question for the administrator is now precise: why did the newsletter’s intended DKIM signature fail, and how is the campaign service configured to authenticate Alder’s domain? “Our SPF passed” does not answer that question.

The interpretation also depends on who added the authentication results. Real messages can contain several such headers. Have the receiving system’s administrator identify the trusted results rather than accepting any line that says “pass.” The Authentication-Results standard explains this trust boundary.

Now compare a controlled order-confirmation sample. Suppose it has a passing DKIM signature aligned with Alder’s visible From domain and a passing DMARC result. That supports a narrower finding: this sample’s authentication path worked. It does not certify every receipt or prove inbox placement. It does help the team avoid replacing the working receipt service while investigating the newsletter.

The unsubscribe report needs a different trace. In Alder’s example, the campaign platform recorded the opt-out correctly, but a later CRM import restored marketing eligibility. Repairing DKIM would leave that customer receiving unwanted messages. The CRM owner must correct the import behaviour and make sure the opt-out survives the next synchronization.

By the end of this first examination, the team has two repair tasks with different owners. It has not assumed that a single deliverability score explains everything.

The marketer’s path: collect evidence you can use

You do not need to understand every mail header to begin. Your job is to identify the affected communication, establish what happened, and preserve enough context for someone else to reproduce the diagnosis.

Start with the customer’s account of the problem

Ask which message they expected, the address it was sent to, and whether they found it in another folder. Keep the request short. A customer trying to locate a receipt should not have to perform a technical audit before receiving help.

Where appropriate, provide the needed information through an existing, approved customer-support route while the email issue is investigated. Avoid sending repeated copies of the same message to see whether one gets through. That makes the customer’s experience worse and complicates the evidence.

Record the difference between “never received,” “found in spam” and “arrived late.” If the customer found it, ask whether they can share the original message with your authorized support team. A screenshot is useful for showing the folder or warning, but it usually omits the routing and authentication information an administrator needs.

Do not ask customers to post headers publicly. Messages can expose addresses, identifiers, routing details and unsubscribe tokens. Share only the necessary material with the people handling the investigation, using an approved channel.

Find the same message in the sending platform

Search by recipient, approximate send time and campaign or transaction. Preserve the message identifier when available. Then record the event sequence in the platform’s own terms: queued, submitted, deferred, accepted, bounced, suppressed or another status.

Look at the event detail rather than relying on the campaign total. A message can be accepted after earlier temporary failures. A queued message may never have reached the receiving server. A suppression may reflect an earlier opt-out or bounce rather than a new delivery failure.

Save the full SMTP response for a rejection or deferral, including the server’s explanation and any linked help page. A screenshot that shows only “failed” forces the administrator to collect the useful evidence again.

Record the time zone alongside timestamps. “It failed at 10” is hard to compare with a provider log in UTC or a CRM export in another zone. For an incident involving several systems, preserve their original timestamps and have the administrator normalize them for the timeline.

Get the original received message

For Gmail on a computer, Google’s documented route is to open the message, use More beside Reply, and select Show original. That view exposes the full header. Interface wording can change, so use Google’s current header instructions if your screen differs.

Use the affected received message, rather than forwarding its body to yourself and examining the new message’s headers. A fresh forward creates another delivery path. If you need to transfer the original, ask your administrator which original-message or attachment format their tools can inspect.

Keep an unedited original securely. Make a separate redacted copy for wider discussion, because removing or changing content can prevent some forms of technical verification. Never treat a redacted screenshot as a replacement for the original evidence.

If no message was accepted, there may be no received header to obtain. Use the sending logs and rejection instead. Asking a recipient to find headers for a message their server refused wastes time.

Compare like with like

Build a small comparison around the reported problem:

• The affected newsletter and an earlier newsletter from the same service.
• An affected recipient provider and another provider from the same campaign.
• The newsletter stream and the separate receipt stream.
• Messages before and after a recent sending-domain, template or integration change.

Each comparison answers a different question. A Gmail newsletter and an Outlook receipt differ in both destination and sending stream, so that pair alone cannot isolate either factor.

Look for the smallest explanation consistent with the evidence. If failures began after one platform’s domain configuration changed, examine that change. If authentication stayed consistent but complaints followed the import of an old event list, investigate the audience. Several factors can coexist, but they should earn their place in the diagnosis.

Check what changed before the incident

Ask the people who maintain campaigns, DNS, integrations and templates. Useful changes include a new sending service, a moved domain, a different From address, a large import, a reactivated automation or a jump in sending volume.

Also ask about changes the marketing team may not see: a mail gateway adding a footer, a security product rewriting content, a decommissioned DKIM selector, or a website form sending through a different host.

A change is a lead, not proof of causation. Write down when it occurred and which messages passed through it. Then look for evidence connecting it to the affected stream. This prevents a coincidental website redesign from becoming the explanation for every subsequent email complaint.

Check the audience before blaming the technology

A technically authenticated email can still be unwanted. Review the relationship that made each audience eligible to receive the message. A list built only from people who opted in also meets CASL, and it is the starting point for email marketing that reaches the inbox.

For Alder, current newsletter subscribers and customers receiving an order confirmation have different expectations. A customer purchasing a table has an immediate reason to receive its receipt. That purchase does not tell the marketing coordinator, by itself, which unrelated promotions the customer agreed to receive.

Trace a sample of addresses back to their entry point. Was the address supplied on a newsletter form, added during a sales conversation, imported from an event, or copied from another system? What was the person told? Which permission record supports the current use? If the answer is unknown, hold the affected marketing audience for review.

For Canadian commercial electronic messages, the applicable CASL basis, sender identification and unsubscribe requirements need attention. Consent rules include distinctions and exceptions; a CRM checkbox alone does not resolve them. Use the government’s consent guidance and obtain advice for your circumstances. This guide provides operational checks, not a legal opinion.

An address-verification service can help investigate address validity, but validity does not establish permission or interest. Buying another verification result cannot repair an unexplained list source. Likewise, a contact who has stopped engaging is not automatically an invalid mailbox.

Review how often people receive messages across your business. The newsletter may run monthly, while three automations and a sales sequence contact the same person between issues. Looking at one campaign in isolation can hide the actual frequency experienced by the recipient.

Use recent replies, complaints, unsubscribes and the relevance of the current relationship to guide review. Treat opens cautiously. Apple’s Mail Privacy Protection can download remote content in the background regardless of engagement, so an apparent open is not a dependable signal that a person read the message. See Apple’s explanation.

Do not solve audience uncertainty with a mass “please confirm you’re still interested” send unless the basis for that message has been reviewed too. It is still a message to the same people. Sometimes the appropriate action is to stop including a poorly documented segment and improve how future subscribers enter.

If the problem is that the follow-up has little value, work on the message itself. The lead nurturing guide covers useful content and conversation-based follow-up. A deliverability audit cannot make an irrelevant campaign welcome.

The administrator’s path: check sending identities

The technical investigation should follow the affected message through the service that sent it. A valid record on the company’s main domain does not establish that every connected application uses that record correctly.

Begin with an inventory of active streams: staff mail, newsletters, sales automation, receipts, booking notices, website forms and support messages. For each, identify the sending service, visible From domain, envelope domain, DKIM signing domain and person responsible for configuration.

Keep this inventory practical. Its purpose is to stop an administrator from fixing the newsletter and accidentally breaking invoices. You need enough detail to identify dependencies and collect representative evidence, rather than a catalogue of every historical application the company once used.

SPF: authorization for the relevant envelope identity

SPF evaluates whether the connecting sender is authorized for the identity being checked, commonly the SMTP MAIL FROM domain. That can differ from the visible From address. Check the identity and actual sending path before deciding which domain’s DNS needs attention.

Follow the sending vendor’s current setup instructions, and examine existing records before adding anything. Publishing another independent SPF policy alongside the existing one is not a safe way to add a service. Evaluate the combined authorization and dependencies.

SPF has a limit of ten DNS-query-causing terms during evaluation, including applicable nested dependencies. It is not simply a limit of ten visible vendors in one line. An administrator should evaluate the record rather than counting words in a screenshot. The protocol and lookup rules are defined in RFC 7208.

For Alder, the observed SPF pass belongs to the campaign vendor’s envelope domain. Copying a vendor include into Alder’s main domain would not, by itself, change which envelope identity that message used. The configuration question comes first.

DKIM: check the signature that arrived

DKIM associates a cryptographic signature with a signing domain. Inspect the domain identified by d= and the selector identified by s=, then have the administrator verify the received message against the relevant key and configuration. The presence of a DKIM-Signature header is not proof that verification passed. See RFC 6376.

A useful investigation follows the failure. Did the service sign with the intended domain? Is the correct public key available? Was the message modified after signing? Do failures affect every selector or only one path? Avoid rotating keys merely because a dashboard shows a red icon; first determine what that icon represents.

Where a message has multiple signatures, preserve their individual domains and results. One failed signature does not necessarily describe every available authentication path. Reducing the message to a single “DKIM present” field throws away information that could explain its treatment.

DMARC: connect authentication to the visible From domain

DMARC requires a passing authentication path whose domain aligns with the visible From domain. A passing, aligned SPF or DKIM path can satisfy DMARC; an unrelated vendor-domain pass cannot do that alone. Strict alignment requires an exact domain match, while relaxed alignment uses the relevant organizational-domain relationship.

Policy selection needs care. The current base specification, RFC 9989, supersedes RFC 7489 and specifically advises against p=reject for general-purpose email domains. Read that guidance with the administrator before applying a blanket enforcement recommendation from an older checklist.

In practice, identify legitimate senders, examine their results and assess indirect mail flows before changing policy. A stricter published policy does not repair a service that signs incorrectly. It can expose that failure by causing legitimate messages to receive different treatment.

For Alder, the immediate repair is the broken newsletter authentication path. The business also needs to establish which other services send using the same domain before considering a wider policy change. That is why a one-line instruction to “set DMARC to reject” is too crude for this investigation.

Forwarding and receiving gateways need their own evidence

If direct delivery works but a forwarded copy fails, preserve both paths. Ask where the message was relayed or modified and which system recorded each result. A mailing list, alias, gateway or forwarding service can make the journey different from the sender’s simple platform-to-inbox diagram.

Do not delete authentication settings to accommodate one unexplained forwarded message. Escalate the actual route, original headers and comparison to the mail administrator. They can evaluate the relevant authentication and local receiving decisions without weakening protections for unrelated traffic.

Also distinguish a personal mailbox service from a company’s managed environment. A business can apply its own gateway, quarantine rules and policies. The sender may need that organization’s mail administrator to explain a local rejection even when the public provider requirements are satisfied.

Use the requirements of the provider you reach

The following summaries are starting points for the relevant official pages, not a substitute for them. Requirements change, so confirm the current wording on each provider’s page.

Personal Gmail accounts. Google’s general sender rules include SPF or DKIM, valid forward and reverse DNS, TLS and low complaint rates. Bulk senders need SPF and DKIM, DMARC with at least p=none, and the required alignment. For those bulk senders, marketing and subscribed messages also need the applicable one-click unsubscribe mechanism and a visible body link. Read the Gmail sender guidelines.

Google’s sender FAQ describes bulk status as close to 5,000 messages or more to personal Gmail accounts in 24 hours. It aggregates the same primary domain, including subdomains, and says the classification is permanent once reached. Splitting campaigns across subdomains does not reset that definition.

Yahoo. Its bulk requirements include SPF and DKIM, a valid DMARC policy of at least p=none, passing DMARC, and easy unsubscribe for marketing and subscribed messages. Yahoo strongly recommends the RFC 8058 POST method while accepting a mailto method. It also requires a visible body unsubscribe link and handling within two days. Consult Yahoo’s sender requirements; do not assume every detail matches Google’s.

Microsoft consumer mail. Microsoft’s high-volume rules cover Outlook.com and related consumer services such as Hotmail, Live.com and MSN. Its current support guidance requires SPF and DKIM to pass, a DMARC record, and DMARC validation through an aligned path. It connects error 550 5.7.515 to this authentication requirement. See Microsoft’s diagnostic guidance. Do not apply that consumer-service explanation automatically to every Microsoft 365 tenant.

Meeting these requirements is necessary where applicable, but it does not give a sender control over every recipient’s inbox. Continue investigating the original symptom after authentication passes.

Interpret a rejection in context

Suppose Alder’s sending log instead contains this illustrative response for a Microsoft consumer destination:

550 5.7.515 Access denied, sending domain alder.example
 does not meet the required authentication level.

This synthetic response points the team toward the sender-authentication requirements described in Microsoft’s support article. It does not say that the recipient unsubscribed or that the address is misspelled. The administrator should preserve the actual complete response, then compare the sending stream’s authentication against that provider’s requirements.

More generally, SMTP distinguishes temporary negative replies beginning with 4 from permanent negative replies beginning with 5. The remaining response text supplies important context. Use the sending service’s documented handling and the SMTP specification, rather than manually resending every deferred message or repeatedly retrying a permanent rejection unchanged.

A permanent rejection of a particular message is also not a universal verdict that the recipient address can never receive email. Authentication and policy failures need a different remedy from an invalid mailbox. Keep the full reason when deciding whether to suppress an address, repair a sender or escalate to the provider.

When authentication passes but mail still hits spam

Passing authentication narrows the investigation. You still need to examine what was sent, to whom, from which service, and how the receiving system treated that particular delivery.

First, verify the reported location. In Gmail’s default inbox, Promotions is an inbox category, separate from Spam. A newsletter appearing in Promotions is therefore a different observation from a newsletter placed in Spam. Google’s inbox category explanation describes how those tabs work. Do not classify a category placement as a failed delivery simply because the sender hoped to appear in Primary.

Ask whether the report concerns a single recipient or a pattern. One person may have a filter, previous interaction history or a company gateway that other recipients do not share. The marketer can collect examples without claiming to know why the provider made each decision. If a business recipient reports a quarantine warning, involve their mail administrator rather than assuming the campaign platform controls it.

Next, compare the actual received content with the approved message. Look at the recognizable sender name, the reason for contacting this audience, working links, destination domains and unsubscribe experience. A campaign that promises a care guide but opens with unrelated promotions may create confusion even if every technical check passes. Correct genuine problems for the reader; avoid rewriting words at random to chase a speculative spam-filter formula.

Review destination links with the website owner if something unexpected appears. A legitimate-looking email can point through an outdated redirect, an unfamiliar tracking domain or a compromised page. Do not click a suspicious destination casually or ask subscribers to bypass a browser warning. Have the relevant administrator investigate it using their security process.

Then consider the sending pattern. Was this a routine newsletter to current subscribers, or a much larger send to contacts who had not heard from the business for years? Did a previously small program suddenly add several automated sequences? The answer helps identify which audience or workflow deserves examination. It does not justify inventing a universal daily volume that every business should use.

Alder’s coordinator might find that the remaining spam reports come from an older imported segment while newer subscribers report normal receipt. That pattern would support inspecting the segment’s origin and recent contact history. It would not establish that every address in the older segment is bad, or that removing a fixed percentage will restore placement.

If you use test mailboxes, keep their role clear. They can confirm what happened to particular samples at particular times. They cannot represent every customer’s history, rules or receiving environment. A favourable test result is one piece of evidence alongside the actual customer reports and provider data.

Choose the next test to distinguish plausible explanations. For example, compare a controlled message through the same service before and after correcting an identified template defect, while holding other practical conditions steady. Record the change and observed result. Avoid simultaneously changing the domain, sender name, template, audience and platform; any improvement would be difficult to interpret.

Escalate persistent patterns with those comparisons attached. A qualified mail administrator or deliverability specialist can assess infrastructure, provider feedback and sending practices beyond the evidence available to a marketing dashboard. Changing to a fresh domain simply to escape the investigation leaves the underlying audience or workflow defect in place. A migration should have a legitimate operational reason and its own validation plan.

Follow an unsubscribe all the way through

A visible unsubscribe link and a working suppression process are different things. Both deserve inspection.

Start with a controlled address your team owns and is authorized to use for testing. Receive a real sample through the affected marketing stream. Check the body link and, where required, the message’s one-click mechanism. Do not test with a customer’s personal unsubscribe token or send extra marketing to someone who already opted out.

For RFC 8058 one-click handling, the message uses List-Unsubscribe and List-Unsubscribe-Post headers. The required HTTPS POST must work without cookies, HTTP authorization or another confirmation step, and must not redirect. A valid DKIM signature must cover both headers. The one-click standard defines those requirements; a body preference link alone does not implement them.

Have the administrator test the endpoint safely. Merely opening a URL in a browser does not demonstrate the required POST behaviour. A normal GET fetch should not itself opt someone out, since automated systems may fetch links. Confirm the actual suppression result after the intended unsubscribe action, including repeated requests.

Then trace the controlled address across the systems that can send to it. Is the change visible in the campaign platform? Does the CRM still show marketing eligibility? Does the next scheduled import preserve the opt-out? Can another automation enrol the contact because it uses an old field?

Alder’s defect sits at this final step. The unsubscribe works initially, but an import reverses its effect. The repair must address the import’s update rules and the precedence of the newer opt-out. Testing only the landing page would miss it.

Keep marketing preferences distinct from the business need to communicate about an existing transaction, and have the applicable legal treatment reviewed. Do not silently convert an opted-out contact into a different promotional list. If the person made a broader request about contact, route that request to someone who can interpret and honour it.

For Canadian commercial messages, the CRTC says unsubscribe requests must be acted on without delay, and no later than ten business days. Provider requirements may be faster, as Yahoo’s two-day requirement illustrates. Use the applicable shorter operational deadline; the legal maximum is not a recommended waiting period. See the CRTC’s CASL questions and answers.

Measure the problem with the right denominator

Before comparing any deliverability percentage, write down what is being counted and what it is divided by. “Delivery rate” may mean accepted messages divided by attempts. It cannot automatically stand in for the percentage that reached an inbox.

Complaint rates need the same care. Yahoo says its spam rate uses mail delivered to the inbox. In a hypothetical cohort with three complaints, 900 inbox-delivered messages and 1,200 attempted messages:

• Three divided by 900, multiplied by 100, is approximately 0.333%.
• Three divided by 1,200, multiplied by 100, is 0.25%.

Both calculations are arithmetically correct. They answer different questions. Comparing the second figure with Yahoo’s below-0.3% requirement would use the wrong denominator. The Yahoo requirements identify both the threshold and its inbox-delivered basis.

In a real investigation you may not know the inbox-delivered total. Do not manufacture it from an acceptance count. Use the provider’s reported metric where available and label gaps explicitly. A dashboard that withholds data for a small cohort has not reported zero complaints.

Break results down by recipient provider and sending stream where the data supports it. A large volume of healthy receipts can conceal a newsletter problem inside an overall average. Likewise, a campaign dominated by one provider may tell you little about a smaller destination group.

Compare time periods with their audience and volume changes in view. A lower complaint rate after stopping most sends may be a useful containment outcome, but it does not prove the remaining configuration is repaired. A successful test to a few staff mailboxes provides evidence about those tests, not the placement of the entire customer campaign.

For reporting, keep a short distinction between observed facts and explanations under investigation. “Twenty messages were rejected with this response” is an observation. “The new signing configuration caused the rejection” is a hypothesis until the configuration and message evidence support it. That separation makes the next technical conversation much more productive.

Repair the narrow problem, then verify the symptom

Choose the repair that follows from the evidence. An authentication failure goes to the administrator responsible for the sending service and DNS. A resubscription defect goes to the integration or CRM owner. An unexplained audience goes to the person accountable for acquisition and permission records.

Before changing anything, identify the affected streams and the way back if the change disrupts legitimate mail. A DNS or service change should have a documented previous configuration, an authorized owner and a verification plan. A rollback must not restore an obsolete marketing permission state or erase newer opt-outs.

For Alder, the newsletter repair has two tracks. The mail administrator corrects the signing configuration and checks a fresh received sample. The CRM owner prevents the import from reversing opt-outs and follows a controlled unsubscribe through the next synchronization. Neither task can stand in for the other.

Resume sending only after the relevant checks support it. Choose an appropriate, permissioned audience and a send plan consistent with the platform’s guidance and the business’s normal activity. There is no universal recovery schedule or fixed number of days after which a domain becomes healthy again.

Watch the same signals that exposed the incident: the relevant rejection responses, authentication results, suppression behaviour and recipient reports. Changing a subject line and seeing more opens would not establish that the original authentication defect was fixed.

Keep essential streams under observation too. A repair affecting a shared domain may touch more than the paused campaign. Verify representative receipts, support replies or other legitimate messages using that configuration, without unnecessarily contacting customers for tests.

If the cause remains uncertain, escalate with a concise evidence package: the affected service and message type, destination provider, exact times, complete responses, securely shared original messages, recent changes and the tests already performed. State the customer impact plainly. “Order confirmations to this destination are being rejected” helps support prioritize more effectively than “our deliverability is bad.”

Close the audit with a useful decision: which sending can continue, which audience remains paused, what was corrected, and what still needs specialist investigation. The downloadable kit can hold that decision and its supporting records. Its local validator checks supplied audit data and examples; it does not query live DNS, verify DKIM cryptography, exercise unsubscribe endpoints or measure inbox placement.

The goal is a smaller, answerable problem and a safer customer experience. When the next message fails, your team should know where to look, who can act, and what evidence would show that the repair worked.

Frequently asked questions

How do I check email deliverability when one message seems to have gone missing?

Work from that single affected message and establish three separate events: whether your platform submitted it, whether the receiving server accepted it and whether the recipient could find it. A dashboard marked delivered may only confirm server acceptance. A rejection calls for the complete error response, while a message found in spam calls for its received headers. Treat each finding separately before changing your setup.

How do I fix email deliverability without stopping receipts and appointment emails?

Pause only the affected campaign or audience while you investigate, and keep necessary customer messages flowing where they can continue safely. Halting every receipt and appointment update can create a second problem before the first is understood. Repair the narrow fault the evidence points to, with the right owner for each task. Then check that the original symptom has actually gone.

What makes a marketing email fail to go through to the recipient's server?

A receiving server can reject a message, defer it for a later retry or never receive it because it stayed queued. A suppression in your platform may also reflect an earlier opt-out or bounce rather than a new failure. For any rejection or deferral, save the full SMTP response, the destination, the time with its time zone and the sending service. A screenshot that only says failed forces someone to collect the evidence again.

Does a falling open rate prove there is an email deliverability problem?

No, a lower open rate on its own establishes neither a rejection nor spam placement. Check first whether the way opens are measured has changed. Then look at real replies, clicks and customer reports. Only evidence about where specific messages went can show a deliverability failure.

What is the difference between email delivery and deliverability?

Delivery usually means the receiving server accepted the message. Deliverability also covers where it landed, such as the inbox, the spam folder or a rule the recipient set up. A platform can truthfully report a message as delivered while the customer finds it in spam. That is why an audit treats acceptance and placement as separate observations.

Why can SPF pass while DMARC still fails on a newsletter?

SPF may pass for the campaign vendor's bounce domain, which says nothing about the business domain shown in the From line. DMARC needs at least one method that both passes and aligns with that visible From domain. If the business's own DKIM signature fails, there is no aligned passing path and DMARC fails. The useful question for the administrator is why that signature failed and how the service is set up to sign for your domain.

How should a customer share a message that landed in spam for an email deliverability assessment?

Ask for the original received message through an approved support channel, since a screenshot leaves out the routing and authentication details. In Gmail on a computer, the More menu beside Reply offers Show original, which exposes the full header. Forwarding the message creates a new delivery path and spoils the evidence. Customers should never post headers publicly, because they can expose addresses and unsubscribe tokens.

Why does someone keep getting marketing emails after unsubscribing?

The opt-out may be recorded correctly in the campaign platform and then undone by a later CRM import that restores marketing eligibility. Fixing authentication will not stop those messages. The CRM owner has to correct the import and confirm the opt-out survives the next sync. CASL, Canada's anti-spam law, sets rules on permission, on naming the business behind a commercial message and on honouring opt-outs, so review the current rules if you are unsure.

What should an email deliverability audit checklist record for each incident?

Record the message identifier, the recipient, the send time with its time zone and the event sequence in the platform's own terms. Add the full server response for any rejection or deferral. Note any recent changes to campaigns, DNS, integrations or sending domains before the problem began. Comparisons should hold one factor steady, such as the same service sending to two different providers.