Why are emails bouncing from Telia and iCloud with a 4.3.2 error?
Published 15 Jun 2025
Updated 15 Oct 2026
14 min read
Summarize with
Updated on 15 Oct 2026: We clarified SMTP refusal stages and safe retry handling, and corrected the DMARC checks for Telia and iCloud delivery issues.
A 4.3.2 error when sending to Telia or iCloud means a mail server on the delivery path is temporarily not accepting network messages. It does not establish that recipient addresses are invalid. Excessive load, maintenance, or an imminent shutdown can cause it. If failures begin during a migration and cluster on the new sending route, investigate new IP reputation, a new envelope sender, changed DKIM signing, SPF or DMARC domain mismatch, different throttling, and any blocklist (blacklist) signal.
The important point is that 4.3.2 starts with 4. That makes this instance a temporary enhanced status code and normally tells the sending system to retry. If queued retries fail until the sending platform's retry window closes, the platform can issue a final failure notification. Check the platform's queue and retry policy for the actual timing.
- Direct answer: A 4.3.2 response says the receiving host is not accepting network messages. The code alone does not prove an address, reputation, or authentication fault.
- First action: Pull raw bounce diagnostics, not open-rate reports, and group them by recipient domain, sending IP, bounce code, campaign, and timestamp.
- Best fix: Allow controlled retries, check whether the failures follow a provider-wide or route-specific pattern, then verify authentication and lower pressure on the affected domains.
What 4.3.2 means
A 4.3.2 response is an enhanced SMTP status code. The first digit, 4, means a persistent transient failure. The middle digit, 3, points to the destination mail system. The final digit, 2, identifies a system that is not accepting network messages. In plain English, the receiver is saying: do not accept this message right now, try again later. The IANA status code registry defines this system-level condition.
The standard examples include excessive load, system maintenance, and an imminent shutdown. A receiver can also use the response while throttling a sending pattern, but the code alone does not reveal that policy decision. Use the full SMTP reply, timing, affected domains, and sending-route comparison to separate a receiver incident from sender-specific treatment.
Treat it as temporary first
Do not suppress every Telia or iCloud recipient after one 4.3.2 event. A 4xx code deserves controlled retries and investigation. Suppress confirmed permanent address failures, and assess persistent recipient failures after repairing the sending route. Repeated provider-wide deferrals do not prove that every affected address is invalid.
- For a temporary code, retry with lower concurrency and watch whether acceptance improves.
- If thousands fail at one provider, investigate the sending route and receiver timing before blaming individual addresses.
Illustrative delayed delivery notificationtext
Reporting-MTA: dns; outbound.example.net Final-Recipient: rfc822; subscriber@example.org Action: delayed Status: 4.3.2 Remote-MTA: dns; receiver.example.org Diagnostic-Code: smtp; 421 4.3.2 System not accepting network messages
In this illustrative delivery status notification (DSN), Action: delayed means delivery attempts will continue. Remote-MTA identifies the server that returned the diagnostic; Reporting-MTA identifies the server reporting the delivery attempt. A DSN generated by your sending platform can report a remote refusal, so correlate both fields with the SMTP logs. These fields are defined in RFC 3464.
Why Telia and iCloud react during a migration
When a sender migrates between email platforms, the mailbox provider sees a new pattern even if the brand and recipient list stay the same. The new platform can use different sending IPs, DKIM selectors, bounce domains, tracking domains, MIME structure, and retry behavior. Those changes give receivers a different sending pattern to assess.
If this is mostly affecting Apple mailboxes, compare the symptoms with Apple domain bounces. If Telia fails at the same time, a shared sending change becomes a stronger hypothesis, but first check whether both sets of failures share the same time window and sending route.
Old sending route
- The receiver has recent accepted mail history for the old IPs.
- Return-Path, DKIM, and tracking hostnames are familiar to mailbox filters.
- The provider has already learned the normal sending volume and complaint rate.
New sending route
- New IPs start with little or no receiver-specific history.
- SPF and DKIM can pass on platform domains while DMARC fails because neither domain meets the visible From domain's matching requirements.
- A full-volume launch can look abrupt even to domains with engaged recipients.
Email send tracking view with 4.3.2 SMTP bounce diagnostics.
A migration also changes what your team can see. One platform can expose a friendly bounce reason while another exposes the raw SMTP diagnostic. That difference makes it easy to compare open rates and miss the underlying SMTP behavior.
How to prove the cause
Start with raw evidence. Open-rate comparison is weak delivery evidence, especially now that privacy protection and image loading behavior distort opens. A sudden drop in opens tells you something changed, but it does not tell you whether mail was rejected, deferred, accepted into spam, or accepted without an image load.
For a clean live sample, send one controlled message through the same route and inspect it with the Email tester. This gives the team a repeatable sample with headers, authentication results, and content checks instead of relying on aggregate campaign reports. A successful test to this separate mailbox does not establish that Telia or iCloud accepted the same message.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For campaign-level diagnosis, export the bounce rows and keep the original diagnostic text. Save the full three-digit SMTP reply as well as 4.3.2. Use the SMTP logs and queue records for the receiver host, command stage, retry times, and policy wording; a normalized bounce label usually omits that context.
|
|
|
|---|---|---|
4.3.2 | Temporary refusal | Retry slower |
SPF | Sending IP authorization for the envelope sender domain | Check the envelope sender SPF record |
DKIM | Signature verification and the signing domain | Check the selector and signing configuration |
DMARC | SPF or DKIM passed with a qualifying From-domain match | Compare authenticated domains with the From domain |
IP | Sending IP and receiver acceptance history | Compare routes and throttle affected domains |
Use this table to keep the investigation focused on signals that change the fix.
Abridged header evidence to savetext
From: Brand <news@example.com> Return-Path: <bounce@bounce.mail.example.net> DKIM-Signature: ...; d=example.com; s=selector1; ... Authentication-Results: receiver.example.org; spf=pass smtp.mailfrom=bounce.mail.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com Received: from outbound.example.net by receiver.example.org ...
Save the same evidence from the old and new platform. If the old system gets accepted by Telia while the new system gets 4.3.2 during the same period, identify the exact difference, then change one variable at a time. In this example, DMARC passes through DKIM; the example.net envelope sender does not match the example.com From domain.
Check where the SMTP refusal happens
Save the failing SMTP command as well as both reply codes. A connection-stage refusal needs different checks than a refusal after the message body.
|
|
|---|---|
Connection or greeting | Receiver availability and IP-based restrictions; the message headers have not been sent. |
MAIL FROM or RCPT TO, before DATA | Envelope sender, recipient response, and SPF; the receiver has not seen the DKIM signature. |
4xx after the message body | The message was not accepted. Preserve it for controlled retry. |
250 after the message body | The receiver accepted responsibility. This does not guarantee inbox placement. |
Use the SMTP stage to narrow the investigation.
Under RFC 5321, a successful final reply after DATA transfers delivery responsibility. A 250 reply to MAIL FROM or RCPT TO does not confirm message acceptance.
Refusals before DATA happen before the receiver sees the visible From header or DKIM signature. These attempts do not appear in DMARC aggregate reports, as RFC 9989 explains. Missing reports therefore do not prove that no delivery attempts occurred.
Authentication checks for Telia and iCloud bounces
Authentication passing is necessary, but it is not enough. SPF can pass on the bounce domain while the visible From domain has no match. DKIM can pass on a platform domain while your brand domain remains unsigned. DMARC can pass for one stream and fail for another because the new platform uses different identifiers. DMARC needs either SPF or DKIM to pass with a domain that meets the published matching mode for the visible From domain. A DMARC pass does not guarantee inbox placement.
For iCloud bulk mail, also verify permission-based recipients, immediate unsubscribe handling, reverse DNS, stable sending IPs and domains, separate marketing and transactional streams, a consistent From identity, SPF and DKIM authentication, a published DMARC policy, and documented bounce handling. For forwarded mail, Apple also requires ARC headers; bulk messages must follow RFC 5321 and RFC 5322. These are part of Apple's bulk sender requirements. A passing authentication result does not compensate for an abrupt route change or poor list practices.
Suped's product combines DMARC monitoring with the domain health check during a migration. Use blocklist monitoring to check whether the new route has public blocklist (blacklist) listings.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped's product, add the domain and review reported sources for SPF and DKIM results and their match to the visible From domain. Use the issue list to fix legitimate sources that fail DMARC, and compare authentication or blocklist (blacklist) alerts with the sending platform's raw DSNs.
Example record for a domain starting DMARC monitoringtext
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;"
Keep established DMARC enforcement during migration
If the domain already uses p=quarantine or p=reject, keep that policy and configure the new route to pass DMARC before moving production traffic. For a domain starting DMARC, p=none requests monitoring without DMARC enforcement, but receivers still apply their own filtering. Replace the example domain and reporting address with your own settings.
Also check reverse DNS, HELO naming, TLS behavior, and whether the new sending IPs are listed on a major blocklist or blacklist. A receiver rarely discloses every scoring input in the bounce text, so remove clear negative signals before asking the receiver to review the new route.
How to fix repeated 4.3.2 deferrals
The fix is not one DNS edit. Treat it like a controlled recovery: preserve evidence, reduce pressure on the affected receivers, repair authentication, and ramp back up only when acceptance improves.
- Export full DSN rows with recipient domain, remote MTA, diagnostic text, campaign ID, sending IP, timestamp, and final status.
- Group iCloud's icloud.com, me.com, and mac.com domains together for provider-level analysis, while retaining each recipient domain. Keep Telia and unaffected domains separate. Check Apple System Status and Telia service notices for incidents during the same time window.
- Lower hourly volume and connection concurrency for affected domains. Keep the sending platform's controlled queue retries running; do not resend the campaign while those messages are still queued.
- Send controlled samples to test mailboxes through the old and new routes, then compare Return-Path, DKIM domain, SPF result, tracking host, and SMTP reply.
- Fix confirmed SPF or DKIM configuration errors, including missing includes, broken selectors, or duplicate SPF records. Investigate unexpected DMARC sources before authorizing them.
- Resume affected domains in smaller batches and compare acceptance with unique-message deferrals. iCloud has no complaint feedback loop, so recipient-level complaint reports are not available for this recovery check.
Six-step flowchart for diagnosing Telia and iCloud 4.3.2 email bounces.
Domain-level response to temporary deferrals
Set internal response bands using each domain's normal deferral rate and queue age. Calculate the rate as unique messages deferred divided by unique messages attempted in the same window; count repeat attempts separately.
Monitor
Near baseline
Acceptance and queue age remain near their normal levels.
Throttle new sends
Above baseline
Reduce new volume and concurrency while comparing diagnostics.
Pause new sends
Persistent deferrals
Pause new campaigns to the affected domains and continue controlled retries of queued mail.
Let the sending platform apply retry backoff rather than forcing repeated immediate attempts. For Apple-heavy failures, the same recovery logic applies to iCloud troubleshooting: reduce pressure, prove authentication, and avoid permanent suppression decisions while temporary deferrals are still being retried.
When to escalate an iCloud delivery issue
Escalate to iCloud's postmaster team at icloudadmin@apple.com after checking Apple's postmaster guidance, reviewing the mail logs, and testing controlled retries without finding or resolving the cause. Send operational evidence rather than an open-rate screenshot so the receiving team can identify the affected SMTP transactions.
- Include the company name and sending domain.
- List every affected outbound mail-server IP address.
- Paste the complete SMTP errors returned by iCloud mail servers. Preserve any reference ID and explanatory URL contained in the reply.
- Describe when the issue started, including the timezone and representative timestamps.
- Explain the scope, sending stream, retry results, and changes already tested.
Ask for review, not allowlisting
iCloud does not provide a bulk sender allowlist or complaint feedback loop. Keep processing its temporary and permanent SMTP responses, maintain permission-based lists, and give the postmaster team enough evidence to review the refused transactions.
For Telia, preserve the same evidence for the mail administrator or support channel responsible for the actual receiving host. Confirm the recipient domain and remote MX host rather than assuming all Telia-branded services share one mail system. A bare 4.3.2 code omits the receiving host, time, sending IP, and surrounding SMTP reply needed for escalation.
Handling bounces and list hygiene
A 4.3.2 bounce does not prove the address is bad. It proves the message was not accepted through that SMTP path at that time. That distinction matters because large accidental suppressions can remove valid Telia and iCloud subscribers.
Do not confuse no opens with no delivery
One open out of several thousand is a serious signal, but it is not a complete delivery diagnosis. Use SMTP responses, accepted counts, final bounce status, and complaint data before deciding whether the mail never reached the provider or simply failed to generate opens.
Use suppression rules that respect bounce class. Permanent codes like 5.1.1 deserve hard suppression. Temporary 4xx codes deserve retry-aware handling. If a recipient has repeated 4.3.2 failures across many campaigns after the route is repaired, suppressing or resting that recipient becomes reasonable. Keep existing unsubscribes and valid suppressions in place during migration; resolving a temporary deferral is not permission to reactivate them.
Poor handling
- Every 4.3.2 recipient is suppressed as if the address were invalid.
- Low opens are used as the only evidence of blocking.
- The same full volume is resent before authentication and reputation checks finish.
Better handling
- Track 4xx failures separately from permanent address failures.
- Use raw DSNs and receiver hosts to drive diagnosis.
- Resume affected domains gradually after verifying the fixes.
Keep the old platform's accepted-mail evidence for a short overlap period if contracts and data rules allow it. That comparison can show whether the recipient list is healthy while the new route is the variable causing deferrals.
Use Suped alongside SMTP logs
Suped's product is useful when this incident crosses DNS, authentication, and reputation work. It helps separate source authentication, policy status, SPF risk, DKIM coverage, DMARC reporting, and blocklist or blacklist changes instead of treating Telia and iCloud bounces as one vague deliverability problem.
Add the sending domain, confirm every legitimate source, turn on alerts, and use the issue list to repair what changed during the migration. Hosted SPF can help when a confirmed SPF error involves the DNS lookup limit; it does not repair receiver reputation.
That does not replace bounce analysis. You still need the raw DSNs from the sending platform. Suped adds the domain-authentication and monitoring layer that helps explain why the new route looks risky and what to repair before the next send.
Views from the trenches
Best practices
Capture raw DSNs by domain before changing throttles, suppression rules, or DNS records.
Separate Telia and iCloud traffic so one receiver pattern does not hide another issue.
Compare old and new sending headers, including Return-Path, DKIM domain, and HELO name.
Common pitfalls
Using open rates as delivery proof misses deferred mail, blocked images, and privacy opens.
Suppressing every 4.3.2 address treats temporary receiver deferrals as hard failures.
Sending full launch volume from a new route can trigger throttling at strict receivers.
Expert tips
Retry with smaller batches, then watch if Telia accepts mail once concurrency drops again.
Keep existing DMARC enforcement; authenticate the new route before moving production mail.
Track complaints and blocklist or blacklist changes beside authentication failures daily.
Marketer view
Marketer from Email Geeks says bounce messages should be collected before deciding whether Telia is rejecting, deferring, or filtering the mail.
2019-05-08 - Email Geeks
Marketer view
Marketer from Email Geeks says opens are not reliable enough to prove delivery because they miss mail accepted without an image load.
2019-05-08 - Email Geeks
