How do I resolve email issues with iinet.net.au?
Published 7 May 2025
Updated 9 Oct 2026
15 min read
Summarize with
Updated on 9 Oct 2026: We updated the mailbox setup steps, added missing-mail checks, and corrected the sender authentication guidance.
Resolve email issues with iinet.net.au by first separating the problem into mailbox access or sending problems, delivery failures to iiNet recipients, and authentication failures for a business's sending domain. The fix is different in each case.
Migrated iinet.net.au mailbox issues need The Messaging Company's support. iiNet's iiNet migration note says iiNet decided to stop providing email services in 2023. Transferred mailboxes are now supported by The Messaging Company. Addresses that did not opt in were deleted and cannot be recovered, and new iinet.net.au addresses cannot be created. For sender-side delivery problems, start with the full SMTP response and sending logs before changing DNS or requesting an unblock.
- Sender-side: If your mail to iinet.net.au bounces, identify the exact rejection before asking anyone to unblock or investigate.
- Mailbox-side: If an iiNet user cannot access a transferred address, route the case through The Messaging Company.
- Authentication: If the rejection or delivered headers show an SPF, DKIM, or DMARC problem, fix the relevant sender configuration.
- Reputation: If the error mentions spam, policy, or content, check IP and domain reputation, including blocklist and blacklist signals.
Identify the right support team
For delivery problems, start by identifying who owns the failure. If the recipient is an iinet.net.au mailbox and the bounce is a server-side rejection, read the full reply to distinguish an invalid address, a full mailbox, or a policy rejection. If the user is trying to operate a transferred mailbox, The Messaging Company owns the support path. If the issue is broader connectivity, check iiNet status before changing mail settings. Check email service notices with The Messaging Company separately; iiNet's network status does not establish that transferred mailboxes are working.
Fast routing
- Sending to iiNet: Collect the SMTP reply, sending IP, recipient, timestamp, and full headers where available.
- Using iiNet mail: Confirm that the mailbox transferred, then use The Messaging Company's support route.
- Checking outages: Look for known network or email service issues before rebuilding a working mail client.
- Opening tickets: Send one complete case rather than several partial tickets with missing evidence.
|
|
|
|---|---|---|
Login fails | The Messaging Company | Check password and subscription |
App cannot send | Mailbox user | Verify SMTP authentication and settings |
SMTP 550 | Depends on full reply | Check recipient address, mailbox status, or policy |
Auth fail | Sender | Fix the sending service or DNS configuration |
Spam policy | Sender, then receiver support | Review reputation and content |
Timeouts or 4xx replies | Sender or email provider | Check connection logs and queued retries |
Use the full error text to route the issue.
iiNet Webmail sign-in screen with email address and password fields
Separate mailbox problems from sender delivery failures
First establish whether you are fixing a mailbox that belongs to an iiNet customer or delivery into iiNet mailboxes. Mail client settings, password resets, transfer status, and mailbox billing belong on the user side. SMTP rejections and authentication failures need sending logs; spam filtering also needs a check of the recipient's mailbox settings.
Sending to iinet.net.au
- Recipient: A customer with an iinet.net.au address cannot receive your mail.
- Evidence: You need SMTP response text, headers where available, source IP, and timing.
- Action: Follow the bounce reason, checking sender authentication and reputation for policy rejections.
Using an iiNet mailbox
- Account: The user cannot sign in, send, receive, or reset the password.
- Evidence: You need screenshots, client settings, error text, and transfer status.
- Action: Use The Messaging Company's support path instead of sender postmaster escalation.
When you control the sending domain, send a fresh message through Suped's email test to inspect the delivered headers. Compare them with the failed delivery logs to check authentication or message differences. A successful test to another receiver does not prove iiNet accepted the original message.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Fix mailbox sign-in and mail client settings
Start with The Messaging Company Webmail at webmail.themessagingco.com.au and sign in with the full iinet.net.au email address. If Webmail also fails, check browser autofill, reset the email password, and confirm that the subscription and payment are active. iiNet-funded access ended on 15 September 2024, so subscription problems need The Messaging Company.
For a forgotten email password, select Reset my password in Webmail and use the email address and registered Australian mobile number to receive the SMS verification code. If you cannot use the registered number or it is an overseas number, contact The Messaging Company. Reset the transferred mailbox password through that service, rather than iiNet Toolbox.
If Webmail works but Outlook, Apple Mail, or another mail app does not, check the app's settings, stored password, and network connection. Use the current encrypted settings below rather than relying on old guides listing mail.iinet.net.au. Use the full email address as the username for incoming and outgoing authentication.
|
|
|
|---|---|---|
Incoming IMAP | imap.themessagingco.com.au:993 | SSL/TLS |
Outgoing SMTP | smtp.themessagingco.com.au:465 | SSL/TLS |
SMTP alternative | smtp.themessagingco.com.au:587 | STARTTLS |
Username | Full email address | Required both ways |
Current settings published by The Messaging Company.
If you can receive but cannot send, enable outgoing SMTP authentication and enter the full email address and the appropriate password. Receiving through IMAP does not confirm the SMTP credentials. If sending fails only on hotel Wi-Fi or another network, test on a different connection and use authenticated SMTP on port 465 or 587. Keep encryption enabled and use the matching security setting for the selected port.
Check app-specific passwords
If app-specific passwords are enabled in Webmail, the normal account password only works in Webmail. Open the app selector, choose Settings, then Accounts, and select GENERATE PASSWORD under App-Specific Passwords. Label and generate a password for each mail app, then update both its incoming and outgoing password fields. Enabling this option requires updating every mail app. A repeated password prompt often means the app still has the normal password or an old app-specific password.
The Messaging Company recommends IMAP. If the old account uses POP, back up locally stored mail before removing or replacing it. POP can download messages to one device and remove them from the server, so changing the account without a verified backup can lose mail that Webmail does not contain. If you need to retain POP, use pop.themessagingco.com.au on port 995 with SSL/TLS and the full email address as the username.
For suspicious password-reset or payment messages, use known support contacts and open Webmail directly. iiNet's cyber incident notice describes unauthorised access to its order management system in August 2025. That incident is not evidence that a current email failure is caused by a compromised mailbox.
Fix missing or delayed incoming email
If you can sign in but are not receiving emails, ask someone to send a fresh message and search for it in Webmail first. A message visible there but absent in your mail app points to synchronisation or local settings. A message missing in Webmail needs mailbox checks and the sender's delivery result.
- Spam or junk: Search the Spam folder and all other folders, then mark a legitimate message as not spam if it was misclassified.
- Filters and forwarding: Review Webmail rules that move or delete mail, blocked-sender settings if available, and automatic forwarding. Another device using POP also removes server copies if configured to do so.
- Mailbox quota: Open the Webmail app selector and choose My Account to view storage usage and the plan limit. Back up mail before deleting it, and empty deleted items after checking them or arrange more storage.
- App synchronisation: If Webmail has the message, confirm the app is online, refresh its folders, and check its IMAP settings and password before removing the account.
Ask the sender for the full bounce or delivery log. A 4xx SMTP reply is a temporary failure, so check that the sending server has queued retries. A 5xx reply is a permanent rejection for that attempt and needs the reported cause fixed before resending. A 250 reply after the message data confirms server acceptance, not inbox placement; check mailbox folders and escalate with the Message-ID and timestamp if the message remains missing.
Collect the evidence before escalating
A receiver cannot investigate a report that only says mail is not getting through. The minimum useful packet has enough information for their team to search logs without guessing. Include both the failed event and a recent successful event when available, because comparing timing often exposes throttling, routing changes, or a specific content trigger.
- Source IP: Use the public IP that connected to the receiver, not an internal relay address.
- Recipient: Include the exact affected iinet.net.au address in the private support ticket. Redact it in public posts, since redaction prevents an exact recipient log search.
- Timestamp: Give UTC time and local time with the time zone, because log searches depend on this.
- SMTP reply: Copy the full server response, including enhanced status codes such as 5.7.1.
- Headers: Attach full headers from a delivered comparison copy or the original message where available, and keep the failed delivery log separately.
- Content: Keep the subject, links, campaign name, and template version tied to the event.
Escalation packet templatetext
Recipient: user@iinet.net.au Sender domain: example.com Sending IP: 203.0.113.10 UTC timestamp: 2026-05-27 03:15:42 Local timestamp: 2026-05-27 13:15:42 AEST Subject: Account update SMTP response: 550 5.7.1 Message rejected Message-ID: <sample@example.com> Comparison sample Authentication-Results: spf=pass dkim=pass dmarc=pass Comparison sample headers: attached Failed delivery log: attached Recent changes: new sending IP added on 2026-05-26
Avoid vague tickets
A ticket that only asks for a contact usually stalls. Add the error text, the IP, timestamps, samples, and any analysis strings. If a filter report includes a token such as p=<hash>, include it exactly as shown. Headers from another receiver help diagnose the sender but do not establish how the iiNet receiver evaluated the rejected message.
Authentication checks before a sender escalation
Before escalating a policy or authentication rejection, verify the sending side. Use Suped's domain health check to review SPF and DMARC DNS, then inspect a real message to check the DKIM selector it actually uses. Valid DNS records alone do not establish that a message passed authentication.
Suped's DMARC reporting and email authentication platform ties DMARC monitoring to source identification and fix steps. Use the reported source IPs and authentication results to investigate which sending service or configuration change caused failures. Aggregate reports do not replace the SMTP evidence for a specific bounced message.
Illustrative DNS authentication recordsdns
_dmarc 3600 TXT "v=DMARC1; p=none; rua=mailto:d@example.com" @ 3600 TXT "v=spf1 include:_spf.example.net -all" selector1._domainkey 3600 TXT "v=DKIM1; k=rsa; p=MIIB..."
These records are placeholders. Replace the report mailbox and SPF include with your actual values, and use the complete DKIM public key or CNAME supplied by the sending service. The p=none policy requests monitoring without requesting DMARC quarantine or rejection; it does not repair authentication or guarantee delivery. Only edit records for a domain you control. An iiNet mailbox user cannot change the SPF, DKIM, or DMARC records for iinet.net.au.
What good looks like
- SPF: The connecting IP is authorised by the SPF record for the envelope sender (MAIL FROM) domain, rather than the visible From address.
- DKIM: At least one signature validates using the published key for its signing domain and selector.
- DMARC: SPF or DKIM passes and its authenticated domain meets the visible From domain's matching requirement. Relaxed mode uses the same organisational domain; strict mode requires identical domains.
- Headers: Use the trusted receiving server's Authentication-Results field to check what passed for that message.
Sender IP, SPF, DKIM, and DMARC checks for email delivery to iinet.net.au
When the issue is content or reputation
If SPF, DKIM, and DMARC pass but recipients still reject or junk the mail, the next layer is reputation and content. That includes the sending IP, domain reputation, URLs in the message, complaint history, sending pattern, and whether a filter is reacting to a specific template.
Check Suped's blocklist monitoring for IP and domain listings, then review the message itself. A blocklist (blacklist) listing only explains a rejection when the receiver's response or policy connects it to that failure. A clean result does not rule out content filtering or private receiver reputation data. Check URL redirects and sudden volume changes as well.
Escalation readiness
Check whether support can identify the failed event and compare message samples; these are practical criteria, not provider thresholds.
Weak
Event not identifiable
Only a domain name or complaint, with missing event details.
Usable
Event identifiable
Full SMTP response, source IP, exact recipient, and timestamp.
Strong
Evidence attached
Event details plus delivery logs, message samples, and recent changes.
iinet.net.au delivery troubleshooting flowchart with authentication, reputation, and retesting steps
When the failure appears content-based, test a plain-text message, then the same message with the normal links, then the full template. Compare the results while keeping the sending IP and test volume consistent. If a single URL triggers the failure, include it in the escalation packet, but do not assume every rejection is a blocklist problem.
How to contact the right team
For transferred mailbox problems, call The Messaging Company on 07 3497 3566 or submit a request through the Support Centre referenced in the iiNet migration note. iiNet no longer provides email support. For iiNet internet account or connectivity issues, use the iiNet contact page. For sender-side blocking, ask your sending provider to confirm the failed connection and full SMTP reply. If receiver review is still needed, supply the affected recipient, exact error, source IP, and time range through the email provider's support route.
- The Messaging Company: Use it for mailbox login, password, quota, setup, subscription, and billing issues.
- iiNet support: Use it for internet account questions, service status, and connectivity problems.
- Sender team: Resolve the issue identified by the bounce and supply authentication or reputation evidence for policy rejections.
- Mail platform: Confirm the connecting IP, DKIM selector, envelope sender, and retry behaviour.
What stalls a review
A receiver review slows down when the sender asks for help without the failed recipient, time of failure, source IP, and SMTP response. Include those fields in the first ticket.
- Missing IP: The receiver cannot identify the connection to inspect.
- Missing time: The receiver has no reliable log window.
- Missing sample: The receiver cannot compare content, headers, and filter output.
- Missing auth evidence: Sender DNS records alone do not show whether the failed message passed authentication.
Where Suped fits in the workflow
Suped's DMARC reporting and email authentication platform turns reported authentication data into a workflow organised by sending source. It shows source authentication pass rates and issues that need action, so a team can investigate a failing sender before opening a receiver ticket. Use reports from participating receivers alongside the logs for the affected iiNet delivery; a DMARC report is not a log of every message.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
After a sender-side fix, Suped's product helps track subsequent SPF and DKIM results and blocklist or blacklist signals. Mailbox password resets, subscription changes, and receiving-folder problems still need The Messaging Company or the mailbox user.
Manual workflow
- Reports: You collect DMARC XML, bounces, and headers in separate places.
- Diagnosis: You map sending sources and failures by hand.
- Follow-up: You rely on calendar reminders to confirm the fix.
Suped workflow
- Reports: DMARC authentication results and monitored reputation signals are grouped by domain.
- Diagnosis: Issue detection points to practical fix steps for the reported failures.
- Follow-up: Alerts and summaries help track the results after a configuration change.
Views from the trenches
Best practices
Record the exact SMTP reply, recipient, sending IP, timestamp, and original message sample.
Separate mailbox access issues from inbound blocking before opening provider tickets.
Verify sender SPF, DKIM, and DMARC when a rejection identifies an authentication problem.
Test a fresh message after each DNS or content change, then retain its full headers.
Common pitfalls
Escalating with only a domain name leaves support without the details to find the event.
Asking iiNet to fix a transferred mailbox sends the case to the wrong support team.
Weakening DMARC policy during a rejection leaves authentication faults unresolved.
Treating a content filter issue as an IP issue wastes time in the first review cycle.
Expert tips
Keep UTC and local time together so support teams can find logs across regions quickly.
Include a delivered comparison sample and the failed message to compare their content.
Check recent DNS edits first because SPF and DKIM drift causes sudden receiver failures.
Use ongoing reporting and SMTP logs to detect recurring failures before complaints.
Marketer view
Marketer from Email Geeks says iiNet-related mailbox issues often route through The Messaging Company now, so account support and sender support need different paths.
2024-09-30 - Email Geeks
Marketer view
Marketer from Email Geeks says postmaster responses vary, and a ticket number without logs does not mean the case has enough evidence to move.
2024-09-30 - Email Geeks
Confirm the fix and monitor delivery
After changing mailbox settings, test Webmail and the mail app separately. After a sender-side DNS or content change, send a fresh message to the affected recipient and check the delivery result.
- Retest: Confirm mailbox sign-in, sending, and receiving, or send a fresh message to the affected recipient after a sender-side fix.
- Validate: Inspect the new SMTP response and delivered headers, and check queued retries for temporary failures.
- Escalate: If the failure persists, send one complete ticket with IP, time, recipient, response, sample, and recent changes.
- Monitor: Use Suped's product to track reported authentication failures and reputation signals after sender-side changes.
