SPF, DKIM and DMARC are three DNS-based standards that let receiving mail servers check whether an email claiming to come from your domain was really sent by you. Set up properly, they make it much harder for criminals to send convincing fake invoices in your name, and they are now a condition of reliable delivery to Gmail, Yahoo and Outlook.com. Most organisations can get to full enforcement within a few months without disrupting legitimate mail.
What SPF, DKIM and DMARC actually do
Each standard does a different job, and they work best together.
- SPF (Sender Policy Framework) is a DNS TXT record listing the servers and services allowed to send mail for your domain. A receiver checks the sending server's IP address against that list.
- DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The receiver looks up your public key in DNS and confirms the message was signed by your domain and not altered in transit. DKIM usually survives forwarding, which SPF does not.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together. It requires that SPF or DKIM passes for a domain that matches the visible From address (this is called alignment), tells receivers what to do with mail that fails (none, quarantine or reject), and asks them to send you reports on who is sending as your domain.
Without DMARC, a criminal can often put your exact domain in the From line and land in a customer's inbox. With DMARC at reject, receivers that honour it will refuse that message outright.
Why email authentication matters for invoice fraud
Business email compromise is one of the most costly cyber threats facing Australian organisations. In the ASD Annual Cyber Threat Report 2024-25 factsheet for businesses (opens in a new tab), business email compromise fraud resulting in financial loss accounted for 15 per cent of cybercrime reports from businesses. A common pattern is a fake email, apparently from a supplier or your own accounts team, advising of "new bank details".
DMARC will not stop every variation. It does not help when an attacker registers a lookalike domain or takes over a genuine mailbox, which is why phishing-resistant sign-in matters too (see our article on why MFA alone is no longer enough). What it does is close off direct spoofing of your own domain, which protects your customers and suppliers as much as your own staff.
What Google, Yahoo and Microsoft now require
Since February 2024, Google's email sender guidelines (opens in a new tab) require everyone sending to personal Gmail accounts to use SPF or DKIM, have valid forward and reverse DNS, use TLS and keep spam rates below 0.3 per cent. Senders of more than 5,000 messages a day must use SPF, DKIM and DMARC (a policy of p=none is the minimum), have the From domain aligned with SPF or DKIM, and offer one-click unsubscribe on marketing mail. Yahoo introduced closely matching requirements at the same time.
Microsoft followed for Outlook.com, Hotmail and Live addresses. Its requirements for high-volume senders (opens in a new tab) apply to domains sending more than 5,000 messages a day and took effect on 5 May 2025. Non-compliant mail is rejected with the error "550 5.7.515 Access denied".
If your organisation sends newsletters, receipts or notifications in volume, these rules apply directly. Even if you send far less, the same checks influence whether your everyday mail lands in the inbox or the junk folder.
How to roll out DMARC from p=none to reject safely
Moving straight to reject is the fastest way to block your own invoices and password reset emails. A staged approach avoids that.
- List every system that sends as your domain. Microsoft 365 or Google Workspace, plus your website, CRM, marketing platform, accounting and invoicing software, helpdesk, payroll, booking system and any scanners or line-of-business applications. Ask each department, not just IT.
- Publish SPF and enable DKIM for each sender. In Microsoft 365, DKIM signing for your custom domain has to be turned on; otherwise messages are signed with the onmicrosoft.com domain, which does not align. Most SaaS platforms provide DKIM records to add.
- Publish DMARC at p=none with reporting. For example, v=DMARC1; p=none; rua=mailto:[email protected]. The aggregate reports are XML files, so use a DMARC reporting service to read them.
- Analyse reports for four to eight weeks. Identify legitimate sources that fail alignment and fix them. Anything you do not recognise is either a forgotten system or someone spoofing you.
- Move to p=quarantine. You can use the pct tag to apply it to a portion of failing mail first, then increase it. Keep watching reports.
- Move to p=reject once legitimate mail consistently passes. Keep monitoring, because new services get added all the time.
Common SPF, DKIM and DMARC mistakes
Too many SPF lookups. SPF allows a maximum of 10 DNS lookups. Every include for a third-party service counts, and some include several more of their own. Exceed the limit and SPF returns a permanent error, which can mean failed delivery. Remove services you no longer use, and rely on DKIM for platforms that support it rather than adding yet another include.
More than one SPF record. A domain must have a single SPF record. Two records also produce a permanent error. Merge them into one.
Forgotten third-party senders. The CRM that sends quotes, the invoicing tool that emails statements and the website contact form are the usual casualties when DMARC moves to reject. Reports from the p=none stage are how you find them.
Ignoring subdomains and unused domains. Subdomains inherit your DMARC policy unless an sp tag says otherwise, but each subdomain that sends mail needs its own SPF record. Parked or unused domains are attractive to spoofers; give them an SPF record of v=spf1 -all and a DMARC policy of p=reject.
Stopping at p=none. Monitoring mode satisfies the bulk sender minimum but offers no protection against spoofing. Treat it as a stage, not the destination.
Where ASD guidance fits
The Australian Signals Directorate's guidance on how to combat fake emails (opens in a new tab) recommends hard fail SPF records for all domains and subdomains (including domains that send no mail), DKIM signing of outgoing mail, and DMARC policies that quarantine or reject email failing checks. The Information Security Manual's email guidelines go further and call for DMARC records configured so that failing emails are rejected, covering subdomains as well.
Email authentication sits alongside the Essential Eight rather than inside it, but it is a standard part of a sound email security baseline and is regularly raised in security assessments and supplier questionnaires.
A quick email authentication checklist
- One SPF record per sending domain, under 10 lookups
- DKIM enabled for your mail platform and every third-party sender
- DMARC published with aggregate reporting turned on
- Reports reviewed regularly, with each legitimate sender aligned
- A plan and dates for moving from none to quarantine to reject
- Parked domains locked down with SPF -all and DMARC reject
- A process to add DNS records whenever a new service is introduced
If you would like a hand reviewing your DNS records or planning a DMARC rollout, get in touch with our team.