Aussie Broadband SPF, DKIM and DMARC setup, step by step

Quick answer: If your approved outbound route actually uses Aussie Broadband’s smart host with your own domain, its documented SPF authorization is include:spf1.aussiebroadband.com.au. Merge it into the correct existing SPF policy, not a second record. This addresses a specific relay authorization problem; it does not enable DKIM or prove that a message passes DMARC.

This is a documentation-based guide, not a report of customer account access, DNS changes or delivered-message testing.

Check which service you are using

A broadband connection, a mailbox and an outbound relay are different services. Identify the actual mail route before editing DNS.

Aussie’s SPF change notice, permits domain owners to retain its smart-host route with the documented authorization. It says mainstream provider addresses such as Gmail, Microsoft and Yahoo cannot use that route. Do not try to fix someone else’s domain or impersonate an address you cannot authorize.

The mailbox settings page, says existing Aussie addresses remain supported but new addresses on its two branded domains are no longer offered. Its mailbox login instructions are not proof of eligibility for every custom-domain relay arrangement. Confirm your account’s current relay eligibility with Aussie before changing transport or credentials.

Understand the specific rejection

The published error is:

Recipient address rejected: Message rejected due to: SPF fail - not authorized.

An error mentioning the recipient does not necessarily mean the recipient address is wrong. In this documented case the relay is rejecting a sender authorization problem. Keep the exact response, timestamp and intended sender, and determine which server returned it. Do not infer that every similarly worded error has the same cause.

Before editing, record the application’s configured outgoing server, approved visible From address and actual SMTP envelope sender. SPF normally evaluates the MAIL FROM domain, not the visible From header; HELO is relevant when the reverse path is empty. A sent-message copy may not show the final envelope identity. Use trusted delivered-message evidence where available, or ask the relay administrator to identify the rejected SMTP identity. Do not guess an apex policy from the visible address alone. RFC 7208

Add the SPF authorization safely

You need the domain owner’s approval and access to the authoritative DNS zone. Save the current record, owner name, TTL and legitimate sender inventory before making a change.

1. Identify the exact domain evaluated by this route. An SPF policy at example.com does not automatically cover mail.example.com.
2. Read all TXT records at that owner. There must be only one selected v=spf1 policy. Other unrelated TXT records can remain.
3. Add this provider-documented mechanism to that existing policy:

include:spf1.aussiebroadband.com.au

4. Preserve other legitimate senders, mechanism order and existing qualifiers. Put a new authorization before a terminal all, not after it. Do not blindly replace a managed policy. If the policy uses redirect, have its owner review the composition; redirect is ignored when all is present.
5. Validate syntax and the complete evaluated DNS-dependent term budget, including nested mechanisms and modifiers. The limit is 10 evaluated DNS-dependent terms, not 10 includes. Do not copy today’s resolved IPs as a permanent replacement for the provider-maintained include.
6. Publish the approved change at the correct owner and recheck authoritative DNS and a public resolver after the relevant caching period.

The include is a fixed published authorization, not an account-issued DKIM key or a complete SPF policy. If the owner has no SPF policy, first inventory every legitimate sender and agree its policy and qualifier; do not assume this relay is the only sender. Avoid +all, which would authorize every sender. A qualifier expresses an SPF result, not a guarantee that a recipient will reject or deliver mail. SPF standard

Map the DNS name, not just the text

For the illustrative evaluated identity mail.example.com, enter mail in a DNS panel managing example.com if that panel appends the zone. If mail.example.com is separately delegated, use that child zone’s apex convention instead. Confirm the full resulting name so you do not create mail.example.com.example.com.

Do not add TXT at a name already occupied by a CNAME. Stop and reconcile the existing configuration rather than deleting the alias, a shared dependency or an NS delegation. This guide adds no DKIM records and requires no change to MX, nameservers, DNSSEC, proxy or firewall settings.

Separate network restrictions from SPF

Aussie’s port-blocking guidance, describes outbound port 25 restrictions for residential connections, an exception for its mail server, and separate business/static-IP conditions. It also says external providers’ ports 587 and 465 are not blocked by that rule.

A timeout before an SMTP session is not the same as an explicit SPF rejection during a session. Verify your actual provider’s supported encrypted submission settings. Do not switch to Aussie’s relay merely to avoid a network restriction: that changes the sending route and its authentication responsibility. Do not disable security controls, opt out of CG-NAT or unblock ports as an automatic troubleshooting step. If the authorized configuration cannot connect, resolve the service-specific question with the network and mail administrators.

For existing Aussie-branded mailboxes, the mailbox page recommends mail.aussiebroadband.com.au with SMTP port 465 and SSL/TLS. That is mailbox connection guidance, not a universal custom-domain credential recipe or DKIM setup. Do not send passwords or authentication tokens in a support ticket.

What about Aussie Broadband DKIM and DMARC?

The reviewed smart-host documentation does not establish a customer-domain DKIM record issuance or signing-activation workflow. This is an evidence limit, not proof that all Aussie services lack DKIM. Ask support whether your precise relay service supports aligned signing, where its public records come from, and how activation is confirmed. Do not invent a selector, reuse a provider-owned signature’s DNS record or assume an SPF pass proves DKIM works.

If a supported branded DKIM configuration is supplied separately, require the intended signature to pass and its d= domain to align with the visible From under the current policy, plus trusted receiver dmarc=pass. A DMARC pass achieved only through SPF does not prove that new DKIM configuration works.

DMARC alignment compares authenticated domains with the visible From domain. Relaxed alignment can accept the same Organizational Domain; strict alignment requires an exact match. A child envelope domain therefore does not guarantee strict alignment. Changing your apex SPF cannot fix a message that still authenticates an unrelated provider-owned envelope identity. Current DMARC specification

Preserve existing direct and inherited DMARC policy and approved reporting destinations. Do not weaken enforcement, duplicate records or add a guessed reporting address to make this relay work. An aggregate-report destination in a different Organizational Domain from the policy domain requires the report-generating receiver to check DNS authorization. A destination within the same Organizational Domain is excepted. That protocol authorization does not replace the owner’s approval to share reporting data or its privacy review. RFC 9990, section 4

Verify with a controlled message

Use an authorized recipient you control and non-sensitive test content through the actual application and approved relay. Do not trigger customer invoices, campaigns or other business actions merely to test authentication.

Check the delivered original message, not just the Sent folder. Use Authentication-Results produced inside the receiving service’s known processing boundary, following its documented treatment of externally supplied result headers. Header position or a familiar authserv-id string alone is not proof; ignore attacker-supplied or otherwise untrusted results. RFC 8601

Record the actual SPF identity and result, visible From, any DKIM signatures and their results, and DMARC alignment. Success for this narrow repair means the intended approved path no longer encounters the documented authorization rejection and SPF passes for the expected identity. Branded DMARC success additionally requires aligned authentication and a trusted DMARC pass. DNS visibility alone proves neither. Inbox placement is not guaranteed.

If your real sender is Google Workspace rather than this relay, use the Google Workspace authentication guide for that separate path. It does not replace Aussie’s relay eligibility decision.