Content and social
Newsletter going to spam? Find where the message stops first.
Low opens do not by themselves prove a spam problem. Mail may have been rejected, delayed or placed in another tab. Gather evidence from the sending service and controlled inboxes before rewriting the subject.
Name the symptom before changing the campaign
Start by establishing what going to spam means in this case. A message may remain in the sending queue, be rejected by a receiving server, reach a mailbox or appear in another category. These are different situations requiring different actions. Ask for the date, campaign identifier, recipient domain and exact response. A fall in opens alone does not identify the cause. Apple describes Mail Privacy Protection as limiting a sender’s knowledge of message opening. Open tracking therefore cannot be treated as a direct count of people who read the copy.
Record whether the issue affects everyone, one provider, a new template or a new sender address. Compare similar sends and account for changes in the list. In a hypothetical example, one campaign mostly reaches company mailboxes and another personal accounts. Different reports may reflect different filtering and behaviour rather than the subject line. Create a brief incident record before replacing the sending domain. It should make the symptom reproducible and let you later check whether a particular change affected the same problem. Keep observations separate from explanations that have not yet been tested.
Collect message headers and server responses
Inspect queues, rejections, delays and the receiving provider’s response in the sending service. Preserve the original code and description. A bounce label may combine several causes, so its total alone is insufficient for diagnosis. Separate recipient domains and dates. If detailed logs are available, establish which event means acceptance by the remote server. Acceptance still does not establish placement in the main category or reading by a person. A report should describe the stage it actually records rather than assume that all later stages completed successfully.
Receive a test in a controlled mailbox and retain its original headers. Useful information includes sender identity, the route and authentication results recorded by the receiving system. Do not treat an arbitrary copied header as a trusted report; the provider should identify the appropriate field in its environment. Include identifier, time and scope in a support request. Remove recipient details support does not need. Test with designated addresses. Another large campaign is a poor way to test a repair whose behaviour is not yet understood. A small reproducible case makes discussion with the provider more focused.
Inventory every system that sends for the domain
A domain can serve ordinary email, newsletters, a store, forms and a CRM. Each system may have different settings. Record the service, visible sender address, technical domain, responsible person and verification method. Without this inventory, a newsletter repair may disrupt other legitimate messages. Look particularly at older integrations and tools the company believes it no longer uses. A mention in documentation does not show whether the service still sends or whether its configuration remains current. Ask the owner to confirm actual use before treating an entry as redundant.
Request the provider’s instructions for the specific account and domain. Do not paste a DNS record from an unrelated guide; its names and keys are not your configuration. Agree who approves the change and how its effect will be tested. With shared infrastructure, the sending IP and reverse DNS may be controlled by the provider. Ask about them rather than trying to repair them in the website panel. Preserve the previous configuration and a recovery plan if the change interrupts legitimate company mail. The objective is a correction you can explain and verify, not simply a different-looking set of records.
Verify SPF, DKIM and DMARC on a received message
SPF, described in RFC 7208, identifies systems authorised to send for the domain used during mail transmission. DKIM, documented in RFC 6376, signs a message and supports signature verification using a domain key. DMARC, now specified in RFC 9989, connects authentication with alignment to the domain in the visible From header. These are related mechanisms, not interchangeable badges in a dashboard. Record presence is insufficient. Receive a test and inspect the actual results and the domains to which they apply, following the receiving provider’s interpretation of the message.
In a hypothetical example, SPF and DKIM both pass, but authenticate provider domains unrelated to the visible brand sender. Those two pass labels alone do not establish successful DMARC. Ask the provider to check the required alignment for the configuration. Then test the store and newsletter separately. Do not adopt a restrictive policy solely because it appears more professional. Identify legitimate senders and the likely effects first. DMARC reports can support that assessment but need interpretation; they do not identify newsletter readers or prove main-inbox placement. Keep authentication evidence separate from the evidence about where messages appeared.
Check the scope of each provider’s requirements
Gmail’s FAQ defines a bulk sender as sending close to 5,000 or more messages to personal Gmail accounts within 24 hours. It counts the primary domain and its subdomains together, and meeting the condition once makes the classification permanent. This is not a threshold for the total mailing list regardless of provider. Gmail separates general and bulk requirements; the latter include SPF, DKIM and DMARC, plus appropriate unsubscribe support for marketing and subscribed mail. Establish which category applies before treating a checklist as complete.
Yahoo publishes its own requirements and definitions. Do not transfer Gmail numbers or deadlines automatically to another mailbox service. Check the operator’s guidance and your sending provider’s documentation on the diagnosis date. Sources for this article were read on 8 October 2026. Record which recipient addresses the findings concern. Personal-account rules do not necessarily describe a company mailbox provided through a different product. If an error identifies a specific condition, start there. Meeting requirements provides a basis for sending; it cannot promise the same mailbox category for every recipient under all circumstances.
Test unsubscribe from request to lasting suppression
A body link and a one-click header mechanism perform different jobs. RFC 8058 describes an HTTPS POST signalled by List-Unsubscribe and List-Unsubscribe-Post headers covered by a valid DKIM signature. Writing a similar phrase in the footer does not implement that mechanism. Use the provider’s supported feature and inspect a received message. Separately follow the visible body link using a test address. A recipient should be able to leave without hunting for a hidden form or having to speak to customer service to stop a newsletter.
After leaving, inspect the contact status and the next scheduled send. A confirmation screen does not demonstrate exclusion from campaigns and related automations. Yahoo requires unsubscribe requests to be honoured within two days; check the applicable rules for other providers as well. In a hypothetical case, an address leaves one segment but a nightly CRM import adds it again. The repair must preserve the unsubscribe status through the data flow. Identify its authoritative source and how imports respect it. Test the import as part of the solution rather than only the page displayed immediately after clicking.
Examine list origin and recipient expectations
Check where addresses came from, what the subscription promised and whether current content matches it. Someone interested in a guide may not expect frequent offers about unrelated products. A purchased or old database does not become current interest through correct DNS. Distinguish active subscribers, unsubscribed contacts, complaints and rejected addresses. Define lasting exclusion where appropriate. The objective is not the largest record count; it is communication that recipients actually expect in the agreed context. Ask what evidence supports that expectation before treating every stored address as an eligible newsletter recipient.
Sender name, subject and opening sentence should accurately explain the message. Do not imitate a reply to a private conversation that never happened. Check links, domains and readability without images. In a hypothetical example, people registered for a completed event and the business suddenly starts sending daily shop offers. Assess expectations and the basis for continued communication before adjusting frequency. Authentication will not resolve this mismatch. Evaluate contact rules under the relevant law and the information provided at subscription. The technical investigation should identify this separate question rather than imply that a green configuration check answers it.
Resume sending through a controlled review
After a repair, choose a limited, justified audience and inspect results before expanding. Agree volume and pace with the provider using the history and identified cause. There is no single domain warm-up schedule suitable for every company. Monitor rejection, delay, authentication and complaints separately for important receiving providers. Record a stop condition and decision owner. If the error returns, compare the same route with the earlier successful test. Changing many variables at once makes it harder to identify what helped and can obscure a remaining problem in another sending system.
Avoid repeatedly changing sender addresses or domains as a substitute for addressing reputation. Recognisable identity and an orderly change history support diagnosis. Separate transactional and marketing streams in the operating plan, remembering that a transactional label does not transform advertising content. In a hypothetical case, a repaired newsletter works while store confirmations still use old settings. Acceptance needs to include both systems. Tell the people handling customer enquiries what was tested and what remains outside scope. A single successful message should not become a claim that every company email route has been repaired.
Keep evidence that supports the next diagnosis
A useful outcome records the symptom, confirmed cause or remaining hypotheses, changes and repeat-test evidence. Add limits: providers, tools and message types not inspected. Keep configuration history, system owners and the unsubscribe test method. Another person should be able to resume the investigation without guessing. A green DNS result does not describe the list, copy or recipient behaviour. Similarly, higher opens without understanding measurement conditions do not establish complete recovery. State what the evidence supports, especially when the investigation fixes authentication but does not yet explain every placement observation.
For a discussion with DigiDraft, prepare the sending provider, domain, message type, affected scope and anonymised errors. Do not include passwords or the entire subscriber database in an initial enquiry. These details help determine whether work concerns configuration, subscription flow, template or integration between systems. After implementation, revisit the same indicators and unsubscribe test when changing providers. Deliverability depends on maintaining several connected parts. No setting guarantees the primary inbox for everyone forever. The practical result is a clearer cause, a tested correction and a way to notice when the problem returns.
Questions and answers
Does a low open rate mean the newsletter went to spam?
No; open rate alone does not show where a message was delivered. Check rejections and delays in the sending system, then inspect delivery to controlled test inboxes. Those checks help distinguish delivery problems from measurement limits or audience response.
Are SPF, DKIM and DMARC records enough to verify a sender?
You also need to inspect an actual received message. Authentication results and domain alignment may differ between your newsletter, shop and CRM. Records in DNS do not prove that every sending system is configured correctly.
How can I test whether unsubscribing really works?
Use a test address, complete the unsubscribe process and check its status in the sending system. Then make sure a CRM import does not add it back or include it in another campaign covered by the opt-out. Test the link in the message and header-based one-click unsubscribe separately.