Email: Outbound reputation tanked — what to stop doing immediately (and fixes)

Stop doing these things immediately

1) Stop “testing” by blasting your whole list

If reputation is dropping, volume amplifies the damage. Sending more mail into higher bounce rates and complaints teaches mailbox providers that you’re the kind of sender they should protect users from. Your first job is to stop feeding the fire.

Replace mass testing with controlled samples to a verified seed list and a small subset of your most engaged recipients (recent opens/clicks/replies). And if you can’t measure engagement, that’s not a reason to keep blasting; that’s a reason to slow down.

2) Stop sending from new domains “to fix it”

“Let’s just send from a different domain” is deliverability debt with interest. Providers correlate infrastructure, URLs, content, and behavior. Plus you lose whatever good reputation you had. Fix the problem; don’t rename it.

3) Stop ignoring bounces and retrying forever

Your MTA happily retries 4xx responses. That’s correct behavior for transient failures, but if you’re receiving throttling or reputation-based tempfails, you need rate control and suppression strategy—not infinite optimism.

4) Stop sending mail that fails authentication (or “sort of” passes)

SPF pass with DKIM fail isn’t “fine.” DMARC pass without alignment isn’t “fine.” In 2026, major providers lean harder into authenticated, aligned mail. You don’t need perfection, but you do need to stop shipping unauthenticated or misaligned mail like it’s 2009.

5) Stop running marketing and transactional mail through the same identity

Mixing a weekly newsletter with password resets under the same domain and IP is how you accidentally teach Gmail that “your login codes are the same vibe as your winter sale.” Segregate streams: subdomains, separate DKIM selectors, separate IP pools if you’re big enough.

6) Stop changing five variables at once

When you adjust SPF, rotate DKIM, change the from-domain, switch ESPs, and modify templates in the same day, you lose the ability to attribute cause. Treat deliverability like an incident: one change, measured impact, rollback option.

Short joke #1: Email reputation is like a credit score: you can ruin it quickly, and disputing it with a keyboard smash does not help.

Fast diagnosis playbook (first/second/third)

This is the “get signal in 30 minutes” path. It won’t solve everything, but it will find the bottleneck fast and prevent you from guessing.

First: determine the failure mode (delivery vs placement vs acceptance)

• Delivery failure: bounces, deferrals, blocks, queue growth, SMTP errors.
• Placement failure: accepted (250 OK) but landing in spam/promotions/quarantine.
• Acceptance but not seen: user-side rules, corporate quarantine, journaling, or routing issues.

Quick test: pick 10 recent messages, collect SMTP transaction logs, and classify. Don’t rely on “user says they didn’t get it.” Users also say “I didn’t change anything.”

Second: check authentication and alignment (SPF/DKIM/DMARC)

• Is the From: domain aligned with SPF (MAIL FROM / Return-Path) or DKIM d= domain?
• Are DKIM signatures present and verifying?
• Does DMARC policy exist, and are you seeing failures?

Most sudden reputation drops correlate with authentication regressions after a vendor switch, DNS change, or template toolchain change.

Third: look at your bounce and complaint profile

• Hard bounces: unknown user, invalid domain. These should be suppressed fast.
• Soft bounces/throttles: rate limiting, “try again later,” reputation tempfails.
• Complaints: users hitting “spam.” If you’re not receiving complaint feedback from your ESP, you still have complaints—you just don’t get the memo.

Fourth: isolate streams and reduce volume

Transactional mail should be protected like a database. If your marketing stream is spiking bounces, cut it off or move it to a separate sending identity. The goal is to stop collateral damage.

Fifth: validate infrastructure identity (rDNS, HELO, TLS)

Many blocks are simply “this looks like malware infrastructure” signals: missing PTR records, generic HELO, or broken TLS. These are easy wins.

How reputation actually works (the parts people forget)

Reputation is multi-dimensional, not a single score

Mailbox providers don’t keep one magic number for you. They track reputation across:

• Domain reputation (the From: domain users see)
• Subdomain reputation (news.example.com vs example.com)
• IP reputation (especially for dedicated IPs)
• URL reputation (where your links go, including redirectors)
• Content and behavioral reputation (templates, subject lines, engagement patterns)
• Recipient-level reputation (how your mail behaves for a specific provider)

So when someone says “our domain is burned,” your first question is: which domain, which stream, which provider, which time window?

Mailbox providers optimize for user outcomes, not sender feelings

The filtering goal is “users aren’t annoyed and aren’t phished.” Your goal is “my business mail is seen.” Those goals overlap only if you behave well. If your list quality degrades, no amount of DNS wizardry can fully compensate.

Authentication is table stakes; alignment is the actual game

SPF and DKIM are authentication mechanisms. DMARC is the policy and reporting layer, and it introduces alignment: the domain visible to users should match the authenticated domain. Many senders “pass SPF” through an ESP bounce domain, yet fail DMARC because the From: domain doesn’t align.

Reputation recovery is like traffic shaping after an outage

If you were rate-limited, you don’t “prove” you’re good by sending more. You prove it by sending consistently, to people who want your mail, with low bounce rates and low complaints. Warm-up is operational discipline, not marketing optimism.

One quote (paraphrased idea): Gene Kim often emphasizes that reliable systems come from disciplined, repeatable practices rather than heroics. That’s deliverability too.

Interesting facts and historical context (the stuff that explains today’s rules)

1. SMTP predates spam. The original mail protocol assumed a friendly network; authentication and abuse controls were bolted on later.
2. SPF and DKIM were born from different pain. SPF was about validating sending IPs; DKIM was about message integrity and domain responsibility.
3. DMARC made “alignment” mainstream. Before DMARC, “pass something” was good enough; DMARC made the visible domain accountable.
4. Reputation systems are a response to scale. When providers started handling billions of messages, manual allowlisting died and statistical filtering took over.
5. Greylisting was once fashionable. Temporary failures to force retries used to deter spam. Today, it mostly punishes poorly-configured senders and fragile MTAs.
6. Image-only emails became a spam trope. Spammers used images to dodge keyword filters; providers responded with better OCR and heuristic detection.
7. Shared IPs created “neighbor risk.” The rise of ESPs made shared infrastructure normal, and one bad actor can drag a whole pool down.
8. Major providers increasingly require alignment for bulk senders. Over time, the bar moved from “some auth” to “aligned auth plus sane list practices.”
9. Bounces are a reputation signal, not just a delivery failure. High unknown-user rates look like list harvesting or stale data, and filters react accordingly.

Practical tasks: commands, outputs, decisions (12+)

These are the kinds of checks you can run today. Each task includes: a command, a realistic example output, what it means, and the decision you make.

Task 1: Check if the mail queue is exploding (Postfix)

cr0x@server:~$ mailq | tail -n 20
-- 2150 Kbytes in 124 Requests.
AB12CD34EF     2190 Thu Jan  4 10:11:12  sender@example.com
                                         (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later (in reply to end of DATA command))
                                         user@gmail.com

Meaning: Lots of deferred mail, with 421 tempfails. That’s usually throttling, reputation, or provider-side rate limiting.

Decision: Stop bulk sends, implement rate limiting, and focus on reputation/authentication before the queue becomes your new monitoring system.

Task 2: Inspect recent SMTP status codes for patterns

cr0x@server:~$ sudo grep -E "status=(bounced|deferred)" /var/log/mail.log | tail -n 15
Jan  4 10:11:12 mx1 postfix/smtp[22107]: AB12CD34EF: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.200.26]:25, delay=12, delays=0.2/0/2/9.8, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later)
Jan  4 10:11:18 mx1 postfix/smtp[22111]: CD34EF56GH: to=<user@outlook.com>, relay=outlook-com.mail.protection.outlook.com[52.101.68.9]:25, delay=3.2, delays=0.1/0/0.7/2.4, dsn=5.7.1, status=bounced (host outlook-com.mail.protection.outlook.com[52.101.68.9] said: 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.)

Meaning: Gmail is tempfailing; Microsoft is hard-blocking with a 5.7.1 and an IP-based refusal.

Decision: Separate remediation by provider. For Microsoft, you need IP/domain reputation improvements and likely delisting workflows; for Gmail, reduce volume and fix auth/list hygiene.

Task 3: Verify your outbound IP address (what the world sees)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Meaning: This is the public IP mailbox providers associate with your SMTP connections.

Decision: Use this IP for PTR checks, blocklist checks (internally or via your provider portal), and any escalations with your ISP/ESP.

Task 4: Confirm reverse DNS (PTR) exists and matches your mail identity

cr0x@server:~$ dig +short -x 203.0.113.10
mx1.mail.example.com.

Meaning: PTR exists. Next, ensure forward-confirmed reverse DNS (FCrDNS): the hostname resolves back to the same IP.

Decision: If PTR is missing or generic (like a cloud instance name), fix it with your ISP/cloud provider. Missing PTR is a fast track to “suspicious host” scoring.

Task 5: Verify forward DNS for the PTR hostname

cr0x@server:~$ dig +short mx1.mail.example.com A
203.0.113.10

Meaning: FCrDNS passes. Good.

Decision: If it doesn’t match, fix DNS so PTR and A records are consistent.

Task 6: Check HELO/EHLO name your MTA presents

cr0x@server:~$ sudo postconf -n | grep -E "myhostname|smtpd_banner|smtp_helo_name"
myhostname = mx1.mail.example.com
smtp_helo_name = mx1.mail.example.com
smtpd_banner = $myhostname ESMTP

Meaning: HELO matches a real, resolvable hostname. That reduces “botnet-y” vibes.

Decision: If you see “localhost” or a random cloud hostname, fix it. It matters more than people want to believe.

Task 7: Validate SPF record exists and isn’t a hand grenade

cr0x@server:~$ dig +short TXT example.com | sed -n '1,5p'
"v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Meaning: SPF authorizes your IP and Microsoft 365, and ends with -all (hard fail). That’s fine if it’s accurate.

Decision: If SPF is missing or ends with ~all while you’re trying to enforce DMARC, tighten it. If it includes too many vendors you no longer use, remove them.

Task 8: Check SPF DNS lookup count (the silent failure)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null 2>&1 || true
cr0x@server:~$ spfquery -ip 203.0.113.10 -sender bounce@example.com -helo mx1.mail.example.com -debug | tail -n 8
policy result: pass
mechanism: ip4:203.0.113.10
explanation: (none)
received-spf: pass (example.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender)

Meaning: SPF evaluates to pass for this sending IP and envelope sender.

Decision: If you see permerror or “too many DNS lookups,” simplify SPF (flatten includes, remove old services). SPF permerror often becomes “treat as fail” in practice.

Task 9: Confirm DKIM public key is published for the selector you’re using

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtY..."

Meaning: The key exists in DNS. Next, ensure your outbound mail is actually signing with that selector and that signatures verify.

Decision: If the record is missing, publish it. If you rotated keys, ensure old selectors remain until all sending systems stop using them.

Task 10: Verify DMARC record and policy

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; fo=1"

Meaning: DMARC exists, with strict alignment for SPF and DKIM. That’s a strong stance.

Decision: If you’re failing alignment due to vendor tooling, either fix the tooling or relax alignment temporarily. Strict alignment while misconfigured is self-sabotage dressed as security.

Task 11: Inspect a real message’s Authentication-Results (from headers)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|From:" -n sample.eml | head -n 30
12:From: "Example Support" <support@example.com>
45:DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed;
88:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@bounce.example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@bounce.example.com;
       dkim=pass header.i=@example.com header.s=s1;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Meaning: SPF and DKIM pass individually, but DMARC fails. Why? SPF is authenticating bounce.example.com (the envelope domain), which is not aligned with example.com. DKIM passes and is aligned (d=example.com), so DMARC should pass—unless the DKIM signature didn’t cover the From header correctly, or the provider saw a different signature result than your captured header.

Decision: Re-capture from the recipient mailbox with full headers, confirm DKIM alignment, and ensure no intermediate system modifies the message (footers, rewriters) after signing. If you have an M365 connector or a gateway adding disclaimers, it can break DKIM.

Task 12: Check whether a gateway or disclaimer is breaking DKIM

cr0x@server:~$ sudo grep -R "disclaimer\|footer\|append" /etc/postfix /etc/opendkim /etc/mail 2>/dev/null | head
/etc/opendkim.conf:# OversignHeaders From

Meaning: Not much found locally. That hints the modification might be happening upstream (e.g., corporate gateway, ESP link tracker, or downstream security appliance).

Decision: Trace the mail path. If anything modifies body/headers after DKIM signing, fix ordering (sign last) or configure “oversigning” appropriately. Or move modifications to pre-sign stage.

Task 13: Measure bounce rate by reason (log sampling)

cr0x@server:~$ sudo awk '/status=bounced/ {print $0}' /var/log/mail.log | tail -n 500 | \
awk -F'said: ' '{print $2}' | sed 's/[()]//g' | cut -c1-80 | sort | uniq -c | sort -nr | head
  88 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.
  41 550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown
  19 554 5.7.1 Message rejected due to content restrictions

Meaning: The top error is a reputation/IP block at Microsoft, not a content problem. Second is unknown users (list hygiene). Third is content-based rejection.

Decision: Prioritize: (1) reputation remediation with Microsoft, (2) suppress unknown users immediately, (3) review content and URLs only after you stop bleeding.

Task 14: Verify TLS support on outbound (signals legitimacy)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.mail.example.com
Verification: OK

Meaning: STARTTLS works and the certificate validates. This helps with some provider scoring and prevents downgrade weirdness.

Decision: If TLS fails, fix it. A surprising amount of “we look sketchy” comes from broken TLS and mismatched names.

Task 15: Confirm you’re not an open relay (yes, still happens)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_recipient_restrictions|mynetworks|smtpd_client_restrictions"
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/8
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Meaning: You reject unauthenticated relay attempts to non-local domains. Good.

Decision: If you see permit rules before reject_unauth_destination or overly-broad mynetworks, fix now. An open relay will torch your reputation faster than you can say “incident review.”

Task 16: Rate-limit outbound to reduce tempfails and throttles

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf default_destination_rate_delay smtp_destination_concurrency_limit
default_destination_rate_delay = 1s
smtp_destination_concurrency_limit = 5

Meaning: You’re slowing down deliveries per destination, which reduces provider throttling and avoids spiky behavior.

Decision: Keep it conservative during recovery. If transactional latency becomes unacceptable, carve out a dedicated stream (separate IP/subdomain) rather than turning the dial to 11.

Three corporate mini-stories (anonymized, plausible, and painfully familiar)

Mini-story 1: The incident caused by a wrong assumption

They migrated from one ESP to another over a weekend. The project plan was clean: update SPF to include the new provider, publish new DKIM keys, flip the sending API, done. Monday morning, password reset emails started disappearing. Not bouncing. Just… not arriving.

The wrong assumption was that “SPF pass is deliverability.” Their new ESP used a different return-path domain for bounces, and while SPF passed for that bounce domain, DMARC alignment failed for the visible From domain. In their old ESP, DKIM was aligned and stable. In the new setup, a downstream security gateway appended a footer after the ESP signed, breaking DKIM on arrival.

So users saw “support@example.com,” but neither SPF-aligned nor DKIM survived in a way that satisfied DMARC. Some providers quarantined; others silently spam-foldered. The team chased templates and subject lines because that’s what marketing people can change quickly. Meanwhile, the actual fix was: change the gateway behavior (no post-sign modifications), sign at the last hop, and validate alignment with real headers from recipient inboxes.

The postmortem action item that mattered: every mail path change required a test that asserts DMARC pass with alignment for each major provider, not just “message accepted by remote.” They started treating mail as production traffic instead of a magical service that “just works.”

Mini-story 2: The optimization that backfired

A growth team wanted faster campaign delivery. They were convinced their MTA was “too slow,” because send times stretched into hours. An engineer increased concurrency limits and removed rate delays. Messages flew out like confetti.

For about 30 minutes, it looked great. Then the deferrals started: 421 tempfails, “try again later,” and then outright blocks from a major provider. The queue ballooned. Retry storms kicked in. The mail system spent the next day hammering the same providers, repeatedly proving it could not behave politely.

In the incident review, the optimization was reclassified as “aggressive traffic shaping in the wrong direction.” Providers weren’t rejecting because the content was suddenly worse; they were rejecting because the sender’s behavior looked like a botnet: spiky, relentless, and oblivious to backpressure.

Fixes were boring: lower concurrency, implement destination-specific rate limits, and stagger campaigns. But the real correction was organizational: stop treating deliverability like bandwidth. Email is not a bulk data transfer protocol; it’s a trust protocol with SMTP as the transport.

Mini-story 3: The boring but correct practice that saved the day

A mid-sized SaaS company separated transactional and marketing mail years ago. Not because of a crisis—because one SRE insisted “blast radius is a thing.” Transactional mail went out from mail.example.com on a small dedicated IP pool, with strict DMARC and a locked-down template pipeline. Marketing went from news.example.com through an ESP shared pool.

One quarter, marketing acquired a partner list (opt-in… allegedly). Complaint rates went up. The ESP pool started to wobble. Some domains throttled. Marketing deliverability dipped. Annoying, but survivable.

The important part: password resets, invoices, and alerting emails kept landing. Transactional stream metrics stayed clean: low bounces, stable volume, consistent recipients. Providers continued to trust it because it behaved predictably and users interacted positively with it.

The “saved the day” moment came during a billing cycle. If invoices had spam-foldered, it would have been a revenue incident. They avoided it because someone did the dull architecture work ahead of time: segregation, alignment, and a measured warm-up plan for any changes. Production likes boring.

Short joke #2: If your deliverability plan is “send harder,” congratulations—you’ve reinvented the retry storm, but for marketing.

Common mistakes: symptoms → root cause → fix

1) Symptom: Gmail accepts (250 OK) but users report spam-folder placement

• Root cause: Low engagement and/or list decay; content looks promotional; inconsistent volume spikes; missing alignment signals.
• Fix: Reduce volume, send only to recent engagers, remove inactive recipients, ensure DKIM is aligned, and keep cadence consistent for 2–4 weeks.

2) Symptom: Microsoft bounces with 550 5.7.1 mentioning your IP

• Root cause: IP reputation damage (shared pool neighbor issues or your own bounce/complaint behavior). Sometimes also missing PTR or weak TLS.
• Fix: Confirm PTR/HELO/TLS, reduce rate, fix hygiene, and pursue provider-specific remediation via your sending provider. If on shared IP, push for a different pool or dedicated IP with warm-up.

3) Symptom: DMARC failures spiked right after a DNS or vendor change

• Root cause: Misalignment between From domain and authenticated domains; wrong DKIM selector; gateway modifying messages after signing; SPF permerror due to lookup limits.
• Fix: Validate with real headers, ensure DKIM signs with d= aligned to From, correct SPF, and remove post-sign modifications.

4) Symptom: Sudden increase in “User unknown” hard bounces

• Root cause: Stale list, imported contacts, typo domains, or broken signup validation.
• Fix: Immediate suppression of hard bounces; implement address validation at capture; quarantine old segments; run re-permissioning only to known-engaged users.

5) Symptom: Mail queue grows, and delivery latency for transactional mail becomes minutes/hours

• Root cause: Shared queue between bulk and transactional; provider throttling causing global backlog; too-high retries saturating connections.
• Fix: Separate streams (distinct MTAs or transports), impose per-destination limits, prioritize transactional queues, and temporarily pause bulk.

6) Symptom: Everything “passes” but a specific enterprise recipient never receives mail

• Root cause: Recipient-side quarantine, custom filtering, or your domain/URL is blocked internally; sometimes their gateway rejects silently.
• Fix: Get the recipient’s mail admin to provide logs for message ID and timestamp. Provide your SMTP logs. If needed, change URLs (tracking domains) and ensure consistent identifiers.

7) Symptom: DKIM occasionally fails, not always

• Root cause: Multi-hop modifications; mixed signing keys across servers; template system injecting dynamic whitespace/line wrapping after signing; multiple DKIM signatures and one breaks.
• Fix: Sign at the final hop, standardize signing config, keep canonicalization relaxed/relaxed, and test with full header captures across providers.

8) Symptom: Deliverability is fine until you run a campaign, then everything gets worse

• Root cause: Shared identity between marketing and transactional; volume spikes train filters to distrust your overall stream.
• Fix: Split domains/subdomains, split DKIM selectors, and use separate IPs if feasible. At minimum, separate envelope domains and traffic patterns.

Checklists / step-by-step plan

Phase 0 (today): Stabilize and stop the bleeding

1. Pause bulk. Freeze marketing sends that are not operationally essential.
2. Protect transactional. If you can’t split immediately, at least prioritize transactional mail in your queue and reduce bulk volume to near-zero.
3. Enable strict suppression. Hard bounces suppressed immediately; repeated soft bounces suppressed after a sane threshold.
4. Reduce concurrency and add rate delay. Behave politely; accept backpressure.
5. Pick one control sample. A small, engaged cohort plus a seed list you own across major providers.

Phase 1 (24–72 hours): Diagnose with evidence, not vibes

1. Classify failure mode. Bounce vs accept-but-spam vs accept-and-missing.
2. Pull real headers. Confirm SPF/DKIM/DMARC results as seen by the receiving provider.
3. Check identity basics. PTR, HELO, TLS certificate validity, consistent sending IPs.
4. Quantify bounces. Top SMTP codes and their distribution by provider/domain.
5. Find the inflection point. What changed around the time reputation tanked? DNS, vendor, template pipeline, list acquisition, concurrency settings.

Phase 2 (1–3 weeks): Repair trust with controlled warm-up

1. Segment by engagement. Start with people who recently interacted. If you don’t track engagement, start collecting it now and accept that recovery will take longer.
2. Warm-up gradually. Increase volume slowly, keep cadence consistent, and watch deferrals/complaints like you watch CPU on a database server.
3. Keep content stable. Don’t A/B test your way through a reputation incident.
4. Stabilize URLs. Avoid rotating link shorteners or domains during recovery. Suspicious redirect chains are not your friend.
5. Separate streams permanently. Transactional vs marketing, and ideally product notifications as a third stream.

Phase 3 (ongoing): Prevent the next tanking

1. Deliverability SLOs. Track bounce rate, deferral rate, complaint proxies, and inbox placement indicators by provider.
2. Change management. DNS and mail pipeline changes need testing and rollback, like any production config.
3. List governance. Define allowed sources of email addresses. No “partner list” without quality gates and suppression rules.
4. Incident drills. Practice the fast diagnosis playbook quarterly. Your future self will be less angry.

FAQ

1) How long does it take to recover sender reputation?

Days to weeks, depending on how badly you hurt it and whether you fix the underlying behavior. Authentication fixes can help immediately, but engagement/list quality improvements take time to show.

2) Should we switch ESPs to fix deliverability?

Only if your current provider can’t give you control or visibility (or you’re stuck on a poisoned shared pool). Switching without fixing list hygiene and authentication just moves the problem and adds migration risk.

3) Does a dedicated IP solve reputation problems?

It removes neighbor risk, not your own risk. If your list is bad, a dedicated IP gives you a private place to burn reputation. You still need warm-up and hygiene.

4) Should we set DMARC to p=reject to prove legitimacy?

Not during a configuration mess. Enforce DMARC when you know your legitimate senders pass alignment. Otherwise you’ll reject your own mail and call it “security.”

5) Why do we see 421 tempfails instead of hard bounces?

Providers often throttle rather than block immediately, especially when they think you might be legitimate but currently risky. Treat it as backpressure and reduce rate; don’t hammer harder.

6) What’s the single most common cause of “it suddenly got worse”?

Untracked changes: DNS updates, ESP routing changes, or gateways that start rewriting messages and breaking DKIM. The second is list acquisition/imports that spike unknown users and complaints.

7) Can link tracking hurt deliverability?

Yes. Shared tracking domains can inherit reputation problems, redirect chains look phishy, and mismatched domains reduce trust. Keep tracking domains stable and aligned with your brand, and avoid sketchy shorteners.

8) Why does transactional mail suffer when marketing runs a campaign?

Because you tied them together: same From domain, same IP, same DKIM identity, same queues. Split streams so one team can’t accidentally DDoS your trust relationship with providers.

9) Our emails are “accepted.” Why do users still not see them?

Acceptance is not inbox placement. Mail can be accepted and then filtered into spam, quarantined by corporate tooling, or routed into a different folder by user rules. You need header evidence and recipient-side logs to differentiate.

10) What metrics should we alert on?

Queue size growth, deferral rate by provider, hard bounce rate, unknown user rate, and authentication failure rates (DMARC aggregate reports help). Alert on trend changes, not just absolute thresholds.

Next steps you can execute this week

1. Freeze bulk sending for 48 hours while you collect evidence: SMTP codes by provider, queue behavior, and real headers from recipients.
2. Confirm identity correctness: PTR/FCrDNS, HELO, TLS, stable outbound IPs. Fix the cheap signals first.
3. Make DMARC pass with alignment for your primary From domain. Validate with captured headers from Gmail and Microsoft recipients.
4. Implement hard suppression immediately and quarantine questionable segments. Unknown-user bounces are a reputation tax you pay with interest.
5. Split transactional and marketing streams (subdomains and DKIM selectors at minimum). Treat it like blast-radius control.
6. Warm up deliberately: consistent daily volume, engaged recipients first, slow ramps, and careful monitoring of deferrals and complaints.

If you do only one thing: stop volume spikes and stop sending to people who didn’t ask for it. Authentication gets you in the building; behavior decides whether you get to stay.