SourceWhale emails going to spam: a practical investigation

Choose the symptom you can actually confirm

“SourceWhale is going to spam” can describe several different problems. A scheduled step may still be waiting to send. A receiving server may have rejected it. A candidate may have found it in junk. Low replies, on their own, establish none of those outcomes.

For a confirmed junk example, record whether it affected one mailbox, one campaign version or several routes. “All candidates” is a hypothesis until the evidence supports that scope.

Identify the mailbox behind the campaign step

SourceWhale offers multichannel sequences. Investigate the email step that failed, rather than assuming every activity in the campaign uses one delivery route.

Write down the campaign reference, step, sending mailbox, connection, message version, time and time zone. Ask the administrator which service handled that exact message. SourceWhale’s public account terms refer to Gmail and Outlook accounts; the connection and received-message evidence in your own setup are what matter here.

If the route is Microsoft 365, use the Microsoft 365 investigation alongside this page. If it is another service, use that service’s logs and account-issued instructions. Do not add an SPF include or DKIM selector simply because a different recruitment tool uses it.

Sending a similar message directly from Outlook or Gmail can be a useful comparison. Record it as a different route, rather than treating it as proof of what the SourceWhale step does.

Use the original message to check authentication

Ask a willing recipient for the original message headers through an approved support channel. A forwarded body or screenshot of a DNS checker leaves out evidence the mail administrator may need.

Have the administrator inspect the received authentication results, including alignment with the visible From domain. Our header explainer helps read pasted result text locally; it does not verify a DKIM signature or establish whether a header block is trustworthy.

If there is a confirmed configuration fault, fix that route with its owner and verify a fresh message. If authentication passes, continue investigating. SPF, DKIM and DMARC passing does not guarantee inbox placement.

Check the message the recipient received

A campaign editor is only part of the picture. Review an authorised delivered example for failed merge fields, unexpected links, a stale signature, attachments and the working opt-out mechanism. Use synthetic candidate and client details in previews and external tests.

Separate a link destination from any tracking redirect. Record the actual domains involved without publishing recipient-specific tokens. If you suspect tracking, use the tracking comparison method to isolate one change. Removing tracking, attachments and the signature together cannot tell you which change mattered.

Also check who should receive the campaign. A working address and successful authentication do not establish that a person expects this outreach. Use the candidate-list preparation guide before another mailshot.

Review pacing without inventing a safe quota

SourceWhale’s public help centre describes email throttling in Profile & Settings. That establishes a control exists; it does not establish a universal safe daily number or the current value in your account.

Ask the owner to record the configured cap, schedule, time zone, pending queue and other campaigns using the same mailbox. Include ordinary correspondence and other connected applications when discussing the mailbox’s total activity with IT. A campaign cap, a provider limit and a recipient spam decision are different things.

Before resuming a paused campaign, agree who will monitor it and what will stop it again. A new restriction, unexplained sending, repeated connection errors or a material increase in invalid-recipient failures needs investigation. Respect complaints and opt-outs; do not wait for a test score to override them. Do not release an accumulated queue simply to catch up with a planned schedule.

Your provider and administrator set the applicable limits and response. Staying below a configured cap is not a guarantee that mail will be wanted or reach the inbox.

When a GlockApps test adds useful evidence

A controlled seed test is useful when the unanswered question concerns placement through this sending route. It is less useful when you already have a broken connection or an exact rejection to investigate.

Use a manual GlockApps test only if your authorised SourceWhale workflow can send the prepared message to the current test destinations. Keep seed addresses out of real candidate records, automated follow-ups and future campaigns. If your account cannot reproduce the route safely, ask SourceWhale support for a supported method.

Follow the GlockApps walkthrough, keep the sender and message conditions comparable, and record missing messages as well as inbox and spam observations. We have not verified a native SourceWhale–GlockApps integration. This is a controlled sending method, not an integration setup guide.

Check GlockApps manual testing options

Give support a question they can answer

Use a brief such as this newly written, illustrative example:

One email step in a candidate campaign reached a confirmed recipient’s junk folder. The mailbox connection and message reference are recorded privately. Can you confirm the service that sent this step, check its sending event and authentication, and explain whether its generated links differ from a direct mailbox message?

Attach the relevant evidence privately, with recipient details limited to what the authorised support team needs. Add what changed recently and what remains unknown. The IT handoff builder and blank investigation record can help structure it without uploading the evidence to this site.