Confirm that this is inbox placement, not rejection
A pass proves authentication, not inbox placement; inspect the recipient's classification and the actual sending route.
An SPF or DKIM pass authenticates a sending identity but cannot force inbox placement. This article concerns accepted mail placed in Junk or quarantine, not a bounce or missing message. Record the receiving provider’s classification, actual sending route and timestamp before investigating filtering.
This applies to a Novasean customer sending from an existing entitled mail service, a hosted application, or an authorised VPS. The actual outbound mail operator controls its server, IP reputation and logs; an external mail provider controls its own sending platform. Novasean cannot promise inbox placement at Gmail, Microsoft 365 or another recipient service. If the message was rejected, use the related rejection guide instead.
Compare one real message with a known good one
Ask a recipient you control, or that recipient's authorised mail administrator, to preserve the affected message and its original headers, including Authentication-Results. Record whether the receiving service labelled it Spam or Junk, or held it in quarantine, and compare with a comparable message that reached the inbox through the same sender and route. A single test to your own account cannot measure delivery for all recipients; one recipient's personal rule can also explain a local difference.
If only one recipient puts the same accepted message in Junk, compare that provider's headers and any local rule with a controlled inbox copy before changing domain-wide DNS.
Inspect the header results reported by the receiving service, not just the DNS records you published. Note the visible From domain, the SPF-authenticated envelope domain, the DKIM d= domain and the DMARC result. SPF and DKIM can each pass for domains that do not align with the visible From domain; DMARC can then fail. If alignment is the fault, correct the authorised sender configuration using the related SPF, DKIM and DMARC guides before investigating reputation. Preserve message IDs and sanitised diagnostic headers for support, but remove recipients, subjects, private content and tokens from any shared excerpt.
Separate authentication from filtering
If SPF, DKIM and aligned DMARC pass, do not add random SPF mechanisms or weaken DMARC to try to escape the spam folder. Authentication is only one input to filtering. Gmail's sender guidance also considers sending IP and domain reputation, complaint rates, forward and reverse DNS, message format and sending practices. On a shared sending IP, another sender's behaviour can affect its reputation. A customer should ask the operator to investigate the actual outbound IP rather than changing an unrelated website DNS record.
For mail to personal Gmail accounts, a domain owner who can verify the domain in Google Postmaster Tools may see authentication, reputation, spam-rate and delivery-error dashboards. Those dashboards are delayed, can omit low-volume days and do not prove the fate of an individual message. For Microsoft 365 recipients, the receiving administrator can inspect the message's filtering verdict and authentication headers; a pass does not rule out a separate spam or phishing classification. Do not ask a recipient to disable protection or add a broad allow rule to mask the cause.
Change the cause you actually control
For a sender-domain or message-format problem, keep the sender identity, headers and links accurate, use the approved sending route, and fix any observed authentication or DNS fault. If the message is promotional or subscription mail, send only to people who asked for it, honour opt-outs and follow the current recipient-provider unsubscribe requirements that apply to your volume and message type. Do not buy address lists, send bursts of repeated tests, rotate identities to evade filtering, or mix advertising into transactional receipts. These practices can damage reputation rather than repair it.
If evidence points to the outbound IP, shared-host reputation, transport configuration or an account compromise, ask the actual mail operator to review it. A VPS owner who directly sends SMTP mail may need an operator-approved PTR and matching forward record for the real sending IP; use the related PTR guide. On a hosted or third-party mail platform, that infrastructure may be outside your account's control. Novasean support can assess its own service boundary; an external sender or receiving administrator must inspect decisions made on their systems.
Retest without promising inbox placement
After one justified change, send a permitted, representative message through the same application and route to a recipient who agreed to the test. Compare the new message's receiving headers, delivery folder and time with the original. Repeat with another affected recipient provider only when the first result warrants it. Changes in Postmaster Tools may take time to appear, and a message reaching the inbox once does not prove a permanent reputation recovery.
If the problem persists, give support the sending service, approximate time, recipient provider, message ID, observed folder and sanitised receiving results. Say which change was made and what happened on retest. Keep message bodies, account passwords, private keys and full unredacted headers out of a public ticket. If the receiving organisation controls the filtering rule, its administrator needs to review that rule and any false-positive report.
Does one inbox result prove a permanent fix? No. Compare representative recipients and monitor the relevant operator evidence.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.