Deliverability

Why Are My Emails Going to Spam? 12 Reasons and How to Fix Them (2026)

Opens drop, replies disappear, and then a customer mentions your last three emails were in spam. Here are the 12 causes, how to identify which one applies to you, and what to fix first.

By The SendDoggie Team · August 2026 · 20 min read

You send a campaign.

Opens drop. Replies disappear. Then a customer tells you they found your last three emails in spam.

Nothing obvious changed.

The spam folder can feel arbitrary when this happens, but receiving mail servers are not making random decisions. They evaluate authentication, reputation, recipient behaviour, sending patterns, list quality and message structure.

Most deliverability problems come down to three questions:

The technical requirements have also become stricter.

Gmail's sender requirements have applied since February 1, 2024. Senders delivering more than 5,000 messages per day to personal Gmail accounts face additional requirements including SPF and DKIM, DMARC, alignment and one-click unsubscribe for marketing and subscribed messages. Gmail says enforcement against non-compliant traffic has been ramping up since November 2025. (Google Help) Microsoft also requires SPF, DKIM and DMARC for domains sending more than 5,000 messages per day to its Outlook.com consumer service. (Microsoft)

But authentication alone does not guarantee inbox placement.

A perfectly authenticated sender can still land in spam because recipients do not want the mail.

This guide covers 12 common reasons emails go to spam, how to identify which one applies to you, and what to fix.

The important part is the order.

First, diagnose why your emails are going to spam

A common response to a deliverability problem is to change everything at once:

• edit SPF;
• regenerate DKIM;
• rewrite the template;
• remove links;
• change the From address;
• reduce sending;
• clean the list.

That makes troubleshooting harder.

If the problem disappears, you have no idea which change fixed it.

Start with four checks.

Check 1: Determine whether the problem is provider-specific

Send a representative message to test addresses you control at:

• Gmail
• Outlook.com
• Yahoo
• a business Microsoft 365 mailbox

Then compare placement.

This is not a perfect deliverability test. A handful of seed addresses cannot reproduce the reputation associated with thousands of real recipients.

It does, however, tell you whether you are dealing with an obvious infrastructure failure or something more dependent on recipient history.

Check 2: Read the authentication headers

Do not trust a dashboard that merely says:

The receiving server's result is what matters.

In Gmail, open the received message, choose Show original, and inspect Authentication-Results.

A healthy result might look like:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@news.example.com;
   spf=pass smtp.mailfrom=bounce@news.example.com;
   dmarc=pass header.from=example.com

That tells you the receiver successfully evaluated the message.

Now consider this:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@mailer.provider.net;
   spf=pass smtp.mailfrom=bounce@mailer.provider.net;
   dmarc=fail header.from=example.com

This catches many senders by surprise.

SPF passed. DKIM passed. DMARC failed.

Why?

Because SPF and DKIM authenticated provider.net, while the recipient sees example.com in the From header.

That is a DMARC alignment problem.

Check 3: Check Google Postmaster Tools

Google Postmaster Tools can provide information about mail you send to Gmail users, including:

• user-reported spam rate;
• domain reputation;
• IP reputation;
• authentication;
• delivery errors.

Register your sending domain before you have a serious deliverability incident.

Historical visibility is much more useful than discovering a problem first and adding monitoring afterward.

Google currently advises senders to keep their Postmaster Tools spam rate below 0.10% and avoid ever reaching 0.30% or higher. (Google Help)

Check 4: Compare your recent sends

Look at your last several campaigns.

Record:

• messages sent;
• hard bounces;
• soft bounces;
• complaints;
• unsubscribes;
• recipient segment;
• sending domain;
• From address;
• sending volume.

Then ask:

What changed immediately before placement deteriorated?

Perhaps you imported an old list.

Perhaps you doubled campaign volume.

Perhaps a new application started sending through the same domain.

Perhaps one particular segment generated most complaints.

That is far more useful than asking whether your subject line contained the word "free."

Gmail, Yahoo and Microsoft sender requirements in 2026

Provider requirements are a baseline. They are not a promise of inbox placement.

For Gmail, all senders to personal Gmail accounts must meet requirements such as SPF or DKIM authentication, valid forward and reverse DNS, TLS and RFC 5322 formatting.

Senders exceeding Gmail's bulk-sender threshold have additional requirements, including:

• SPF and DKIM;
• DMARC;
• From-domain alignment with SPF or DKIM;
• one-click unsubscribe for marketing and subscribed messages;
• a visible unsubscribe link;
• maintaining acceptable spam rates.

Google defines a bulk sender as one sending close to 5,000 or more messages to personal Gmail accounts within 24 hours, counted across the same primary domain. Once Google classifies a sender as a bulk sender, its FAQ says that status does not expire. (Google Help)

Microsoft applies SPF, DKIM and DMARC requirements to domains sending more than 5,000 messages per day to Outlook.com consumer domains such as Outlook.com, Hotmail.com and Live.com. (Microsoft)

Yahoo publishes comparable authentication, unsubscribe and sender-quality expectations. (Yahoo Sender Hub)

The important operational lesson is:

1. Your SPF, DKIM or DMARC is not actually passing

"We configured authentication" and "receivers successfully authenticate our mail" are different statements.

DNS errors can survive unnoticed for months.

Common SPF problems

Multiple SPF records

A domain should not publish separate SPF policies like:

v=spf1 include:_spf.google.com ~all

and:

v=spf1 include:example-email-service.com ~all

If both services legitimately send mail for the domain, their mechanisms belong in a single SPF record, for example:

v=spf1 include:_spf.google.com include:example-email-service.com ~all

The exact record depends on your actual providers. Do not copy an SPF example into production without checking what services send on behalf of your domain.

SPF lookup limits

SPF evaluation has a limit on DNS-querying mechanisms. Nested include: statements count too.

That means a short-looking SPF record can still exceed the limit because an included provider includes several other domains.

Remove obsolete sending services rather than continually adding new includes.

Common DKIM problems

DKIM failures often come from:

• publishing the record under the wrong selector;
• accidentally publishing it under the root domain;
• malformed public keys;
• DNS interfaces splitting or modifying long TXT values;
• configuring one sending subdomain but sending from another.

A selector might be queried at:

selector1._domainkey.example.com

But the selector name must match the one used by your sending provider.

Common DMARC problems

DMARC normally lives at:

_dmarc.example.com

A monitoring policy might resemble:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none tells receivers not to quarantine or reject mail solely because it fails DMARC policy enforcement, while still allowing reporting.

Do not immediately copy p=reject from a tutorial.

First identify every legitimate system sending mail for your domain.

Troubleshooting authentication

Query your records independently:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Then send an actual message.

Inspect Authentication-Results.

Published DNS is step one. Receiver-side passing is the real test.

For a record-by-record walkthrough of each mechanism, see our guide to SPF, DKIM and DMARC.

2. Your From domain is not aligned

DMARC does not simply ask whether SPF passed, or whether DKIM passed.

It asks whether an authenticated domain aligns with the domain visible to the recipient.

Consider:

From:        hello@example.com
Return-Path: bounce@mailer.provider.net
DKIM d=:     mailer.provider.net

The receiver could produce:

SPF:   pass for provider.net
DKIM:  pass for provider.net
DMARC: fail for example.com

Everything looks authenticated until you consider alignment.

How to fix DMARC alignment

Authenticate a domain you control with your sending platform.

Depending on the platform, this can involve:

• DKIM CNAME or TXT records;
• a custom MAIL FROM domain;
• a custom return-path subdomain;
• domain verification records.

A typical architecture might use:

From:        newsletter@example.com
DKIM d=:     example.com
Return-Path: bounce.mail.example.com

Exact values depend on your email provider.

The goal is not to make every domain string identical. DMARC supports organizational-domain alignment rules.

The goal is for at least one authenticated identifier, SPF or DKIM, to align with the visible From domain.

A common mistake: sending bulk mail as a free Gmail address

Do not configure a bulk email platform to send marketing mail with:

From: businessname@gmail.com

You do not control gmail.com, so you cannot publish the authentication records necessary to make that domain yours.

Use a domain you control.

3. Your domain or IP reputation is poor

Authentication establishes identity.

Reputation answers a different question: what has mail associated with this sender historically looked like?

A sender can have perfect SPF, DKIM and DMARC and still go to spam.

Signals that can damage reputation include:

• recipient complaints;
• persistent delivery to invalid addresses;
• abrupt volume changes;
• unwanted mail;
• poor engagement patterns;
• suspicious link domains;
• reputation problems associated with sending infrastructure.

Google Postmaster Tools can expose domain and IP reputation information for qualifying Gmail traffic.

How to recover

Do not try to solve a reputation problem by repeatedly redesigning your template.

Instead:

1. reduce sending to your most clearly engaged recipients;
2. suppress known bad addresses;
3. investigate complaint sources;
4. stop questionable acquisition sources;
5. maintain predictable volume;
6. give reputation time to recover.

Reputation is historical.

Fixing a DNS record can take minutes once propagation completes. Repairing sender reputation can take considerably longer because receivers need new sending history.

Do not rotate domains to escape reputation problems

A new domain does not automatically have good reputation.

It has little or no history.

Immediately sending large volumes from a newly established domain can create another deliverability problem while leaving the original cause untouched.

Fix the underlying behaviour first.

4. You increased sending volume too quickly

Mailbox providers observe sending patterns.

If a domain historically sends 500 messages per day and suddenly sends 50,000, that is a meaningful change.

There is no universal warming schedule that guarantees inbox placement.

Your appropriate ramp depends on:

• previous domain history;
• IP history;
• recipient engagement;
• provider distribution;
• list quality;
• complaint behaviour;
• whether infrastructure is shared or dedicated.

That is why rigid tables such as "send exactly 500 on day one and 1,000 on day two" should not be treated as standards.

A better ramp strategy

Start with your strongest audience.

Increase only when delivery indicators remain healthy.

If complaints or delivery errors deteriorate, hold or reduce volume rather than blindly continuing the schedule.

Best practice

Treat warming as feedback-controlled sending, not a calendar exercise.

The question is not "what day of the warm-up are we on?"

It is "what happened when we sent the previous batch?"

5. Recipients are marking your email as spam

Authentication proves who sent the message.

It does not prove that recipients wanted it.

Google recommends keeping user-reported spam rates in Postmaster Tools below 0.10% and avoiding 0.30% or higher. (Google Help)

The absolute numbers can be surprisingly small.

For illustration:

20 complaints / 20,000 delivered messages = 0.10%
60 complaints / 20,000 delivered messages = 0.30%

Those are mathematical examples, not industry benchmarks.

Why people report legitimate companies as spam

Often because:

• they do not remember subscribing;
• the sender increased frequency;
• the message is unrelated to what they signed up for;
• unsubscribing is difficult;
• an old customer list was turned into a newsletter list;
• the sender waited months before sending the first campaign.

The Spam button is extremely convenient.

Your unsubscribe process needs to be at least as convenient.

How to reduce complaints

• Set expectations during signup.
• Make the sender identity recognizable.
• Avoid surprising frequency changes.
• Segment by subscriber interest.
• Stop repeatedly emailing chronically disengaged contacts.
• Make unsubscribe obvious and functional.

Do not hide the unsubscribe link because you are worried about losing subscribers.

6. Your email list is old or low quality

An email list does not remain healthy automatically.

Addresses disappear. Employees leave companies. Domains expire. People abandon personal accounts. Subscribers forget why they signed up.

A list collected years ago therefore should not automatically receive the same campaign as someone who subscribed yesterday.

Segment by engagement and provenance

Instead of treating every contact equally, store information such as:

{
  "email": "alex@example.com",
  "source": "newsletter_form",
  "subscribed_at": "2025-09-12T14:32:00Z",
  "last_engaged_at": "2026-07-28T09:15:00Z",
  "status": "subscribed"
}

Then segment using both:

• how the address was acquired;
• how recently the subscriber engaged.

Avoid purchased and scraped lists

Buying addresses solves the wrong problem.

You obtain contacts without obtaining the relationship that makes those contacts valuable.

It also increases the likelihood of:

• complaints;
• invalid addresses;
• spam traps;
• poor engagement;
• legal and policy problems.

An email address being publicly visible does not mean the owner subscribed to your marketing.

7. You are emailing people who did not expect your messages

Consent is not merely a database field.

Expectation matters.

Someone who purchased a product, downloaded a PDF, registered for an event, created an account, or contacted support has given you an email address for a specific purpose.

That does not automatically mean they expect every type of marketing campaign you might want to send.

Make signup expectations explicit

A useful signup form answers what the visitor will receive, and how often.

For example:

That is much clearer than:

Then send the first message while the subscriber still remembers signing up. Our welcome sequence playbook covers what that first series should contain.

Consider double opt-in

With double opt-in:

1. a visitor enters their email;
2. you send a confirmation message;
3. they click the confirmation link;
4. only then does the address become an active subscriber.

A simplified backend flow:

def signup(email):
    subscriber = create_pending_subscriber(email)
    send_confirmation(subscriber)

def confirm(token):
    subscriber = get_subscriber_by_token(token)
    subscriber.status = "subscribed"
    subscriber.confirmed_at = now()
    subscriber.save()

Double opt-in can reduce typo addresses and automated submissions while creating a stronger record that the mailbox owner confirmed the subscription.

8. You keep sending to bouncing addresses

Bounce processing should be part of your sending infrastructure, not a monthly spreadsheet task.

A permanent bounce generally means the message cannot be delivered to that address.

Continuing to send to known permanently bouncing recipients is unnecessary and harmful.

Amazon SES provides suppression functionality for bounced and complained addresses, and AWS advises removing addresses associated with hard-bounce suppression unless you have good reason to believe they are valid. (AWS Documentation)

Basic suppression logic

def process_bounce(event):
    if event.bounce_type == "Permanent":
        suppress(
            email=event.email,
            reason="hard_bounce"
        )

def process_complaint(event):
    suppress(
        email=event.email,
        reason="complaint"
    )

For temporary failures, do not blindly treat every soft bounce as permanent.

A temporary failure could represent:

• a full mailbox;
• greylisting;
• temporary server problems;
• rate limiting.

Your retry strategy should consider the actual SMTP response and repeated failure history.

The re-import bug

One operational mistake appears repeatedly in email systems:

1. recipient hard-bounces;
2. system suppresses them;
3. marketer imports an old CSV;
4. contact is recreated as active;
5. system sends to them again.

The solution is simple: check suppression at send time.

if suppression_exists(recipient.email):
    skip_send(recipient)
else:
    queue_email(recipient)

Suppression should be a final sending guard, not merely an attribute attached to the current list.

9. Your email or links look suspicious

Spam filtering is much more sophisticated than searching for a list of forbidden words.

The word "free" does not automatically send an email to spam.

Structural patterns matter.

Avoid unnecessary redirect chains

Instead of:

email
  -> generic-shortener.example
  -> tracking-provider.example
  -> yoursite.example

prefer a cleaner path where practical:

email
  -> links.example.com
  -> yoursite.example

A custom tracking domain also gives you greater control over the domain appearing in your links.

Avoid image-only emails

A campaign consisting almost entirely of one image is fragile even beyond spam filtering.

If images are disabled, there may be almost nothing for the recipient to read.

Use meaningful HTML text and descriptive alt text.

Send multipart email

A normal marketing message can contain both plain text and HTML:

Content-Type: multipart/alternative

--boundary
Content-Type: text/plain; charset=UTF-8

Your plain-text version.

--boundary
Content-Type: text/html; charset=UTF-8

<html>
  <body>
    <p>Your HTML version.</p>
  </body>
</html>

Your email platform will normally construct MIME boundaries for you.

The important point is to provide a sensible plain-text alternative rather than manually building MIME unless you operate the sending layer yourself.

Avoid deceptive content

Your From name, subject and content should describe what the message actually is.

Do not imitate reply prefixes, account warnings or personal conversations to trick someone into opening a marketing email.

Even if such tactics create a temporary click, the resulting negative recipient behaviour is exactly what you do not want. Deceptive subject lines are also a compliance problem: the FTC applies a primary-purpose test to the content of a message rather than the label the sender attaches to it. (FTC)

10. Your unsubscribe implementation is broken

For qualifying bulk marketing and subscribed mail, Gmail requires one-click unsubscribe.

This is not the same thing as placing the word "Unsubscribe" at the bottom of the HTML.

RFC 8058 defines one-click unsubscribe using headers such as:

List-Unsubscribe: <https://example.com/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS endpoint needs to process the provider's POST request. (RFC 8058)

A simplified endpoint could look like:

@router.post("/unsubscribe/{token}")
def one_click_unsubscribe(request, token: str):
    subscriber = find_by_unsubscribe_token(token)

    if subscriber:
        subscriber.status = "unsubscribed"
        subscriber.save()

    return 200

Production implementations also need secure, unguessable tokens and idempotent processing.

Common one-click unsubscribe mistakes

Mistake 1: Only accepting GET. The mailbox provider performs the one-click action using POST.

Mistake 2: Requiring login. A recipient should not need to remember an account password just to stop marketing mail.

Mistake 3: Requiring another confirmation. Do not turn "unsubscribe" into a multi-step retention funnel.

Mistake 4: Expiring unsubscribe tokens too aggressively. A recipient may unsubscribe from an older message.

Mistake 5: Only unsubscribing from the current campaign. Suppression semantics should match what the recipient asked to leave. If they opted out of all marketing, another list should not quietly reactivate them.

Keep a visible unsubscribe mechanism in the message body as well.

11. You mix transactional and marketing email

Your password-reset email and Black Friday campaign have very different risk profiles.

Do not unnecessarily make one depend on the reputation of the other.

A practical architecture can look like:

example.com
├── Human/company mail
│
├── news.example.com
│   └── Marketing campaigns
│
└── notify.example.com
    └── Receipts, password resets and account notifications

This separation can help isolate traffic streams and makes operational monitoring clearer.

But subdomains are not magic.

You still need:

• authentication;
• alignment;
• bounce processing;
• appropriate volume;
• good recipient behaviour.

And depending on how providers aggregate reputation, organizational-domain reputation can still matter.

Keep transactional messages transactional

A password reset should help someone reset their password.

An order receipt should describe their order.

Adding substantial promotional content to operational mail can blur the purpose of the message and create unnecessary compliance and deliverability complications.

Keep the streams conceptually separate as well as technically separate. The same reasoning applies to commercial mail triggered by store events, such as abandoned cart emails: a shopping trigger does not make a promotional message transactional.

12. You are not monitoring deliverability

The worst time to configure deliverability monitoring is after customers start asking where their emails went.

Set it up while everything is healthy.

Google Postmaster Tools

Monitor available information such as:

• spam rate;
• domain reputation;
• IP reputation;
• authentication;
• delivery errors;
• compliance status.

DMARC aggregate reporting

A basic monitoring record might include:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Aggregate reports can reveal sending systems you forgot existed.

That happens frequently in real organizations.

Marketing authenticates the newsletter platform, while the CRM, helpdesk, invoicing system, recruitment platform or an old application server still sends using the same organizational domain.

DMARC reporting helps inventory those senders.

Do not jump straight to p=reject

Moving immediately from no DMARC to:

v=DMARC1; p=reject

can block legitimate mail if you have not identified every sender.

A safer process is:

1. publish DMARC reporting;
2. collect reports;
3. inventory legitimate sources;
4. authenticate them;
5. verify alignment;
6. gradually tighten policy where appropriate.

Common mistakes that put legitimate email in spam

Across all 12 causes, several mistakes appear repeatedly.

Trusting the sending platform instead of the receiver

"Domain verified" does not necessarily tell you what Gmail saw on a specific message.

Read the headers.

Fixing five things simultaneously

You lose the ability to identify the root cause.

Change one meaningful variable at a time.

Treating every deliverability problem as content

Changing "FREE" to "special offer" will not repair failed DMARC or a damaged reputation.

Treating authentication as a guarantee

SPF, DKIM and DMARC are prerequisites for trustworthy sending.

They do not force Gmail, Yahoo or Outlook to put your email in the inbox.

Continuing to mail unengaged recipients forever

List size is a vanity metric if much of the list no longer wants the mail. If you are judging recovery by opens, compare against realistic open rate benchmarks rather than your best month ever.

Hiding unsubscribe

You are not preventing churn.

You are encouraging recipients to use the Spam button instead.

Ignoring SMTP response codes

The receiving server often tells you what happened.

Store the response. For example:

550 5.7.515 Access denied, sending domain does not meet
the required authentication level

That is far more actionable than a dashboard saying simply "delivery failed."

Troubleshooting: diagnose email spam problems by symptom

A practical 7-step recovery plan

If your emails are already going to spam, resist the temptation to blast another campaign just to see whether the problem fixed itself.

Step 1: Preserve evidence

Before changing anything, save:

• raw message headers;
• SMTP responses;
• campaign metrics;
• sending volume;
• Postmaster Tools data;
• recent list imports.

Step 2: Verify authentication

Check:

SPF   = pass
DKIM  = pass
DMARC = pass

Then confirm alignment.

Step 3: Fix hard technical failures

Correct:

• invalid SPF;
• broken DKIM;
• missing DMARC;
• alignment failures;
• DNS mistakes;
• missing unsubscribe implementation.

Step 4: Clean sending eligibility

Immediately suppress:

• permanent bounces;
• complaints;
• unsubscribed contacts.

Then investigate old and chronically disengaged segments separately.

Step 5: Identify the best audience

Do not test recovery by sending to the riskiest part of your database.

Start with recipients who clearly requested and recently interacted with your mail.

Step 6: Resume conservatively

Increase volume based on feedback rather than a predetermined daily multiplier.

Step 7: Monitor every meaningful send

Compare:

• complaints;
• bounces;
• provider responses;
• Postmaster Tools data;
• segment-level performance.

Deliverability recovery is a process, not a DNS toggle.

Email deliverability best practices checklist

Before your next major campaign, verify:

• SPF is published correctly.
• Only one valid SPF policy exists for the hostname being evaluated.
• SPF does not exceed its DNS lookup limit.
• DKIM passes on actual received messages.
• DMARC exists.
• SPF or DKIM aligns with the From domain.
• You send marketing mail from a domain you control.
• Sending domains and IPs meet applicable forward and reverse DNS requirements.
• TLS is used for transmission.
• Marketing and transactional traffic are appropriately separated.
• One-click unsubscribe is implemented where required.
• A visible unsubscribe option exists in marketing messages.
• Permanent bounces are suppressed.
• Complaints are suppressed.
• Unsubscribes are enforced at send time.
• Old CSV imports cannot bypass suppression.
• You know how each audience was acquired.
• Purchased and scraped lists are not used.
• Sending volume changes are controlled.
• Links use domains you trust.
• Messages contain a usable plain-text alternative.
• Google Postmaster Tools is configured where applicable.
• DMARC reports are reviewed.
• SMTP rejection details are stored for troubleshooting.

Where SendDoggie fits

A good email platform should remove repetitive infrastructure work without pretending software can manufacture sender reputation.

SendDoggie combines marketing campaigns and transactional email with domain authentication, contact management, segmentation, campaign analytics, SMTP sending and an email API.

Because SendDoggie's sending infrastructure uses Amazon SES, bounce and complaint feedback can be incorporated into the sending workflow rather than treated as something marketers manually clean up months later.

The division of responsibility is important.

A sending platform can help you configure infrastructure, manage contacts, process sending events and expose campaign data.

It cannot make recipients want an email they never asked for.

Good deliverability still depends on:

• legitimate audience acquisition;
• useful messages;
• reasonable frequency;
• list hygiene;
• respecting unsubscribes;
• responding to negative signals quickly.

That is why deliverability should be treated as an operational system rather than a score attached to an individual campaign.

Conclusion

When emails start going to spam, the fastest path back is usually not rewriting the subject line.

Start lower in the stack.

Check what the receiving server actually saw.

Did SPF pass? Did DKIM pass? Did DMARC pass? Did the authenticated domains align with the visible From domain?

If authentication is healthy, move upward.

Check reputation, complaints, list quality, sending volume, bounce processing and unsubscribe behaviour.

The most useful distinction is this:

You need all three working together.

Key takeaways

Sources

1. Google — Email sender guidelines
2. Google — Email sender guidelines FAQ
3. Google Postmaster Tools
4. Yahoo Sender Hub — Sender requirements and best practices
5. Microsoft — Outlook requirements for high-volume senders
6. RFC 7208 — Sender Policy Framework (SPF)
7. RFC 6376 — DomainKeys Identified Mail (DKIM)
8. RFC 7489 — DMARC
9. RFC 8058 — One-Click Unsubscribe
10. Amazon SES — Suppression list documentation
11. FTC — CAN-SPAM Act Compliance Guide for Business