Why are my emails soft bouncing with Bigpond after implementing DMARC changes?
Published 13 Jul 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified Bigpond bounce codes and added DNS checks and escalation steps for persistent rejections.
If your Bigpond bounce says 558 5.7.1 and IB703, Bigpond is rejecting the message as suspected spam. That response alone does not prove a DMARC policy failure. DMARC still matters because a recent authentication change can expose a Klaviyo alignment problem or coincide with a sending pattern that Bigpond already treats as risky.
Treat this as a delivery incident with an authentication audit attached. Do not turn DMARC off as the first move. Prove whether Klaviyo mail passes DKIM or SPF with an identifier aligned to the visible From domain. Then isolate Bigpond recipients, pause bulk retries, test simpler content, review the sending IPs, and compare bounce rates by campaign.
First steps for a Bigpond bounce spike
A sudden, widespread bounce spike to Bigpond addresses is enough to pause bulk sends to that mailbox group immediately. Keep other domains moving only if their metrics are stable.
- Do this first: Segment Bigpond addresses and stop bulk campaign retries while you investigate.
- Check authentication: Confirm that either DKIM or SPF passes with an identifier aligned to the visible From domain on a live Klaviyo message.
- Check filtering: Compare rejected content with a plain, low-link version sent to controlled Bigpond test mailboxes.
- Check reputation: Review sending IPs, complaint patterns, and blocklist or blacklist signals.
What the Bigpond bounce means
The bounce string matters. An explicit DMARC or authentication error is useful evidence, but receivers also use generic policy responses. Bigpond's IB703 response says the message content was rejected as suspected spam. That wording points to filtering based on the message and its sending context. It does not identify the individual signal or rule out an authentication problem.
Bigpond bounce example
558 5.7.1 Message content rejected due to suspected spam. IB703
The leading 5 in 558 makes this a permanent negative SMTP completion for that delivery attempt. The enhanced status 5.7.1 means delivery was not authorized and the message was refused for a security or policy reason. An email platform can still categorize the event as a soft bounce based on its internal interpretation of the cause, but the receiving server did not issue a temporary 4xx deferral.
|
|
|
|---|---|---|
558 | Permanent rejection for this attempt | Do not resend unchanged |
5.7.1 | Security or policy refusal | Read the response text |
Suspected spam | Filtering decision | Test content and reputation |
IB703 | Suspected spam rejection when paired with this response | Save the full sample |
451 4.7.23 / IB305 | SPF verification deferral when the response says unable to verify SPF policy | Check SPF DNS resolution; allow normal queued retries |
How to read the bounce before changing DNS.
A reported Bigpond IB305 example uses 451 4.7.23 and says the receiver was unable to verify the SPF policy. That is a temporary deferral with a different diagnostic path. Check DNS resolution for the MailFrom domain and its SPF dependencies, then let the sender retry on its normal schedule. Do not apply the IB703 no-retry advice to a queued 4xx response.
Prove authentication first because DMARC changes are the recent event. Once authentication passes with alignment, investigate content, volume, IP reputation, domain reputation, and recipient engagement without repeatedly changing DNS.
Why Klaviyo can still call this a soft bounce
SMTP status and Klaviyo's bounce type answer different questions. Bigpond's 558 response says the server refused that message attempt. Klaviyo's soft-bounce label groups the event by the reason it inferred, such as content, reputation, or a condition that can change before a later campaign.
- SMTP result: Bigpond did not accept the message, and the sending server should not repeat the exact request without intervention.
- Platform category: Check the bounce type, category, and full reason in Klaviyo rather than relying on the word soft alone.
- Retry decision: Do not manually resend the same campaign. Change a relevant variable and use a small controlled test.
- Suppression decision: Klaviyo suppresses addresses after repeated consecutive soft bounces, but an incident-level Bigpond spike warrants earlier temporary exclusion.
This distinction also explains why waiting for ordinary server retries is the wrong recovery plan for IB703. SMTP retry guidance distinguishes temporary 4xx deferrals from permanent 5xx rejections. Diagnose the 5xx response and address its cause before a new send; permanent describes the delivery attempt, not proof that the address is invalid.
How DMARC changes can still be involved
DMARC does not score spam content. DMARC passes when SPF or DKIM passes with an authenticated domain that meets DMARC alignment requirements for the visible From domain. Under the default relaxed mode, the organizational domains must match. Strict SPF or DKIM alignment requires an exact domain match for that mechanism. A new policy can expose legitimate mail streams that were never authenticated with an aligned domain.
DMARC policy failure
- Bounce wording: The response explicitly names DMARC or authentication; generic policy wording needs more evidence.
- Report data: Reports for the affected source show no passing, aligned SPF or DKIM result.
- DNS fix: Correct the branded sending domain records or the aligned identifier.
- Test result: A live message passes DMARC after the authentication fix.
Bigpond spam rejection
- Bounce wording: The response says suspected spam, content rejected, or similar filtering language.
- Report data: DMARC passes in available evidence, but Bigpond still rejects a campaign or sending path.
- Delivery fix: Reduce content variables, control volume, and review sender reputation.
- Test result: A changed message or sending path changes the bounce pattern.
Suped's DMARC monitoring product shows whether reporting receivers saw the Klaviyo stream pass DMARC through an aligned identifier. Investigate failures for the affected source before changing policy; passing results shift attention toward content and reputation.
Diagnostic flow for Bigpond IB703 bounces after DMARC changes.
The common mistake is changing the DMARC policy again before checking the identifiers Bigpond evaluated. Inspect the receiving server's Authentication-Results on an accepted Klaviyo test, preferably delivered to a controlled Bigpond mailbox. Confirm a passing, aligned DKIM or SPF result under the mode in your DMARC record. A pass at another provider is useful evidence, but it does not prove Bigpond saw the same DNS answers or sending path.
Aggregate reports summarize results for reporting receivers and time windows; they are not per-message bounce logs. Bigpond results are available only if that receiver sends reports. Missing Bigpond reports do not prove a pass or a failure, so use the full bounce and sending logs when receiver-specific evidence is unavailable.
Klaviyo checks to run first
Verify the Klaviyo sending setup before editing campaign strategy. Check the active branded sending domain for the correct send type, its DNS verification status, the visible From domain, and the identifiers in a delivered test message. Run the domain through Suped's DMARC checker and then use the domain health checker to review DMARC, SPF, DKIM, and relevant reputation signals in one workflow.
- Check DKIM: Verify the signature and compare its d= domain with the visible From domain under relaxed or strict alignment.
- Check SPF: Verify SPF for the actual MailFrom (Return-Path) domain, then confirm a passing result meets DMARC alignment requirements for the visible From domain.
- Check DMARC: Check for one valid TXT policy at _dmarc.<From-domain>. If none exists there, check the applicable parent policy, including sp= for a subdomain.
- Check the send type: Confirm marketing and transactional mail use the intended active branded sending domains.
- Check evidence: Save an accepted header plus each bounce reason, timestamp, Message-ID, campaign name, and sending IP.
After DNS edits, check authoritative DNS and cached answers against the previous TTL. For an SPF-specific deferral, check for multiple SPF policies, DNS timeouts or SERVFAIL, and SPF errors. SPF evaluation limits allow at most 10 mechanisms or modifiers that cause DNS lookups per evaluation, including nested includes; exceeding the limit produces permerror. Use the records generated for the active Klaviyo sending domain rather than adding an unverified SPF include to the visible From domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If DMARC recently moved to enforcement, compare Bigpond bounces with available aggregate reports for the same period and source. A DMARC failure means neither SPF nor DKIM supplied a passing, aligned identifier; raw SPF and DKIM passes alone are insufficient. A content or reputation rejection can occur while DMARC passes.
Klaviyo campaign report with Bigpond soft bounces and an IB703 reason.
DMARC monitoring record for a new rollout
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use this monitoring policy when starting a DMARC rollout or when evidence shows enforcement is blocking legitimate, misaligned mail that cannot be fixed immediately. Do not lower a passing enforcement policy to address IB703. A p=none policy does not repair content or reputation filtering and reduces protection against spoofing. These examples use a placeholder reporting mailbox; replace it with an address you control or the destination Suped provides for your domain.
How to stabilize Bigpond delivery
Once authentication is clean, handle Bigpond as its own mailbox provider segment. Do not keep resending the unchanged campaign to the same addresses. A repeated 5xx response adds failures without testing a new hypothesis.
Use your Bigpond baseline
There is no universal Bigpond soft-bounce percentage that proves one cause. Compare the campaign with your recent Bigpond baseline, other mailbox providers, and the distribution of exact response codes. Pause the segment when a sudden provider-specific spike or repeated 5xx pattern appears.
Create a Bigpond-only segment covering bigpond.com, bigpond.net.au, and telstra.com addresses, then compare exact bounce codes by domain. Temporarily exclude addresses that just bounced and send a small test after a relevant change. Keep the authenticated sender stable and target recent, consented recipients with recorded clicks or purchases. If the test succeeds, increase volume gradually while measuring that mailbox group separately.
|
|
|
|---|---|---|
Authentication | DMARC result and alignment | Fix identifiers first |
Content | Links, markup, and copy | Send a simple test |
Reputation | IP and domain history | Control volume |
Audience | Consent and recent engagement | Tighten the segment |
Provider | Bigpond response codes | Track separately |
Initial Bigpond incident checks; recovery has no fixed timetable.
What to send in the test
Use a small test message that changes one variable. Keep the authenticated sender and test volume stable when comparing content, then test volume separately.
- Use focused copy: Test simplified HTML or a plain-text version, with a clear subject and no unnecessary attachments. Keep required unsubscribe links.
- Use clean links: Remove unnecessary redirects or broken destinations. If links are suspect, test click tracking as a separate variable.
- Use a small cohort: Send to recent, consented Bigpond engagers before returning to broader campaign volume.
- Use one main change: Keep other variables stable and record the sending IPs, because provider routing can change between tests.
Check blocklist (blacklist) signals for the actual sending IPs and domain as supporting evidence. A clean public result does not exclude a private Bigpond block, and a public listing alone does not prove Bigpond uses that list. Use explicit blacklist wording in the bounce and provider logs to guide escalation.
When to escalate a Bigpond rejection
Escalate when small, authenticated tests still return IB703, or when rejection patterns follow a sending IP rather than a template. A branded sending domain does not give you a dedicated IP. Klaviyo's shared IP guidance explains that other customers share IP reputation, so ask support to compare the affected pool and actual outbound IPs.
- Provide the full SMTP response, including any rejection identifier, affected recipient domains, UTC timestamps, Message-IDs, and campaign or flow IDs.
- Include the sending IPs, visible From domain, MailFrom domain, DKIM d= domain and selector, plus an accepted header and the results of each controlled test.
- Ask Klaviyo to check the affected IP pool, PTR/reverse DNS, forward DNS resolution, and SMTP EHLO identity. The IP owner controls reverse DNS; changing your website DNS does not repair a shared sending IP.
- If the evidence points to Bigpond filtering, ask Klaviyo to coordinate a Telstra postmaster review. Use the contact specified in the actual bounce or a support-confirmed route and request review of the rejection evidence.
Keep the authenticated sender stable during escalation. A new domain or dedicated IP adds a reputation and warming change, so require evidence of an infrastructure problem before considering a move.
When to change DMARC and when to leave it alone
Change DMARC only when the evidence says DMARC is the blocker. If aggregate reports show Klaviyo failing both SPF and DKIM alignment, correct the branded sending domain or visible From domain. If the only evidence is a Bigpond suspected spam response and DMARC passes, keep the policy stable and work on filtering signals.
RFC 9989 quarantine example
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
RFC 9989 replaced RFC 7489 and removed the pct tag because receiving systems applied partial percentages inconsistently. Do not use pct=25 as a dependable rollout control. Review aggregate data under p=none, fix every legitimate source, publish quarantine when failures are understood, and monitor results before moving to reject.
Suped's Hosted DMARC product supports policy changes after initial DNS delegation, without a manual DNS edit for each adjustment. Review authentication reports before tightening enforcement.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For this Bigpond incident, Suped's DMARC reporting product helps compare Klaviyo authentication results by reporting receiver and sending source. Match those results with campaign bounce logs to determine whether authentication work belongs in the recovery plan.
The related guide on why legitimate email can fail DMARC covers cases where SPF and DKIM exist but neither provides a passing identifier aligned to the visible From domain.
Views from the trenches
Best practices
Segment mailbox providers before retrying, so one domain issue does not shape every send.
Keep full bounce strings with message IDs, sending IPs, campaign names, and timestamps.
Use DMARC reports to separate authentication failures from content filtering decisions.
Throttle Bigpond separately after a spike, then rebuild volume with small clean tests.
Common pitfalls
Changing DMARC policy repeatedly can hide the real cause and weaken domain protection.
Engagement tightening alone does not fix content or IP filtering at one mailbox provider.
Treating soft bounces as minor delays can let a provider-specific block keep building.
Assuming Klaviyo meets DMARC alignment requirements leaves the main sending risk untested.
Expert tips
Compare accepted and bounced evidence side by side before editing DNS or templates.
Test a plain low-link campaign to Bigpond so content filtering is easier to investigate.
Check blocklist and blacklist data, but treat listings as clues rather than verdicts.
Use one change per test window so the next Bigpond bounce pattern points to a clear cause.
Marketer view
Marketer from Email Geeks says Bigpond can react strongly to sudden volume shifts, so isolate that mailbox group before changing the whole send plan.
2024-02-14 - Email Geeks
Marketer view
Marketer from Email Geeks says a 558 5.7.1 suspected spam response points more toward filtering than a DMARC rejection.
2024-02-14 - Email Geeks
How to resume Bigpond sending
Resume only after a small test with a passing, aligned authentication result and a relevant fix stops returning the rejection. Keep transactional mail on its intended sending domain, check its delivery separately, and retain the bounce evidence during recovery.
Practical order of operations
- Pause Bigpond: Stop repeating the failure while collecting evidence.
- Prove alignment: Check a live header and aggregate reports for the Klaviyo source.
- Classify the bounce: Use the full SMTP response plus Klaviyo's type and category.
- Test one change: Send a simpler version to a small recent-engager group.
- Resume slowly: Increase Bigpond volume only after IB703 stops recurring.
Frequently asked questions
No. The wording points to suspected spam filtering. Check DMARC because authentication changed, but the response itself does not prove a DMARC policy rejection.
No. A 5xx SMTP response is a permanent rejection for that delivery attempt. Klaviyo can still classify the event as a soft bounce based on its internal bounce category, so review both the raw response and the platform label.
Only when reports show legitimate Klaviyo mail failing DMARC under enforcement and the alignment cannot be fixed immediately. Lowering DMARC will not fix a suspected spam rejection when DMARC already passes.
The change can expose a nonaligned Klaviyo stream or coincide with a reputation, volume, or content issue. Compare the timing with aggregate reports and campaign logs instead of assuming causation.
Request the actual sending IPs and shared-pool status, complete bounce samples, branded sending domain status, authentication evidence, and patterns by campaign or destination. Ask support to investigate persistent Bigpond filtering and coordinate a postmaster review when needed.
Resume only after a small authenticated test with a meaningful change stops returning IB703. Increase volume gradually and continue tracking Bigpond separately.
