How to Set Up DMARC, SPF and DKIM Without Breaking Email

Getting to p=reject on your sending domains buys two concrete things. Receivers that honour DMARC will refuse most mail that claims to come from your exact domain, which shuts down a large part of the invoice-redirection fraud that starts with an email from accounts@yourdomain.com.au that you didn't send. Enforcement is not absolute — it depends on the receiving side acting on your policy, and mail can travel paths where that does not happen cleanly — but it removes the easy version of the attack. And your legitimate mail gets treated better by the large mailbox providers, because authenticated, aligned mail from a domain with an enforcement policy is the mail they most want to deliver. Gmail and Yahoo have both tightened what they expect from bulk senders, and a published DMARC record is now part of the entry price rather than a nice-to-have.

The reason so many Australian businesses sit at p=none for years is that the failure mode of getting it wrong is loud and immediate: your invoices stop arriving, your CRM stops sending, your marketing platform bounces. That risk is real, but it is manageable, and it is almost entirely front-loaded into the discovery phase. What follows is what each record does, the order to do things in, and the specific things that break.

What the three records actually do

SPF is a DNS TXT record listing which IP addresses and services are permitted to send mail using your domain in the envelope sender. The receiving server checks the connecting IP against that list. SPF proves the mail came from an authorised server. It proves nothing about the content, and it breaks the moment mail is forwarded, because the forwarding server is not on your list.

DKIM is a cryptographic signature added to the message headers by the sending platform, verified against a public key you publish in DNS at a selector you nominate. DKIM proves the message was signed by a holder of the private key and that the signed headers and body have not been altered in transit. It survives forwarding, which is why it does most of the real work.

DMARC is the policy layer that ties the other two to the domain your recipient actually sees. This is the part people miss. SPF checks the envelope sender (Return-Path); DKIM checks the signing domain (d=). Neither of those is the From: address in the mail client. DMARC introduces alignment: a message passes DMARC only if it passes SPF or DKIM and the domain that passed matches the visible From: domain. That alignment requirement is the entire security value. Without it, an attacker can pass SPF using their own domain and still display your name in the From: line.

DMARC also tells receiving servers what to do with mail that fails — p=none (do nothing, just report), p=quarantine (junk it) or p=reject (refuse it) — and where to send aggregate reports, via the rua= tag.

What enforcement stops, and what it does not

p=reject is the control for exact-domain spoofing. Where a receiver honours DMARC, mail that displays your registered domain in the From: line but fails authentication and alignment gets refused. Receivers do not all implement DMARC identically, so treat it as substantially reducing the attack rather than eliminating it — but the major providers do act on published policy, and that covers a large share of payment-redirection fraud, fake-CEO wire requests and credential-phishing that borrows your brand to target your own staff.

It does not stop:

• Lookalike domains. yourcompany.com.au under enforcement does nothing about yourcompany-au.com or yourc0mpany.com.au, which the attacker registers and authenticates properly. Domain monitoring and a defensive registration policy are separate work.
• Display-name spoofing. Mail from randomaccount@gmail.com with the display name set to your CFO's name passes DMARC on the Gmail domain. This is handled at the mail gateway with impersonation rules, not in DNS.
• Compromised mailboxes. Mail sent from a real account you own is perfectly authenticated. That is a conditional access, MFA and detection problem.
• Inbound protection. DMARC on your domain protects the world from mail pretending to be you. Whether you enforce DMARC on inbound mail is a separate setting in Exchange Online or your gateway, and it is worth checking that it is actually rejecting rather than silently accepting.

Treating DMARC as a broad anti-phishing control is the mistake that makes it disappointing. It is a narrow control that does one job well. Deciding which controls carry which part of the load, and where the gaps sit, is exactly the kind of judgement call that belongs in a security architecture and monitoring programme rather than in a single DNS change.

The staged path, in order

1. Publish p=none with a reporting address. This changes nothing about delivery. It starts the flow of aggregate XML reports from every major receiver, which is your only reliable inventory of who is sending as your domain.
2. Read the reports for at least a few weeks. You are looking for sending sources you did not know about — the marketing platform someone signed up for, the accounting system, the recruitment tool, the survey service, the legacy on-premises scanner relaying through a printer, the payroll provider. Most organisations find more than they expect.
3. Fix alignment source by source. For each legitimate sender: either add it to SPF and ensure the envelope domain aligns, or configure DKIM signing with your domain. DKIM is the better answer nearly every time.
4. Move to p=quarantine. Optionally with a pct= value to ramp the proportion of failing mail affected. Watch the reports again. This is the stage where anything you missed becomes visible in the junk folder rather than in a bounce.
5. Move to p=reject, and set the same on sp= for subdomains once subdomain senders are accounted for.

The sequence matters more than the speed. Jumping straight to reject on a domain with an unknown sender inventory is how you lose a fortnight of invoices.

The failure modes worth knowing about

The 10-lookup limit in SPF is the most common self-inflicted outage. Every include: in your record consumes lookups, and nested includes count too. Add Microsoft 365, a CRM, a marketing platform and a ticketing system and you can breach the limit without the record looking long. Once you exceed it the result is permerror and SPF fails for all your mail, not just the last sender you added. There is no warning; it just stops working.

Parked domains deserve a specific mention. Businesses accumulate them through rebrands, acquisitions and defensive registrations, and a domain that never sends mail is a free spoofing platform. Queensland Government guidance is explicit that parked and unused domains should carry DMARC protection too. In practice that means an SPF record of v=spf1 -all and a DMARC record at p=reject on every domain you own that does not send mail. There is no rollout risk, because there is no legitimate mail to break.

Reports nobody reads is the quiet failure. Aggregate reports arrive as gzipped XML from dozens of receivers. Pointing rua= at a shared mailbox and never looking is functionally identical to not publishing DMARC at all, because the whole point is the sender inventory. A reporting platform that parses and dashboards them is worth the licence, and the useful ones sit in the low hundreds of dollars a year for a single domain.

The real cost is ownership, not setup

The DNS changes themselves are cheap. The cost is that your sender inventory is now a living asset. Every new SaaS tool that sends email on your behalf — and marketing, HR and finance all buy them without asking IT — needs SPF and DKIM configured before its first send, or it fails at reject and someone concludes "email is broken". Domain acquisitions, platform migrations and tenant changes all move DKIM keys. Someone has to own the review.

Budget for a reporting tool, a documented process for onboarding new senders, and a quarterly check that keys are current and the record has not drifted past the lookup limit. That is the ongoing work, and it is the part that determines whether enforcement holds two years from now.

There is a bonus on the far side. p=quarantine or p=reject is a prerequisite for BIMI, which puts your verified logo next to your mail in supporting clients. It is a marketing benefit rather than a security one, but it is free once you are enforcing.

Start with a look at what you actually publish

Query your own domain's TXT records and your DMARC record at _dmarc.yourdomain.com.au, count the DNS lookups your SPF record triggers, and list every domain your business owns alongside whether it sends mail. If you find no DMARC record, or one at p=none pointing at a mailbox nobody opens, you have your starting point.

If you would rather have the sender inventory done properly, Precision IT will run the discovery across every domain you own, tell you exactly which sending services are unaligned and what each one needs, and give you a staged plan to reject with a date on each step and a clear answer on which failures are safe to ignore. Ask us for an email authentication scope and we will come back with the domain count, the sender list and what enforcement will cost to run.