DMARC p=none and a recent MX change

A DMARC policy of p=none combined with a recent MX record change can look alarming, but the two DNS settings describe different parts of email delivery. DMARC controls how receiving servers assess messages claiming to come from a domain, while MX records identify the servers that accept its incoming mail.

A monitoring-only policy is therefore not proof of a security breach, and a routing change is not proof of spoofing. Together, they justify checking authentication records, mail-provider changes and the actual source of recent messages before altering the domain’s policy.

Why p=none does not mean enforcement

p=none requests visibility rather than automatic enforcement. It tells receiving servers to report messages that fail DMARC alignment without asking those servers to quarantine or reject them. SPF and DKIM still operate, and ordinary spam filters can independently block suspicious mail.

That distinction matters when domain owners receive customer questions about fake invoices or password-reset emails. A p=none policy can expose misconfigured bulk senders, mailing lists and forwarding services, but its reports describe messages received under the domain. It does not directly establish whether the organisation’s outgoing mail account has been compromised. Australian Cyber Security Centre resources on business email compromise likewise treat domain-based authentication as an important layer of defence.

What the MX record actually controls

An MX change redirects inbound mail according to DNS priority and host routing. A lower-numbered preference normally becomes the primary destination, while TTL values determine how long resolvers may cache the old arrangement. During a migration, both the former and new mail hosts may process traffic.

For a Brisbane wholesaler, this could simply reflect a move to a new security gateway or hosted mail platform. It can still affect authentication: SPF authorisations may name the former provider, while DKIM selectors or CNAME records may point to hosts the new operator has not configured correctly. A Melbourne service business switching between mail platforms faces the same alignment risk.

Why organisations change their MX records

Planned provider changes are common as Australian organisations consolidate Microsoft 365 or Google Workspace accounts, introduce additional filtering or add backup routing. Updating MX records can accompany a gateway replacement, service restoration after an outage, or the correction of an incorrect destination. A legitimate operations change can coincide with delivery delays or authentication failures.

Other explanations include preparing a domain for a new brand or reorganising mail infrastructure. The local context is relevant because many Australian workflows still rely on email for purchase orders, payroll changes and delivery instructions, while .com.au and .au domains remain standard business choices. Neither domain suffix nor Australian registry eligibility rules guarantee that a domain’s mail configuration is trustworthy.

Distinguishing migration from compromise

Warning signs include a spike in DMARC failures, messages arriving from an unfamiliar provider, or an unexplained mismatch between the displayed sender and the authenticated domain. If the MX edit happened alongside a registrar account change, unexpected DKIM keys or altered delegation records, the cause could be unauthorised rather than planned.

An MX change can also expose a pre-existing weakness. Suppose mail reaches a new provider, but SPF still authorises only the old one and DKIM is not signed correctly. Sending systems may then fail alignment, while a phishing campaign uses the domain in its display name. Conversely, perfectly aligned DKIM does not make a compromised mailbox legitimate, so investigators must examine domain-level records and account access together.

Checking the domain and supporting evidence

Start with a current snapshot of the domain’s DMARC, SPF, DKIM and MX records, then compare it with the configuration that existed before the change. The DMARC monitoring guide explains how to interpret the policy and related authentication signals. These checks show what DNS currently says, not whether a particular message was malicious. Sender-reputation results can add context, but a newly introduced mail host may simply lack established history.

Next, examine provider tickets, DNS audit logs, message headers and sample DMARC reports, and ask the mail administrator or hosting provider to confirm the routing change. If there is no authorised change, restoring account control, revoking exposed credentials and replacing affected keys becomes urgent. Any subsequent increase in DMARC enforcement should be tested against legitimate senders and forwarding services to avoid interrupting Australian customer, supplier and payroll communication. That evidence separates a planned mail migration from a domain under attack; neither setting can make that distinction on its own.