DMARC p=reject policy that still lets mail slip past - what it means

A DMARC policy of p=reject is widely treated as the finish line for email authentication across Australian organisations, from Sydney financial firms to Brisbane retailers publishing mail under .com.au domains. Many teams expect a reject rule to block every unauthenticated message outright. In reality, p=reject instructs receiving mail servers to drop mail that fails both SPF and DKIM alignment, but it does not patch the underlying authentication gaps. Understanding why some legitimate or spoofed messages still arrive when the policy is set to reject is the key to tightening configuration rather than relying on the policy alone.

The short version is that p=reject is an instruction to receivers, not a fix for misconfigured sending sources. If a sender in your ecosystem is publishing a weak SPF record, or signing mail with a DKIM key that no longer matches the live selector, those messages can still bypass the reject rule under specific conditions. That gap is why so many organisations across Melbourne, Perth, and Adelaide still see spoofed or stray mail landing in inboxes long after they switched on p=reject.

What p=reject actually enforces at the receiver

When a domain publishes a DNS record containing "v=DMARC1; p=reject", receiving mail servers are told to reject any message that fails both SPF alignment and DKIM alignment. The receiver should return a 5.x.x SMTP rejection, drop the message before delivery, and generate a forensic report back to the rua address published in the DMARC record.

In practice, that instruction is honoured unevenly. Some receivers reject outright, while others accept the message after a forwarding chain rewrites the SMTP envelope. Forwarding is a common culprit in Australian workplaces where Outlook rules, hosted Exchange migrations, or third-party archiving services re-send mail through new infrastructure. Each hop can strip the SPF result, leaving DKIM as the only aligned check. If the original DKIM signature survives intact, the message can still pass under p=reject.

Why legitimate mail still slips past a reject policy

Three configuration patterns tend to explain mail arriving despite a published p=reject. The first is partial subdomain coverage. A DMARC record on the organisational apex, such as example.com.au, does not automatically cover mail.sydney.example.com.au. Subdomains inherit the policy by default, but misaligned SPF or DKIM setups on those subdomains produce inconsistent behaviour across major Australian inbox providers.

The second pattern is a relaxed SPF record ending with "+all" or a wide softfail qualifier. Where an operator in Adelaide or Perth has added multiple marketing platforms and HR systems, the SPF record can exceed the ten DNS lookup limit. Those PermErrors are treated as a pass by some receivers, the opposite of what most teams expect from p=reject. Walking through a structured dmarc-guide helps surface these silent passes.

The third pattern is DKIM keys that have rotated out but remain on a forgotten ESP. Mail signed under the retired selector still aligns with the visible From header, so the receiving server accepts it even with p=reject in force. The honest answer is that p=reject is only as strong as the weakest aligned signature floating around your infrastructure.

DKIM alignment gaps that hide behind stale selectors

DKIM alignment is the second leg of the authentication pair, where rotation and forgotten senders create silent gaps. A DKIM signature is generated with a private key stored at the sending platform and verified using the public key published in DNS under a selector. When a business retires one ESP and onboards another, the old public key is often left in place because scheduled reports or archived mail are still signed by the original selector.

Under p=reject, any receiver performing the DKIM check sees a passing aligned signature and delivers the message. The reject policy never gets a chance to evaluate the message because authentication succeeded. Mail administrators working through transitions in Brisbane or Melbourne often find the cleanest fix is a published list of every active selector, refreshed quarterly, with retired selectors removed from DNS entirely. Without that step, p=reject offers a false sense of completeness.

Moving from p=none to a confident reject stance

The standard rollout is p=none, then quarantine, then reject, with weeks of reporting between each step. In Australia, this staged approach also lines up with obligations under the Notifiable Data Breaches scheme, where evidence of attempted spoofing can become a reportable event. Running an extended p=none phase with rua aggregation lets you confirm every legitimate sender is aligned before tightening the policy. Once aggregate reports show near-zero unaligned volume across two billing cycles, moving to quarantine, then reject produces the cleanest cutover. Anything faster risks rejecting mail that should have been delivered.

For organisations in cities like Sydney or Perth that manage multiple brands, each branded domain needs its own DMARC plan rather than a single shared record. A practical ultimate-dmarc-project-guide walkthrough pulls together SPF lookup budgeting, DKIM selector discovery, and rua reporting into a single repeatable process. The result is a p=reject deployment that does what it claims, rather than one that leaves gaps open to domestic scammers mimicking the ATO or major banks.