Identify the stage at which the message failed
Start with one message, one sending source and one intended recipient. Record the approximate time with timezone, the sending platform, visible From domain and the observed outcome. A message missing from the sending application is different from a server rejection; a delayed message is different from an accepted message placed in spam.
Ask the sender for the relevant submission or delivery record and the recipient for the observed placement or diagnostic response. Use identifiers and redacted evidence where possible. A screenshot of a spam folder establishes a placement observation at that time, but not the complete reason for the receiving system's decision.
| Observed outcome | Evidence to collect | First question |
|---|---|---|
| Not submitted | Application queue, error and sender configuration | Did this system attempt to hand off the message? |
| Rejected or bounced | Diagnostic code, receiving system and timestamp | What exact reason did the receiving system report? |
| Delayed | Queue state, retry history and temporary response | Is the failure temporary, and which hop is delaying it? |
| Accepted into spam | Redacted message headers and recipient placement | What authentication and sending-pattern evidence is available? |
| Only some recipients affected | A comparable successful and unsuccessful delivery | What differs by receiver, source or message type? |
Inventory all legitimate sending sources
Business email often comes from more than staff mailboxes. Website forms, invoicing, customer support, newsletters and transaction platforms can follow separate routes. A successful message from an employee does not prove that a website form uses the same authentication or infrastructure. Group evidence by source and message purpose before drawing a domain-wide conclusion.
For each active source, note its owner, provider, visible From domain, supported DKIM configuration and SPF identity where relevant. Do not add every unfamiliar sender to DNS solely because it appeared in a report. Confirm that the business owns or authorizes the service and determine whether an obsolete integration should be removed.
Inspect authentication without treating it as a delivery score
Review the actual received message and trusted Authentication-Results from the receiving environment. SPF evaluates an authorized sending route for a particular identity; DKIM verifies a signature for a signing domain. DMARC relates an authenticated identity to the visible From domain through alignment. Passing aligned SPF or passing aligned DKIM can satisfy DMARC.
A pass is not a judgment that the message content is safe, wanted or guaranteed to reach the inbox. A failure also needs context: forwarding, mailing-list changes and a platform using its own identity can complicate interpretation. Inspect the domains and the route instead of replacing a precise result with a single generic email-security score.
Consider receiver requirements and sending behavior
Google's sender guidance cited here applies to personal Gmail accounts and contains requirements that depend on sender category and volume. It is not a universal rulebook for every recipient worldwide. Other receivers and enterprise tenants can apply their own policies. Check the requirements for the receiving population actually affected.
Once the route is clear, review recipient permission, sudden changes in volume, complaint signals, list quality and the purpose of links or attachments. Where bulk or marketing mail is involved, check the applicable unsubscribe requirements and provider guidance. These observations support a diagnostic decision; they do not justify claiming that one content phrase or one DNS record controls all spam placement.
Change one supported control and verify the affected route
Preserve the current DNS configuration and identify an owner for the change. Prefer provider-supported authentication settings for the confirmed source. Avoid adding a second SPF record, copying a stranger's DNS example or increasing a DMARC policy before legitimate senders and reporting have been reviewed. A broad change can interrupt a working route while leaving the failing one untouched.
Define the verification in advance: the affected platform submits the message, the recipient system accepts or explains its handling, and the observed message has the intended authentication identities. Check more than one relevant recipient environment when the business serves several. Record what improved and what remains uncertain; DNS visibility alone is not a successful end-to-end test.
When the symptom may indicate a different problem
Unexpected messages, altered forwarding, unfamiliar application grants or login alerts can point to account compromise rather than ordinary deliverability. Reports of mail apparently sent from your domain may involve spoofing or a lookalike domain instead of the business mailbox. Preserve relevant evidence and use the appropriate incident path before focusing only on inbox placement.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. Our business-email and authentication services can scope the source inventory, provider settings and verification separately. Share the sending platform, affected domain and delivery stage first; keep passwords, private message contents and access tokens out of an initial enquiry.
