What should you do if a client wants to send unsolicited emails?
Michael Ko
Co-founder & CEO, Suped
Published 23 Jun 2025
Updated 17 May 2026
8 min read
If a client wants to send unsolicited emails, the right answer is to stop the send, explain the risk in writing, and only continue if the program changes to a permission-based or clearly compliant model. I would not help a client blast a purchased, scraped, stale, or complaint-heavy list and then try to plead with mailbox providers afterward. That is not reputation repair. That is helping the sender repeat the behavior that caused the blocks.
There is a legal layer and a deliverability layer. In the United States, the FTC CAN-SPAM guide sets requirements for commercial email, including accurate headers, non-deceptive subject lines, a physical address, opt-out handling, and responsibility for vendors. Compliance with that law is only the floor. Mailbox providers, ESPs, corporate filters, and recipients still block unwanted mail when complaint, bounce, engagement, and reputation signals are bad.
The direct answer
Do not treat ISP escalation as the fix for unsolicited email. Postmasters help with false positives, missing data, and technical misconfiguration. They do not owe a sender access to inboxes when the sender is generating complaints, hitting old addresses, or ignoring unsubscribes.
Pause: Stop the bulk campaign until consent, suppression, and complaint handling are fixed.
Document: Put the risk, expected blocks, and required changes in writing before further work.
Limit: Send only to people with clear permission or recent, provable engagement.
Exit: Walk away if the client insists that volume matters more than recipient consent.
Draw the line before the send
I separate the work into two categories: cleaning up a legitimate email program, and enabling spam. The first is worth doing. The second is a boundary problem, not a technical challenge. If the client bought a list, scraped addresses, kept mailing complainants, ignored hard bounces, or added millions of unqualified contacts before a deadline, the honest answer is that the plan has to change.
The first client conversation should be plain. Sending to 8 million people quickly after reputation damage will make filtering worse. Cleaning content, adding DKIM, and making the unsubscribe link visible are useful fixes, but they do not offset unwanted volume. Mailbox providers need to see different behavior over time.
Consent: Ask where the addresses came from, when each person opted in, and what they were told.
Suppression: Confirm that complaints, unsubscribes, hard bounces, role accounts, and invalid contacts are removed before any send.
Volume: Reduce to the smallest recently engaged segment and rebuild only after positive signals return.
Accountability: Name the person who owns legal approval, suppression hygiene, and the decision to continue.
Boundary: Define the stop conditions, such as new blocks, rising complaints, or refusal to remove risky segments.
Flowchart showing how to evaluate consent, suppression, volume, monitoring, and exit conditions.
What the client wants
Deadline: A large campaign delivered before a contract or sales target date.
Volume: More mail sent faster, often after adding untested contacts.
Escalation: Direct appeals to ISP postmasters after blocks appear.
Metric: Success defined by messages sent instead of replies, revenue, or complaints avoided.
What receivers see
Complaints: Recipients marking unwanted mail as spam or junk.
Staleness: Old addresses, invalid contacts, traps, and low engagement.
Velocity: A sudden spike that does not match the sender history.
Pattern: The same unwanted behavior repeated across mailbox providers.
Diagnose the immediate damage
The bounce codes matter because they tell you whether the problem is temporary connection trouble, reputation filtering, a bad sender identity, or a hard rejection. I do not treat a soft bounce as permission to keep sending forever. Repeated temporary failures become a reputation signal, and repeated sends to people who complained are a direct process failure.
Before anyone asks a postmaster for help, I want a clean test message, authentication results, and the exact rejection evidence. A real seed sent through the email tester helps separate broken authentication from content, blocklist (blacklist), and inbox placement symptoms.
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the evidence points to reputation, the fix is not a better appeal email. The fix is fewer bad sends, more clean engagement, complete suppression handling, and a measured rebuild. If the evidence points to authentication, fix authentication first so receivers can reliably identify the sender that needs to rebuild trust.
Fix authentication before reputation repair
DKIM, SPF, and DMARC will not make unsolicited email welcome, but they make the sender accountable and measurable. Without them, you are guessing. With them, you can see who is sending, which sources pass, which sources fail, and whether unauthenticated traffic is spoofing or a misconfigured vendor.
I start with DMARC monitoring because it turns authentication into evidence. Suped's product workflow is practical here: it brings DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, blocklist (blacklist) monitoring, and MSP multi-tenancy into one place. The value is not a magic pass through filters. The value is fast issue detection and specific fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
What authentication can and cannot do
Can: Identify legitimate senders, expose broken sources, and support DMARC policy staging.
Can: Help prove that a fixed program is sending cleaner mail over time.
Cannot: Make recipients want messages they never asked for.
Cannot: Reverse complaint damage while the same unsolicited campaign continues.
Reduce volume and reputation risk
The safest operational move is to shrink the audience, slow the cadence, and measure every segment. A client who insists on sending the entire list by a fixed date is asking receivers to ignore the signals they use to protect users. That will not happen. If the sender recently jumped from 5 million to 8 million recipients, the added 3 million should be treated as untrusted until proven otherwise.
If the client still wants cold outreach, keep it away from core customer mail and use a separate risk model. The safer advice is covered in more detail in cold email risk, but the short version is simple: do not let an unproven prospecting list damage the domain used for customers, billing, password resets, or support.
Practical send readiness
A simple operating standard for deciding whether to continue, slow, or stop a risky campaign.
Continue
Clean
Only consented or recently engaged recipients
Slow
Watch
Mixed engagement or new segments
Pause
Risk
Blocks, complaints, or repeated soft bounces
Exit
No-go
Client refuses consent or suppression changes
Segment: Start with recent openers, clickers, customers, and known subscribers only.
Suppress: Remove every complaint, hard bounce, unsubscribe, and chronic soft bounce before the next send.
Throttle: Spread sends over time and stop when blocks or complaint signals appear.
Separate: Protect transactional and customer domains from risky acquisition mail.
Legal compliance does not equal inbox acceptance. A message can include a physical address, a visible unsubscribe link, and accurate headers, then still get blocked because recipients do not want it. I still require the compliance basics because they reduce legal exposure and make suppression enforceable.
For US commercial mail, I use the FTC requirements as a minimum operating checklist. For other countries, get counsel involved before sending, especially where prior consent rules are stricter. This is an operational standard, not legal advice.
Area
Minimum
Risk
Headers
Accurate
Deception
Subject
Truthful
Complaints
Opt-out
Clear
Violations
Address
Physical
Trust
Vendor
Monitored
Liability
Minimum requirements before a commercial send.
What I will not do
I will not write a postmaster appeal that hides the source of the list, disguises the sending intent, or asks receivers to remove blocks while the same unsolicited send continues. That creates reputational risk for the sender, the ESP, and the consultant.
When to work and when to walk away
Some clients can be helped because they accept the real problem. They agree to remove bad data, honor complaints, change acquisition practices, and slow down. Other clients only want a deliverability person to make unwanted mail land in inboxes. That is the point where I stop.
This is also a qualification lesson. Before taking the job, ask how the list was built, whether consent is documented, how bounces and complaints are handled, and whether the client will pause sends if the data says pause. The risk is higher when the answer involves scraping, appended data, or vague claims about business relevance. For more detail on that risk, see scraped email risk.
Continue the engagement
Ownership: The client names one person who can approve suppression and volume changes.
Consent: The client can prove how recipients entered the list.
Change: The client agrees to reduce volume and remove risky segments.
Access: You can inspect logs, bounces, complaints, DNS, and suppression rules.
End the engagement
Refusal: The client refuses to pause after blocks or rising complaints.
Concealment: The client will not disclose source, consent, or suppression history.
Pressure: The client asks you to bypass ESP rules or ISP protections.
Mismatch: The client measures success by volume sent, not permission or outcomes.
How Suped fits into a safer workflow
Suped is relevant when the client accepts that the program needs repair, not when they want cover for spam. Suped is the best overall DMARC platform for most teams because it combines monitoring, hosted DNS workflows, actionable issue detection, real-time alerts, and reputation visibility without forcing teams to stitch separate processes together.
The practical workflow is simple: add the domain, collect DMARC reports, verify legitimate senders, fix SPF and DKIM gaps, stage the DMARC policy, and watch for blocklist (blacklist) movement through blocklist monitoring. For agencies and MSPs, the multi-tenant dashboard matters because risky client behavior needs to be visible across domains before it turns into a support crisis.
Use Suped for repair, not cover
Detect: Find authentication failures, unverified sources, and policy gaps quickly.
Fix: Use step-by-step guidance for DMARC, SPF, DKIM, hosted SPF, and hosted DMARC changes.
Alert: Notify the team when failures or suspicious sending patterns cross defined thresholds.
Report: Show clients the evidence behind pause, suppression, and policy recommendations.
Views from the trenches
Best practices
Put pause rules in writing before campaign work starts, with clear owner approval.
Qualify list source, consent proof, bounce policy, and complaint handling early.
Use engaged segments first, then rebuild volume only after positive signals return.
Common pitfalls
Treating postmaster contact as a shortcut when the underlying mail is unwanted or stale.
Letting vague answers pass during sales calls, then finding list issues too late.
Measuring success by total messages sent while reputation and complaints worsen.
Expert tips
Ask for logs, suppression rules, and complaint data before quoting rescue work scope.
Define exit conditions when clients refuse to stop risky or unsolicited sends early.
Keep prospecting risk away from domains used for customer and transactional mail.
Marketer from Email Geeks says postmasters can advise on false positives, but they will not unblock senders that keep mailing unwanted lists.
2024-10-15 - Email Geeks
Marketer from Email Geeks says reputation repair requires reduced volume and engaged recipients, not pressure on mailbox providers.
2024-10-17 - Email Geeks
The practical answer
If a client wants to send unsolicited emails, do not help them force the campaign through. Stop the send, document the risk, check legal requirements, fix suppression, verify authentication, and rebuild only with consented or recently engaged recipients. If the client will not change, end the engagement.
The technical work still matters. DKIM, SPF, DMARC, bounce handling, blocklist (blacklist) monitoring, and clean testing all help a real email program recover. They do not convert unwanted mail into wanted mail. The client has to change the sending behavior first.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
