When business email starts going to spam, delaying, or disappearing, the fastest fix is a structured diagnosis. Do not change every DNS record at once. Start with a fresh real message, identify the exact symptom, and move through the checks below. Each result tells you what to inspect next.
Follow the decision branches
Was the message submitted to the sending platform?
|-- NO: Check account status, application errors, and send limits.
`-- YES: Did the receiving server accept it?
|-- NO: What does the SMTP response say?
| |-- 4xx: Temporary deferral; inspect retry logs and limits.
| `-- 5xx: Permanent rejection; investigate the exact code.
`-- YES: Did it arrive in the expected inbox?
|-- YES: Compare the affected sender or recipient separately.
`-- NO: Does the received message pass DMARC?
|-- NO: Identify the failed or misaligned sender.
| Check SPF, DKIM selector, and recent DNS edits.
`-- YES: Is only one recipient organization affected?
|-- YES: Ask its admin to inspect rules/quarantine.
`-- NO: Review complaints, list quality, volume,
links, and reputation by mailbox provider.
After a confirmed fix: send a new test.
|-- Fixed: Record the cause, evidence, owner, and change.
`-- Still failing: Escalate with headers, logs, and SMTP response.If accepted mail cannot be found, obtain the recipient’s message trace or quarantine result before assuming it went to spam. The sections below explain each diagnostic branch.
Step 1: Define the symptom
Is mail bouncing, landing in spam, arriving late, or not arriving at all? Is the problem limited to one recipient provider, one campaign platform, or every sender? Save a recent example with the full message headers and timestamp. A delivery delay, a hard bounce, and a spam-placement problem have different causes and should not be treated as one generic “email issue.”
Step 2: Check the sending platform
Confirm the message was accepted or sent by the platform. Review account status, sending limits, authentication setup, recent domain changes, and bounce logs. Make sure the visible From address, return-path, and configured sending domain match what the platform expects. If only one tool is affected, compare its configuration with a sender that is working.
Step 3: Inspect SPF
SPF identifies systems authorized to send using the envelope-from domain. Check that there is one SPF record, that it includes the platform actually sending the message, and that it does not exceed the ten DNS-lookup limit. Then inspect the fresh message header for the SPF result. Use the SPF check guide and lookup-limit troubleshooting before editing DNS.
Step 4: Inspect DKIM
Find the DKIM-Signature header and check whether the result passes. Note the signing domain and selector, then confirm the selector record exists publicly. A missing selector, incorrect key, or unsigned third-party sender can weaken delivery and DMARC alignment. Review how to check DKIM for the exact evidence.
Step 5: Inspect DMARC alignment
DMARC passes when SPF or DKIM passes with an identity aligned to the visible From domain. A message may show an SPF or DKIM pass while still failing DMARC because it uses a different domain. Check the published DMARC policy, any aggregate reports, and the fresh header. See what a DMARC failure means before lowering enforcement.
Step 6: Review reputation and recipient signals
If authentication passes but placement is poor, look at complaint rate, bounce rate, sending volume, list source, engagement, and content. A sudden campaign to inactive or unconsented recipients can harm reputation even with perfect DNS. Separate promotional mail from transactional mail and test at more than one recipient provider when possible.
Step 7: Check DNS and change timing
After a recent DNS or vendor change, compare the current public value with the intended value. TTL-based caching can make results vary temporarily, but propagation does not explain a malformed record or incorrect host name. Make one evidence-based correction, wait through the expected cache window, and send a new test. Read DNS propagation and email problems for this decision point.
Step 8: Escalate with useful evidence
When contacting a provider, include the recipient address domain, timestamp, message ID, complete headers, error text, and exact sender path. Keep the old and new DNS values. This gives support enough information to investigate without guessing, and it leaves a clear record for your team.
Run Beacon’s free domain check to review the public SPF, DKIM, and DMARC baseline before or during troubleshooting.
Document the resolution
Record the confirmed cause, change made, test result, and owner. This turns the next issue from a fresh investigation into a faster, repeatable response.