Sitemap
Everything on this site
Every page and section, with a one-line note on what you'll find there.
Main
Blazalek.com: Email Deliverability Specialist
I help SaaS and e-commerce teams land in the inbox: email authentication (SPF/DKIM/DMARC), sender reputation, and list hygiene. Deliverability audits, setup, consulting and training.
About Wojtek Blazalek, email deliverability & lifecycle expert
Wojtek Blazalek: 15+ years building, fixing and scaling email. Deliverability, lifecycle marketing, system implementation and platform migrations, plus talks, interviews and publications.
Contact
Get in touch about email deliverability: book a call, send a message, or call directly. You reach the specialist, not a call center.
Urgent help with company email problems
Direct help when messages are rejected, a domain is blacklisted, or an email provider blocks sending. Talk to a specialist, not a call center.
Deliverability questions, answered
The questions I hear most about getting email into the inbox, and how I work. Can't find yours? Book a call.
Privacy notice
How blazalek.com handles analytics, form submissions, bookings, technical logs, language preferences, and your data-protection rights.
Everything on this site
Every page and section, with a one-line note on what you'll find there.
The deliverability guide
Build a production-ready email system
A provider-agnostic guide to building a production-ready email system: the messages your app needs, sending authentication, stream separation, delivery reliability, events, and list hygiene.
Email Types: Transactional vs Marketing
The core distinction between mail a user is waiting for and mail you want them to read, plus the legal framing, the hybrid gray area, and how the split shapes your sending infrastructure.
Which transactional emails does your app need?
Choose a baseline for your app type, then use the catalog to define each transactional email's trigger, purpose, and minimum content.
Deliverability
The four pillars of reaching the inbox: SPF/DKIM/DMARC authentication, sender reputation, bounce & complaint handling, and DNS architecture that protects transactional mail.
List Management
Keeping lists clean: suppression lists, automated hygiene, data retention, and separating transactional from marketing streams so you don't erode sender reputation.
Transactional Email Design
How to build the mail users expect, clear, fast and action-oriented: subject lines, structure, mobile-first layout, OTP/CTA display and error handling.
Email Capture
Collecting addresses responsibly: client- and server-side validation, double opt-in verification, dark-pattern-free form design and proper consent capture.
Marketing Emails
Running a consent-based program: how to collect opt-in, make unsubscribing painless, design valuable messages and keep the list healthy so mail keeps landing.
Compliance
A summary of the key regimes (CAN-SPAM, GDPR, CASL and others): unsubscribe rules, consent records and the technical headers now required of bulk senders.
Sending Reliability
Sending as a distributed-systems problem: idempotency (no duplicates), retry with backoff, error-code handling and queuing decoupled from the request path.
Webhooks & Events
The other half of the email story: event types, signature verification, non-negotiable idempotent processing, and reacting to bounces and complaints to keep suppression accurate.
Case studies
Deliverability work, start to finish
A closer look at how I actually work through real projects, not pitches. Each one walks through the process rather than the private details, across very different kinds of senders.
A newsletter system built from zero, done right · Easy.Tools
I built Easy.Tools a full newsletter and lifecycle sending system from scratch: isolated infrastructure, clean authentication and a monitored model they run themselves.
Scaling toward a million sends a day on a new engine · Youmoney
How I moved a high-volume lending marketplace onto a new event-driven sending engine and rolled it out safely, phase by phase.
Rescuing sender reputation and leaving the playbook behind · Tagvenue
I recovered a busy marketplace's damaged sender reputation and handed over the routines that keep its mail in the inbox.
Email errors and bounce codes
SMTP Error Codes: Email Bounce Diagnosis | Email Errors
Browse 92 reviewed SMTP enhanced status codes, interpret the complete response, and choose the next diagnostic step without treating the leading digit as the whole answer.
SMTP Other or Undefined Codes | Email Errors
Interpret X.0.0 SMTP enhanced status codes when a response gives an outcome class but no more specific subject condition.
SMTP Addressing Errors | Email Errors
Diagnose SMTP addressing status codes for recipient syntax, destination selection, sender-system addresses, and null-MX domains.
SMTP Mailbox Errors | Email Errors
Interpret SMTP mailbox status codes for recipient capacity, mailing-list expansion, permissions, and per-mailbox message limits.
SMTP Mail System Errors | Email Errors
Diagnose SMTP mail-system status codes for storage, receiving capability, system state, priority changes, and message size limits.
SMTP Network and DNS Errors | Email Errors
Interpret SMTP network, DNS, and routing status codes for host reachability, directory services, connection failures, and congestion.
SMTP Delivery Protocol Errors | Email Errors
Diagnose SMTP protocol status codes for command sequence, syntax, arguments, recipient limits, AUTH responses, and transaction timing.
SMTP Message Content Errors | Email Errors
Interpret SMTP content and format status codes for conversion, unavailable content, UTF-8 addresses, replies, and message headers.
SMTP Security and Policy Errors | Email Errors
Diagnose SMTP security, authentication, authorization, reputation, and receiving-policy status codes using the complete provider response.
2.x.x SMTP Success Codes | Email Errors
Understand SMTP enhanced status class 2 success codes: confirm the action they describe, read them with the full event, and avoid mistaking one success line for final inbox placement.
4.x.x SMTP Temporary Failure Codes | Email Errors
Understand SMTP enhanced status class 4 temporary failures: preserve the complete response, identify the condition, and use controlled retries with backoff instead of assuming every deferral will clear.
5.x.x — Permanent failure codes | Email Errors
Understand SMTP enhanced status class 5 permanent failures: inspect the full response, correct the underlying condition, and do not repeat the same send unchanged.
2.0.0 — Other undefined success status
Code 2.0.0 is a general success status: only class 2 is known, with no more specific status. It is not a message rejection.
2.1.5 — Destination address is valid
The specified recipient mailbox address was found to be valid. This is a success confirmation, not a message rejection.
2.3.0 — Other or undefined mail system status
The destination system exists and normally accepts mail, but its condition caused a general DSN to be generated. Because the code begins with 2, it describes success, not a message rejection.
2.3.6 — Requested priority was changed
The message was accepted for relay or delivery, but the requested priority—including a possible implied default—was not retained. The system reported a new priority instead. This is a success status, not a rejection.
SMTP 2.5.0: Other or undefined protocol status
Code 2.5.0 is a general status concerning the protocol needed to pass the message to the next system. It provides no more specific detail, but the leading digit 2 means success, not rejection.
SMTP 2.6.4: Conversion with data loss performed
The message was delivered, but delivery required a conversion in which some data was lost. This is a successful-result warning, not a rejection.
2.6.8 — Required UTF-8 reply not permitted by the SMTP client
A reply needed to show the mailbox name would have to contain a UTF-8 string, but the SMTP client does not permit that form of reply. Code 2.6.8 reports this as a success status, not a rejection.
2.7.0 — Other or undefined security status (success)
The mail system reported a general security-related status that could not be described by a more specific code. The leading digit 2 denotes success, not message rejection.
SMTP 4.0.0: Undefined temporary delivery status
Diagnose SMTP 4.0.0 by retaining the full reply, using bounded retry, and avoiding recipient suppression from this generic temporary result alone.
SMTP 4.1.1: Recipient mailbox temporarily unavailable
Handle SMTP 4.1.1 by checking the exact recipient address, retrying with limits, and withholding suppression until independent permanent evidence appears.
SMTP 4.1.8: Sender system temporarily cannot accept return mail
Diagnose SMTP 4.1.8 by checking the sender address and return-mail configuration, retrying with limits, and not suppressing the recipient.
SMTP 4.2.0: Recipient temporarily unavailable
Preserve the provider reply, retry with limits, and avoid suppression from generic SMTP 4.2.0.
SMTP 4.2.1: Recipient receiving-rate limit
Use spaced, bounded retries for Gmail SMTP 4.2.1 and do not suppress from its temporary receiving-rate condition.
SMTP 4.2.2: Recipient mailbox temporarily over quota
Retry Gmail SMTP 4.2.2 with limits after capacity may change; do not suppress a recipient from this temporary over-quota result.
SMTP 4.2.4: Temporary mailing-list expansion problem
Diagnose SMTP 4.2.4 by retrying in a bounded way, asking the list administrator to inspect expansion, and not suppressing the list address.
SMTP 4.3.0: Undefined temporary mail-system status
Handle SMTP 4.3.0 with bounded retries, preserved logs, and no recipient suppression from a generic temporary mail-system result.
SMTP 4.3.1: Temporarily full mail system
Respond to SMTP 4.3.1 with bounded retry and a storage-capacity investigation by the mail-system administrator, not recipient suppression.
SMTP 4.3.2: Mail system temporarily not accepting messages
Preserve the full provider response for SMTP 4.3.2, use bounded retry, and route recurring host conditions to the receiving administrator.
4.4.0 — Temporary unspecified network or routing failure
Diagnose SMTP 4.4.0: preserve the provider response, retry with bounded backoff, and do not suppress an address from this generic transient network or routing code alone.
4.4.1 — No answer from remote host
Diagnose SMTP 4.4.1: retain the failed connection context, use bounded retries with backoff, and do not suppress an address from this temporary remote-host non-response alone.
4.4.2 — Bad connection
Diagnose SMTP 4.4.2: retain the transaction trace, inspect timeout or connection-quality evidence, retry with bounded backoff, and do not suppress from this temporary connection failure alone.
4.4.3 — Directory server failure
Diagnose SMTP 4.4.3: identify the unavailable directory service, keep DNS assumptions bounded, retry with backoff, and do not suppress a recipient from this temporary routing failure alone.
4.4.5 — Mail system congestion
Diagnose SMTP 4.4.5: identify the congested delivery stage, retry with bounded backoff, avoid adding queue pressure, and do not suppress recipients from this temporary capacity result alone.
4.4.6 — Routing loop detected
Diagnose SMTP 4.4.6: trace the forwarding path, repair the loop, retry only within a bounded window, and do not suppress a recipient from this routing condition alone.
4.5.0 — Other or undefined temporary protocol status
Diagnose SMTP 4.5.0: preserve the complete protocol transaction, identify a more specific condition when evidence supports it, retry with bounded backoff, and do not suppress from this temporary catch-all alone.
4.5.1 — Temporarily invalid protocol command
Diagnose SMTP 4.5.1: preserve command sequence and support evidence, correct the transaction context, then use bounded retries without suppressing recipients from this temporary protocol result alone.
4.5.3 — Too many recipients
Diagnose SMTP 4.5.3: identify unprocessed recipients, split only the remaining batch, retry with bounded backoff, and do not suppress valid addresses from this temporary recipient-count limit alone.
4.5.4 — Temporarily invalid command arguments
Diagnose SMTP 4.5.4: retain the exact command arguments, correct a confirmed range or feature issue, retry with bounded backoff, and do not suppress from this temporary protocol result alone.
SMTP 4.7.0: Other or undefined temporary security status
Diagnose SMTP 4.7.0 from the complete reply, use bounded retries, and do not suppress an address from this temporary security status alone.
SMTP 4.7.1: Delivery not authorized, temporarily refused
Interpret SMTP 4.7.1 as a temporary authorization refusal, collect the full response, retry with limits, and avoid recipient suppression from this code alone.
SMTP 4.7.3: Receiving domain queue quota exceeded
Handle Outlook.com SMTP 4.7.3 as a temporary receiving-domain queue limit: reduce pace, retry with backoff, and do not suppress a recipient from this shared condition.
SMTP 4.7.12: Authentication mechanism transition required
Fix the required SMTP AUTH mechanism transition before a bounded retry; SMTP 4.7.12 is a temporary authentication gate, not a recipient bounce.
SMTP 4.7.15: Priority level is too low
Diagnose SMTP 4.7.15 as a temporary priority condition, verify the receiver's policy, and use bounded retries without suppressing a recipient from this code alone.
SMTP 4.7.16: Message too big for the specified priority
Resolve SMTP 4.7.16 by checking message size and authorized priority policy, then retry with limits; do not suppress a recipient from this temporary condition alone.
SMTP 4.7.24: Temporary SPF policy issue
Diagnose Gmail SMTP 4.7.24 from its suspicious-SPF reply, correct only verified SPF issues, use bounded retries, and do not suppress recipients from this temporary IP-level limit.
SMTP 4.7.26: Gmail unauthenticated-mail rate limit
Resolve Gmail SMTP 4.7.26 by verifying SPF or DKIM authentication, reducing send pace, using bounded retries, and avoiding recipient suppression from this temporary sending condition.
4.7.28 — Gmail sender IP rate limit for unsolicited mail
Diagnose Gmail SMTP 4.7.28: reduce sending rate, retry with backoff, inspect authentication and list hygiene, and do not suppress recipients from this IP-level temporary limit.
SMTP 5.0.0: Unspecified permanent delivery failure
SMTP 5.0.0 supplies no cause beyond a permanent failure. Preserve the full reply, diagnose the condition, and do not retry unchanged.
SMTP 5.1.0: Generic address-status rejection
SMTP 5.1.0 is a permanent, generic address-status result whose exact response decides whether to repair sender or recipient addressing.
SMTP 5.1.1: Recipient mailbox does not exist
SMTP 5.1.1 reports a nonexistent recipient mailbox. Correct the address from a trusted source or apply address-specific hygiene; do not retry unchanged.
SMTP 5.1.2: Recipient address rejected as an invalid destination
SMTP 5.1.2 is permanent for the unchanged destination. Confirm the full response, correct the address from a trusted source, and do not suppress an entire domain.
SMTP 5.1.3: Invalid recipient address syntax
SMTP 5.1.3 rejects invalid destination-address syntax permanently. Correct the exact address from a trusted source; do not retry unchanged.
SMTP 5.1.8: Invalid sender system address
SMTP 5.1.8 means the sender system cannot receive return mail. Correct sender identity and bounce routing before a new attempt; do not retry unchanged.
SMTP 5.1.10: Recipient domain has null MX
SMTP 5.1.10 identifies a recipient domain that declares it accepts no mail. Do not retry unchanged; correct the exact recipient address if a trusted replacement exists.
SMTP 5.2.0: Generic mailbox status, evidenced as DMARC rejection
SMTP 5.2.0 is a generic mailbox-status detail. The accepted Comcast example is a sender-domain DMARC failure: fix authentication, do not retry unchanged or suppress the recipient.
SMTP 5.2.1: Recipient mailbox is disabled
SMTP 5.2.1 is permanent for this attempt, but a disabled account can be re-enabled. Stop unchanged retries, inspect the full Gmail response, and revalidate before permanent removal.
SMTP 5.2.2: Recipient mailbox is full
SMTP 5.2.2 reports a full recipient mailbox. Stop unchanged retries, ask the recipient or administrator to restore capacity, and do not automatically suppress the address.
SMTP 5.2.3: Message exceeds the mailbox limit
SMTP 5.2.3 means the message exceeds a limit for one mailbox. Reduce the message or obtain a confirmed limit change; do not retry unchanged or suppress the recipient automatically.
SMTP 5.3.0: Undefined permanent mail-system status
SMTP 5.3.0 is a permanent, unspecified mail-system result. Preserve the response and do not retry the unchanged attempt.
SMTP 5.3.2: System not accepting network messages
SMTP 5.3.2 is a permanent result for the unchanged request: the mailbox host is not accepting network messages. Check the host context before a new attempt.
SMTP 5.3.4 Error: Message Size Limit
SMTP 5.3.4 means the message exceeds a permanent system size limit. Reduce the message or headers before sending again; do not retry it unchanged.
SMTP 5.4.0: Other or undefined permanent routing status
A documented 554 5.4.0 response stopped delivery after too many hops. Fix the routing loop before a new send; do not suppress the recipient from this code alone.
SMTP 5.4.1: Destination Domain Rejection
SMTP 5.4.1 is an observed permanent destination-side rejection. Check the full provider response and recipient policy; do not retry unchanged.
SMTP 5.4.3: Directory server failure
SMTP 5.4.3 is a permanent result in the current context: forwarding could not use a directory server. Verify the directory path before a new send.
SMTP 5.4.6: Titan Email quota exceeded
Documented Titan Email 5.4.6 replies concern mailbox or domain quotas. Do not retry unchanged or suppress an address solely from this provider-specific quota result.
SMTP 5.4.7: Titan recipient-domain quota exceeded
Documented Titan Email 5.4.7 replies report a recipient-domain hourly or daily inbound quota. Treat the unchanged attempt as failed, not the address as invalid.
SMTP 5.5.0: Other or undefined permanent protocol status
A permanent problem occurred with the protocol needed to pass the message to the next system, but no more specific code described it adequately. Do not retry the unchanged send.
SMTP 5.5.1: Invalid protocol command
A mail system permanently rejected a protocol command because it was issued out of sequence or was unsupported. Do not retry the same unchanged attempt.
SMTP 5.5.2 Error: Protocol Command Syntax
SMTP 5.5.2 means a mail-transaction command could not be interpreted because its syntax was wrong or the command was unrecognized. Inspect the exact command and trace, correct the confirmed cause, and do not retry unchanged.
SMTP 5.5.4: Invalid command arguments
A mail system permanently rejected a valid protocol command because its arguments were invalid. Do not retry the same attempt without changing the arguments or conditions that caused the rejection.
SMTP 5.5.6: Authentication exchange line is too long
The server permanently rejected an authentication attempt because the client's response was longer than the buffer available for the selected SASL mechanism. Do not retry the same unchanged attempt.
SMTP 5.6.3: Required conversion is not supported
The message failed permanently because forwarding it required a content conversion that a host in the path could not practically perform. Do not retry the same unchanged attempt.
SMTP 5.6.6: Message content is not available
The attempt failed permanently because the message content could not be fetched from a remote system. Do not retry the same unchanged attempt.
SMTP 5.6.7: Non-ASCII address is not permitted for the sender or recipient
A system permanently rejected a MAIL or RCPT command because the sender or recipient address contained non-ASCII characters that were not permitted in that context. Do not retry the same unchanged attempt.
SMTP 5.6.8: Required UTF-8 reply not permitted by the SMTP client
The attempt failed permanently because showing the mailbox name required a reply containing a UTF-8 string, but the SMTP client did not permit that form of reply. Do not retry the same unchanged attempt.
SMTP 5.6.9: Message with a UTF-8 header cannot be transferred
The message was permanently rejected after its data had been transmitted because it could not be transferred with its UTF-8 header to one or more recipients. Do not retry the same unchanged attempt.
SMTP 5.7.0: Other or undefined permanent security status
The message was permanently rejected because of a security-related problem, but the response does not describe it more precisely. Do not retry the unchanged send.
SMTP 5.7.1: Delivery not authorized, message refused
The system permanently refused the message because the sender was not authorized to send to the destination. Per-host or per-recipient filtering may produce this decision. Do not retry the same unchanged attempt.
SMTP 5.7.2: Mailing list expansion prohibited
The system permanently refused the message because the sender was not authorized to send to the intended mailing list. Do not retry the same unchanged attempt.
SMTP 5.7.4: Security features not supported
The message was permanently rejected because it used a security feature that could not be supported on the delivery protocol. Do not retry the same unchanged attempt.
SMTP 5.7.7: Message rejected for duplicate authentication-results headers
The receiving system reports a permanent rejection under the enhanced code 5.7.7 because the message carried more than one copy of the same X-Original-Authentication-Results header. The registry pattern X.7.7 names a message-integrity failure; this catalog's only exact evidence for the concrete class-5 code comes from one relay that treats a duplicated authentication-results header as a sign of corruption or tampering and refuses the message outright.
SMTP 5.7.8: Authentication credentials invalid
Authentication failed because the credentials were invalid or insufficient. Do not retry the same unchanged attempt.
SMTP 5.7.9: Authentication mechanism is too weak
The server permanently refused the AUTH attempt because the selected authentication mechanism was weaker than its policy permits for that user. Do not retry the same unchanged attempt.
SMTP 5.7.10: Encryption needed
The server permanently refused the attempt to use the selected authentication mechanism because it requires an external strong privacy layer. Do not retry the unchanged attempt.
SMTP 5.7.11: Authentication mechanism requires an encrypted connection
The server permanently refused the AUTH attempt because the selected authentication mechanism may be used only over an encrypted SMTP connection. Do not retry the same unchanged attempt.
SMTP 5.7.13: User account disabled
Authentication succeeded, but the account is disabled, so the server permanently refused the attempt. Do not retry the same unchanged attempt.
SMTP 5.7.14: Trust relationship required
The submission server permanently refused the attempt because access to the message content requires a configured trust relationship with a third-party server. Do not retry the same unchanged attempt.
SMTP 5.7.15: Priority level is too low
The receiving SMTP server permanently refused the attempt because the message's specified priority was below the lowest level the server accepts. Do not retry the same unchanged attempt.
SMTP 5.7.16: Message too big for the specified priority
The server permanently rejected the message because it is too big for the specified priority. Do not retry the same attempt unchanged.
SMTP 5.7.17: Mailbox owner has changed
The receiving system permanently rejected the attempt because it determined that the mailbox had not remained continuously owned by the intended recipient since the time specified by RRVS. Do not retry the same attempt unchanged.
SMTP 5.7.18: Domain owner has changed
The receiving system permanently rejected the message and indicated that the owner of the recipient's domain had changed since the time supplied through RRVS. Do not retry the same unchanged attempt.
SMTP 5.7.19: RRVS test cannot be completed
The receiving system permanently rejected the message because it could not complete the RRVS evaluation: the required timestamp had not been recorded. Do not retry the same attempt unchanged.
SMTP 5.7.20: No passing DKIM signature found
The receiving system permanently rejected the message because it contained no DKIM signature that passed verification. Do not retry the same unchanged attempt.
SMTP 5.7.21: No acceptable DKIM signature found
The receiving system permanently rejected the message: at least one DKIM signature passed verification, but none was considered acceptable. Do not retry the attempt unchanged.
SMTP 5.7.22: No valid author-matched DKIM signature found
The receiving system permanently rejected the message: at least one DKIM signature passed verification, but none had an identifier matching an author address in the From field. Do not retry the same unchanged attempt.
SMTP 5.7.23: SPF validation produced a fail result
The receiving system permanently rejected the message because its SPF check produced a fail result contrary to local policy. Do not retry the same unchanged attempt.
SMTP 5.7.24: SPF validation error
SPF evaluation for the arriving message resulted in an error, and the system returned a permanent failure. Do not retry the same attempt unchanged.
SMTP 5.7.25: Reverse DNS validation failed
The receiving system permanently rejected the message because the SMTP client's IP address failed a reverse DNS check required by local policy. Do not retry the same attempt unchanged.
SMTP 5.7.26: Multiple authentication checks failed
The message failed more than one authentication check required by local policy, so the system returned a permanent failure. Do not retry the same attempt unchanged.
SMTP 5.7.27: Sender address has a null MX
The receiving system permanently rejected the message because the associated sender address has a null MX and the receiver rejects mail from such senders—for example, when it could not return a DSN. Do not retry the same attempt unchanged.
SMTP 5.7.29: ARC validation failure
This code may be returned when a message fails ARC validation. It denotes a permanent failure of the current attempt, so do not retry it unchanged.
SMTP 5.7.30: REQUIRETLS support required
The message was received with a REQUIRETLS requirement but could not be forwarded because none of the destination SMTP servers provided that support. Code 5.7.30 denotes a permanent failure of the current attempt.
Deliverability incidents
Email Deliverability Incidents: Diagnose and Recover
Choose the right email-deliverability incident runbook, preserve evidence and recover safely across authentication, reputation, delivery and sending systems.
Email Spam, Junk, and Inbox Placement Troubleshooting
Diagnose why legitimate email lands in spam, junk, or Promotions, or fails at a mailbox provider. Start with the affected provider, identity, and real delivery evidence.
Authentication and DNS Failures
Triage authentication and DNS failures with preserved message evidence, scoped diagnosis, and verified remediation.
Reputation, Blocklists and Warm-up
Triage reputation, blocklist, and warm-up incidents with preserved message evidence, scoped diagnosis, and verified remediation.
SMTP Bounces, Rejections, and Throttling Troubleshooting
Classify SMTP failures before changing a sending stream. Separate temporary deferrals and rate limits from permanent rejections, retain the complete reply, and scope the problem to the recipient service and sending identity.
Email Unsubscribe, Complaint, and Compliance Troubleshooting
Contain unsubscribe, complaint, and consent incidents by preserving recipient-level evidence, protecting suppression state, and separating mailbox-provider requirements from legal obligations.
Transactional Email Outage Troubleshooting
Diagnose missing, delayed, or duplicate password-reset, OTP, registration, and order-confirmation email. Trace one request through provider events before retrying.
ESP Migration and Sending Infrastructure Troubleshooting
An ESP or sending-infrastructure incident can affect the route, IP pool, sending domain, authentication, or receiver response after a migration or reputation change. Establish which sending path handled the affected mail before changing volume, IP allocation, or provider. Use the matching runbook for the exact provider and failure boundary.
Email List Quality and Suppression Troubleshooting
Contain list-quality and suppression failures by protecting recipients, preserving send evidence, separating permanent bounces from temporary delivery states, and testing the effective exclusion path.
Email Monitoring and Postmaster Signal Troubleshooting
Triage email monitoring gaps, Postmaster signals, DMARC reports, and provider alerts without mistaking partial telemetry for proof of delivery or failure.
Security, Spoofing and Account Compromise
Triage security, spoofing and account compromise with preserved message evidence, scoped diagnosis, and verified remediation.
Email Queue, Webhook, and Sending Reliability Troubleshooting
Queue and webhook incidents occur when an accepted event is delayed, repeated, misrouted, or processed unsafely. Separate acknowledgement from completed downstream work, and preserve event identity before replaying, draining, or restarting a route. Use the matching runbook for the exact provider and failure boundary.
Mailbox Provider Incident Troubleshooting
Diagnose Gmail, Outlook.com, Yahoo, AOL, and iCloud incidents from exact provider evidence; do not transfer one provider rule to another.