A legitimate business message can be authenticated correctly and still land in spam. Deliverability is a trust decision made by the receiving system for every message. The receiver evaluates who appears to be sending, whether that identity can be verified, how the sending infrastructure has behaved, whether recipients appear to want the mail and whether the message resembles abusive traffic. A serious investigation therefore cannot stop at “SPF passed” or “DMARC exists.”
Key takeaways
- SPF, DKIM and DMARC establish identity and alignment, but they do not create a good reputation by themselves.
- Gmail requires SPF or DKIM for all senders to personal Gmail accounts and stronger authentication for higher-volume senders.
- A useful diagnosis starts with message headers and SMTP evidence, then works backwards through DNS, identity, sending behaviour and list quality.
- Sudden volume changes, high complaint rates, poor targeting and inconsistent sending infrastructure can damage delivery even when DNS records are valid.
Start with authentication and alignment
SPF identifies servers permitted to send on behalf of a domain. DKIM adds a cryptographic signature that allows a receiver to verify that the message was signed by an authorised domain and was not materially altered in transit. DMARC adds policy and reporting and tests whether the authenticated identity aligns with the domain the recipient sees in the From address.
Those mechanisms answer an identity question. They do not guarantee inbox placement. A domain can have syntactically valid records while still using an incomplete SPF policy, an old DKIM selector, a third-party sender that is not aligned, or several systems that send under the same visible identity with inconsistent authentication.
- Inspect Authentication-Results on a real affected message.
- Confirm the visible From domain aligns with SPF or DKIM.
- Check for duplicate or obsolete SPF senders.
- Confirm DKIM is signing current production mail.
Reputation is behavioural and develops over time
Mailbox providers also evaluate the behaviour associated with a sending domain and IP address. Gmail’s sender guidance tells senders to keep spam rates reported in Postmaster Tools below 0.3 percent. Authentication cannot compensate for mail that recipients consistently reject or mark as spam.
A newly used domain, a sudden jump in volume, purchased or stale contact data, repeated bounces and a high proportion of recipients who never interact with the sender can all create negative signals. Shared infrastructure adds another variable because the reputation of a sending IP can be influenced by traffic outside one company’s direct control.
Separate transactional, operational and promotional traffic
A password reset, invoice, internal notification and marketing campaign have different recipient expectations and risk profiles. Mixing all of them through one identity can make troubleshooting difficult and can expose important operational mail to the reputation of promotional traffic.
Where volume and business importance justify it, use consistent sending identities for distinct classes of mail. Google’s sender guidance recommends that messages of the same category use a consistent From address.
Read the SMTP evidence before changing DNS
When a message is rejected, the SMTP response often identifies the failure category more accurately than a dashboard. A 5.7.26 authentication failure points in a different direction from an invalid recipient, policy rejection, rate limit or reputation-related deferral. When a message is accepted but placed in spam, the evidence shifts toward headers, reputation, content and recipient behaviour.
Repeatedly editing DNS without reading the actual rejection or authentication results can create new problems while leaving the original fault untouched. Preserve affected messages with full headers and compare a message that reached the inbox with one that did not.
Content matters, but content is not the whole system
Broken HTML, misleading display names, deceptive links, excessive tracking, URL shorteners, large image-only messages and content that does not match what the recipient expected can increase risk. There is no universal list of “spam words” that explains modern filtering.
A better content review asks whether the message is recognisable, wanted, technically well formed and easy to act on. For marketing mail, unsubscribe handling and recipient expectations also affect complaint rates and trust.
Use an evidence-led order of operations
Start with one affected message and its headers or bounce response. Confirm authentication and alignment. Verify DNS and reverse DNS where applicable. Identify every platform that sends for the domain. Check complaint and bounce behaviour. Then examine volume changes, list acquisition, engagement and message construction.
The purpose is to isolate the layer where trust is being lost. Deliverability problems become expensive when businesses change several layers at once and can no longer tell which change improved or worsened the result.
- Preserve full headers or the nondelivery report.
- Check SPF, DKIM and DMARC results and alignment.
- Inventory legitimate senders for the domain.
- Review recent volume, bounces and complaints.
- Compare inboxed and spammed examples.
- Change one evidenced fault at a time.
Why does business email go to spam even when the message is legitimate?
Because mailbox providers are not deciding whether your company is real; they are deciding whether a particular message should be trusted in a particular recipient’s mailbox. That decision uses several layers of evidence at once: whether the sending identity authenticates, whether the visible From domain aligns with that authentication, whether the sending IP and domain have a trustworthy history, whether recipients complain or disengage, whether the sending pattern looks normal, and whether the message resembles traffic that the provider has learned to treat cautiously. A legitimate invoice, proposal or sales email can therefore be filtered even though nobody intended to send spam.
This is also why a single green check in an online DNS tool is not enough. DNS records describe part of the sending configuration, but they do not show what happened to the actual message after it left the sender. The fastest route to a useful diagnosis is to collect one affected message, its full headers, the sending timestamp, the sending system, and any SMTP response. That evidence tells you whether the problem begins with identity, infrastructure, reputation, policy, content or recipient-side filtering rather than forcing you to guess.
Delivery and inbox placement are different problems
A message can be accepted by the recipient’s mail server and still be placed in spam. In SMTP terms, acceptance only tells you that the receiving system agreed to take responsibility for the message. It does not promise where the message will be surfaced to the recipient. That distinction matters because a bounce and a spam-folder placement call for different investigations. A bounce is usually accompanied by an SMTP status code or enhanced status code. Spam placement normally requires examining authentication results, reputation, user-feedback signals and the characteristics of the accepted message.
For business owners, the practical implication is simple: do not describe every email problem as “deliverability.” Ask whether the message was rejected, deferred, accepted into spam, accepted into another folder, silently quarantined by an organization, or delivered normally but not noticed. A provider who cannot distinguish those outcomes before recommending a fix is likely to waste time. DSDillon treats each outcome as a different branch of the diagnostic tree because the evidence and corrective action are different.
Forward and reverse DNS still matter at the infrastructure layer
Google’s current sender requirements say sending domains or IP addresses should have valid forward and reverse DNS records, often discussed as A/AAAA and PTR records. Reverse DNS gives a receiving system a way to associate an IP address with a hostname. A missing or obviously inconsistent PTR record can make a self-hosted or newly provisioned mail server look less trustworthy, especially when combined with other weak signals. The hostname should also resolve sensibly in the forward direction rather than existing only as an isolated reverse record.
This is particularly important when businesses move from a hosted mailbox product to custom infrastructure. The application may be able to send mail immediately, while the surrounding identity of the server remains incomplete. The result can be inconsistent treatment across providers: one recipient accepts the message, another defers it, and another places it in spam. That pattern is a reason to inspect transport identity, not a reason to keep rewriting the message subject line.
Complaint rate is a commercial signal, not just a technical metric
Google tells senders to keep spam rates reported in Postmaster Tools below 0.3 percent. That threshold should not be interpreted as a target to approach. It is better understood as a warning line showing how strongly recipient feedback can influence delivery. A technically authenticated campaign sent to people who did not expect it can still create negative reputation. Conversely, a smaller list of recipients who asked for the mail generally produces cleaner signals because the audience and message are aligned.
For a business, this turns list governance into part of infrastructure management. You need to know where an address came from, what the person agreed to receive, whether the address is still valid, how often the person is contacted, and whether suppression requests are honored. Purchased lists, old exports and aggressive reactivation campaigns are not merely marketing risks; they can damage the sending identity used by legitimate operational mail if everything is sent through the same domain and infrastructure.
Separate the reputation of the domain from the reputation of the sending path
People often ask for a single “domain reputation score,” but real filtering is more fragmented. Different mailbox providers maintain their own observations and models. A company can also send through several paths: a staff mailbox, a CRM, an invoicing platform, a support system and a campaign engine. Those systems may use different IP addresses, DKIM selectors, return-path domains and volume patterns. One path can perform well while another creates complaints or authentication failures.
That is why a serious audit inventories every system authorized to send as the organization. The purpose is not simply to expand SPF. It is to map the visible identity to the actual infrastructure and confirm that each path has an intentional role. When multiple systems are mixed together without governance, a business can spend weeks trying to “fix Gmail” while the real problem is a forgotten service still sending poorly authenticated or unwanted mail under the same brand.
Bulk and promotional mail should not endanger operational mail
A password reset, invoice, legal notice or customer support response has a different commercial purpose from a newsletter or prospecting campaign. When all of these messages share exactly the same sending path and reputation, poor engagement or complaints from promotional traffic can create collateral risk for business-critical messages. Larger senders often isolate streams with subdomains, dedicated DKIM identities or distinct infrastructure so that monitoring and policy can be applied more precisely.
Isolation does not make abusive mail acceptable, and it does not erase the relationship to the parent brand. It simply creates cleaner operational boundaries. For a smaller business, the first step may be less elaborate: identify which systems send transactional mail, which send one-to-one staff mail and which send promotional mail, then confirm that each category has appropriate authentication, consent controls and monitoring. The goal is to stop treating “email” as one undifferentiated stream.
Read the full headers before changing the DNS
The Authentication-Results header can show whether SPF, DKIM and DMARC passed for the message the recipient actually received. Received headers show the path through mail servers. DKIM-Signature identifies the signing domain and selector. Return-Path helps explain the SPF identity. These values often reveal a mismatch that a DNS-only checker cannot see. For example, a domain may have a valid DKIM record while the production message is being signed by a different selector or not being signed at all.
Headers are also useful when forwarding is involved. Traditional SPF checks can fail after forwarding because the forwarder becomes the connecting system, while a valid DKIM signature may survive if the message is not modified. DMARC can pass when either SPF or DKIM passes and aligns with the visible From domain. The exact outcome depends on the message and path, which is another reason to diagnose the affected mail rather than reasoning only from published DNS records.
Common fixes that sound plausible but often miss the cause
Changing the subject line, removing one image, shortening the signature or asking recipients to add the sender to contacts can occasionally change a result, but those actions should not be the first response to a systemic problem. If multiple unrelated recipients reject the same domain, the first questions are authentication, server identity, reputation and policy. If only one corporate recipient is affected, the problem may instead be that organization’s gateway, allow/deny rules or security policy.
Likewise, repeatedly editing SPF without understanding the existing authorized senders can break working mail. Publishing a strict DMARC policy before all legitimate sources are aligned can cause rejection of real messages. Moving to a new provider without preserving authentication and reputation can trade one problem for another. The safest repair is the smallest change supported by evidence, followed by a controlled test across representative receiving providers.
- Do not rotate domains simply to escape a reputation problem.
- Do not add every vendor you can think of to SPF without confirming it sends mail.
- Do not move directly to p=reject in DMARC until legitimate sources are understood.
- Do not interpret one successful Gmail test as proof of universal delivery.
What should you ask before paying for email deliverability work?
A buyer should ask what evidence the provider will inspect, what systems will be inventoried, how success will be measured and which changes require DNS or mail-server access. A credible deliverability engagement should be able to distinguish configuration repair from reputation recovery and from list-quality problems. It should also explain whether the provider is changing records, changing sending infrastructure, changing operational behavior or simply giving recommendations.
The deliverable should leave the business with a map of authorized senders, authentication status, observed message-level results, major reputation or policy risks, and a prioritized remediation plan. If a provider promises “100 percent inbox placement,” treat that promise cautiously because the final placement decision belongs to the receiving mailbox provider. A more credible objective is measurable improvement in authentication consistency, rejection rates, complaint signals and representative inbox placement over time.
Sources reviewed
Requirements, platform behavior and market conditions can change. Review the current source material before acting on time-sensitive requirements.
Related DSDillon resources
DSDillon can examine the technical, commercial or property-specific evidence and define the next action.
Talk to DSDillon