When a DMARC report shows no passes from a known mail service

A DMARC report can look alarming when it records zero passing messages from a mail service your organisation genuinely uses. It may show that Google Workspace, Microsoft 365, a CRM, a marketing platform or a ticketing system sent mail on your behalf, yet every message failed DMARC evaluation.

This result does not automatically mean the provider is malicious or that your domain has been hijacked. DMARC checks whether the visible From address aligns with an authenticated SPF or DKIM identity. A legitimate service can therefore send real mail that still fails because its authentication settings, return path or signing domain are not aligned correctly.

The immediate concern is deliverability. Receiving systems may quarantine or reject those messages, while some mailbox providers continue accepting them based on other reputation signals. Australian businesses sending invoices, appointment reminders or customer updates from Sydney, Melbourne or Brisbane can lose important communications without noticing an obvious outage.

DMARC data is especially valuable because it reveals what recipient systems see, rather than what your internal mail platform is configured to do. A careful reading can separate an authentication configuration error from spoofing, forwarding, a third-party platform change or an incorrectly interpreted report.

What “no passes” actually measures

A DMARC pass occurs when either SPF or DKIM passes and aligns with the domain in the visible From header. SPF alignment usually means the envelope sender domain shares an organisational domain with the From address. DKIM alignment means the signing domain in the d= tag aligns with it.

A report showing no passes means that neither route satisfied both authentication and alignment for the messages counted. SPF may have passed for a provider-owned domain but failed alignment, or DKIM may have passed with a signing domain unrelated to your brand. The message can still have been sent by an approved account.

Why a familiar provider can fail

Many services use shared infrastructure. A CRM might deliver mail through its own servers, use a branded return-path only after domain verification, or sign with a generic provider domain. If your From address is billing@example.com but the service signs as provider-mail.com, DMARC alignment may fail even when DKIM itself is valid.

Changes are another common cause. A vendor may rotate outbound IP addresses, alter its DKIM selector, introduce a new sending region or change the format of its bounce domain. An agency managing campaigns may also add a new platform without telling the domain owner, creating a sudden authentication gap.

Read the report fields carefully

Start with the reporting source, date range, message count, source IP and policy result. Aggregate reports can combine thousands of messages, so one row may represent a large campaign while another represents a handful of automated notifications. A single “fail” row should not be treated as proof that every message from the provider failed.

Compare the source IP with the service’s published sending ranges and check the DKIM selector, envelope-from domain and visible From domain. A genuine service with a known IP but no aligned authentication needs configuration work. An unfamiliar IP sending large volumes may indicate spoofing, a compromised account or an unauthorised vendor.

Separate spoofing from a configuration fault

Spoofed mail often fails DMARC because the sender cannot use your domain’s valid SPF or DKIM identity. That is precisely the protection DMARC is designed to provide. If the report shows suspicious infrastructure and low message volumes, the correct outcome may be continued rejection rather than adding the source to SPF.

If the source is legitimate, document the business owner and purpose of the stream before changing DNS. Review your trust score basics when a report coincides with a reputation decline, rising bounces or unexpected complaints. Authentication failure and domain reputation can reinforce each other, but they are separate signals.

Fix SPF and DKIM alignment properly

Ask the mail service to enable custom DKIM signing using a selector under your domain, then publish the required public key in DNS. This is usually more reliable than adding many third-party IP ranges to SPF. SPF has a ten-DNS-lookup limit, and complex records can exceed it as an organisation adds software.

If SPF is needed, configure a custom return-path or bounce domain that aligns with the visible From domain. Keep the record within lookup limits, remove obsolete providers and avoid copying broad mechanisms from old documentation. DNS changes can take time to propagate, so monitor reports after each controlled change.

Treat forwarding and mailing lists as special cases

Forwarding can break SPF because the forwarding server is not authorised in the original domain’s SPF record. DKIM may survive, but only if the message is not altered. Mailing lists sometimes rewrite content or headers, causing DKIM failure and leaving DMARC with no passing path.

For operational mail, prioritise aligned DKIM and test common routes: direct delivery to Gmail or Outlook, forwarding to another mailbox and receipt through a corporate gateway. Australian organisations using Microsoft 365 alongside local accounting, booking or property-management platforms should test each stream separately rather than assuming one provider’s success covers all mail.

Move from observation to enforcement carefully

If your DMARC policy is p=none, failing messages are generally reported but delivered. This is useful while identifying legitimate services. Once known senders pass consistently, consider staged enforcement with p=quarantine, a percentage rollout and separate reporting addresses. A full p=reject policy should follow evidence, not a single report.

Use a domain checking workflow to review SPF, DKIM, DMARC and related DNS records before making changes; the sender score checker can support that investigation. Keep an inventory of every platform that sends mail, including low-volume systems such as payroll, support desks and event registrations.

For Australian senders, authentication supports compliance with the Spam Act 2003 and ACMA expectations around permission, identification and unsubscribe mechanisms, although DMARC itself does not replace those obligations. Good alignment protects brand trust, helps customer messages reach inboxes and makes it harder for criminals to impersonate a business in everyday email traffic.