Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Confirm the MailGuard product and outbound route
This guide addresses MailGuard at mailguard.com.au and its outbound email-filtering service. Confirm that this is the provider and product in the account or contract before applying any instructions to a system labelled Mailguard. Record whether the organization uses MailGuard for inbound filtering only, outbound delivery as well, or a Microsoft 365 or hybrid arrangement. Its Microsoft 365 guidance treats inbound and outbound configuration as separate work. MailGuard Microsoft 365 routing guidance.
Identify the source mail system, connector, domain, intended From address and application or mailbox workflow. Draw the route in order, including any gateway that changes message content or adds a signature. Assign ownership for the source mail system, MailGuard account and DNS. Preserve current records and connectors before changing them, and identify the person who can pause the transition if mail queues or bounces increase.
An inbound MX pointing at MailGuard does not establish that outbound mail traverses it. Verify the real outbound connector and logs. Do not make an authentication change on the assumption that all traffic follows the same path, especially where applications, hybrid servers or emergency routes can bypass the main connector.
Authorize the actual sending infrastructure
MailGuard's public SPF guidance identifies include:customer.mailguard.com.au as its authorization mechanism. Apply it only after confirming the relevant outbound service and current tenant instructions. Merge the required authorization into the existing SPF policy at the evaluated name, preserving other legitimate senders. Do not replace a multi-provider policy with the short example from a blog. MailGuard SPF guidance.
SPF checks the SMTP envelope identity, not simply the visible From address. Inspect the actual Return-Path before deciding which domain's SPF result matters. Keep a single SPF policy at that name and calculate the total DNS-lookup cost, including nested includes. An SPF fail or softfail is an authentication result; the receiving system determines handling under its policies. Do not promise that a particular SPF qualifier always produces a bounce or always permits delivery. SPF specification.
For Microsoft 365 outbound service, MailGuard's published guidance describes adding the Microsoft 365 networks through the console's Trust Office 365 Networks setting and then configuring the outbound connector. Treat trust configuration as a reviewed mail-security change using current instructions for the exact tenant. Do not import a broad bypass rule or change inbound filtering simply to make an outbound test succeed. Hybrid deployments need their own route review. MailGuard Microsoft 365 routing guidance.
Obtain and activate the tenant-specific DKIM configuration
MailGuard publicly announced outbound DKIM signing and directs administrators to Configure > MailGuard > Domains, then the domain's menu and DKIM. This establishes that the Australian product offers outbound signing; it does not supply the tenant's public key, selector or activation state. MailGuard outbound DKIM announcement.
The linked detailed setup article currently leads to a console login in this research environment. Its signed-in instructions were not inspected. Obtain the current configuration from the authorized administrator or provider before publishing records. The exact record type, owner name, value, validation sequence and activation procedure remain a setup hold. Do not create a guessed selector or reuse a public key from another account. MailGuard DKIM setup endpoint, login required.
Create a worksheet with the issued selector, signing domain, DNS record type and value, existing answer and responsible publisher. Confirm what component will sign and whether another system already signs earlier in the path. Publish the current issued records, verify the public DNS answer and complete the documented activation step. Keep any existing signing path until the new one has been tested and the migration plan permits retirement.
The reviewed public material does not establish a universal customer-configurable envelope-domain feature. Mark any need for a custom Return-Path as a question for the exact product and tenant. Do not infer that outbound DKIM support also means the gateway can rewrite the envelope to an arbitrary customer domain.
Verify alignment at an external receiver
DMARC compares the visible From domain with successful SPF and DKIM identities. One aligned passing path is sufficient for DMARC, but a shared provider-domain signature alone does not authenticate the customer's From domain for that purpose. Strict alignment requires an exact domain match; relaxed alignment permits the specified organizational relationship. Inspect all DKIM signatures rather than stopping at the first pass. DKIM and DMARC.
Original acceptance worksheet, not an executed test: send harmless content to controlled external recipients from each changed mailbox, application and hybrid route. Record the time, source system, connector and message identifier. Preserve the original received message and create an identity table showing the visible From domain, Return-Path, receiver SPF identity and result, every DKIM d= and s= pair, and the trusted receiver's DMARC result. Identify exactly which successful path supplies alignment.
Correlate the result with MailGuard and source-system logs to establish that the tested message used the intended gateway. If DKIM fails, investigate whether signing was activated, whether DNS answers match the issued selector and whether a later component changed signed content. If the route fails, pause the change and restore only the connector or DNS edits covered by the recovery plan. Avoid weakening domain-wide DMARC or broadly bypassing inbound security controls as a substitute for diagnosis.
No MailGuard tenant, connector, authoritative DNS or received message was tested here. Exact product identity, signed-in DKIM setup and activation instructions, any custom-envelope capability, and live route evidence remain open gates. Independent technical review and human SME approval are required before publication or production acceptance.