Start with one confirmed message in a recipient’s spam folder. Identify the service that sent it, inspect the receiving system’s authentication results, then investigate reputation, sending patterns and recipient relevance. Changing subject lines before you know the cause usually leaves you guessing.
First, confirm the symptom
“Nobody replies” and “our messages are in spam” are different observations. Ask whether a recipient has actually found the message in their spam folder. If the sender received an error instead, use the bounce and rejection guide.
Write down a few facts before changing anything:
- Which app was used to send the message?
- Was this a normal reply, a CRM mailshot or an automated sequence?
- Did one recipient report it, or several at the same provider?
- When was it sent, including the time zone?
- What changed shortly before the problem appeared?
You’re building a small evidence trail, not trying to prove a theory.
Identify the actual sending route
An email written in a CRM might travel through your connected Microsoft 365 mailbox, or through a separate delivery service. The visible From address does not tell you which route was used.
Compare a normal mailbox message with the affected CRM message. Use an authorised test recipient and record each route separately. If you use Bullhorn, distinguish ATS from Automation. For other recruitment platforms, start in the recruitment field guide.
Ask your administrator or platform support to identify the service using the original received-message headers. Avoid adding every possible platform to your SPF record “just in case”.
Inspect authentication before changing DNS
The receiving system’s results can show whether SPF, DKIM and DMARC passed for that particular message. Our header explainer translates recorded results; it does not verify the header or inspect live DNS.
If a check failed, ask the administrator to compare the message with the records issued by your actual sending service. A generic record from a blog is not a substitute for your account’s setup.
If all three passed, keep investigating. Authentication helps establish who sent a message. It does not establish that the recipient wanted it. The authentication guide explains this distinction.
Look for a pattern, not a magic word
Group affected examples by sending route, recipient provider and message type. Keep expected interview updates or receipts separate from prospecting sequences. Look for a recent increase in volume, older contact data, a new link-tracking domain or a change in the sending connection.
Check whether the problem follows one message version or affects different messages from the same route. Removing a link for a controlled comparison can be informative. It does not prove that every link, image or ordinary word causes spam filtering.
If someone is sending unexpectedly from the account, investigate that activity with IT before trying to restore normal sending.
Choose a test that answers a question
A DNS check can help inspect published authentication records. A spam scorer can inspect a received test message. An inbox-placement test observes where a message lands in its test mailboxes. These are related but different jobs.
Before buying anything, write the question you need answered: “Does this message authenticate?”, “Does the CRM route behave differently?” or “Which test providers place this version in spam?” Read the testing guide for the appropriate next step.
Change one thing and record the outcome
Save the starting result, the exact change, its time and the next check. Use comparable conditions when you retest. If several variables change together, you may improve the result without learning which action helped.
There is no reliable universal recovery deadline. A corrected record and an improved sending history are different kinds of change. Don’t keep resending a campaign to chase a better score.
When to involve IT or platform support
Bring in an authorised administrator for DNS changes, account restrictions, unexplained sending activity or messages that require server-side investigation. Give platform support the product, connection, time and a specific example, rather than “all our email is broken”.
Use the IT handoff builder to organise that brief privately. Keep personal recipient data and original headers within your approved support channel.
Ad / GlockApps affiliate link
Need to see where a test message lands?
GlockApps can show placement in its test mailboxes. Use your actual sending route and read the results by provider. It cannot guarantee placement with your candidates or clients.
We may earn a commission from an eligible purchase. Check current allowances and pricing with GlockApps. How links are funded.
Sources & scope
This is a documentation-led guide, not a claim of hands-on testing in your account. Sources checked 19 October 2026. Product settings and provider policies can change.
How we write and check guides →Give IT something useful to work with.
Turn the symptoms and checks into a clear, private handoff.
Build an IT handoff