SPF, DKIM and DMARC Explained for Business Owners

Email is the most impersonated channel in Australian small business. The common fraud is painfully simple: an email arrives that looks like it came from a supplier, says the bank account has changed, and asks the accounts team to update the payment details. The business pays the next invoice to the new account. The real supplier calls a few weeks later to ask why they have not been paid. The money is gone.

Three technical records make this kind of impersonation harder: SPF, DKIM and DMARC. None of them stop every phishing email, and none of them replace trained staff who verify changes to payment details by phone. What they do is reduce the subset of attacks that depend on impersonating your actual domain, and raise the cost of running those attacks at scale.

A Quick Model Of How Email Travels

When your business sends an email, the mail server that transmits it writes your domain into the headers of the message. When another mail server (Gmail, Outlook, a corporate server) receives the message, it has no innate way to know whether the sender is really authorised to send on your behalf. Historically, anybody could put any domain in the From field of a message, and the receiving server would simply deliver it.

SPF, DKIM and DMARC are three separate records that give the receiving server something to check. Each is a DNS record published on the domain being protected.

SPF: The List Of Senders

SPF stands for Sender Policy Framework. It is a short list, published as a TXT record on your domain, of the mail services that are allowed to send on your behalf. Microsoft 365, Google Workspace, Mailchimp, Xero, your SMS gateway if it sends email receipts, your help desk tool, your e-commerce platform and your newsletter tool each have their own entry.

A receiving mail server checks the SPF record and compares the sender's IP address against the list. If the sender is on the list, SPF passes. If it is not, SPF fails. SPF alone does not reject the message; it just produces a pass or fail that other systems can act on.

The common SPF mistake is missing a service. A business adds Microsoft 365 to its SPF and forgets about Mailchimp, which has been sending the monthly newsletter from a different infrastructure. The newsletter starts failing SPF, and some recipients stop seeing it. The fix is to inventory every service that sends email on behalf of the domain and include each one in the SPF record.

The second common mistake is exceeding the SPF lookup limit. SPF has a limit of ten DNS lookups, and businesses with a complex mail stack can hit that limit, at which point the record stops being evaluated correctly. SPF flattening is a workaround some providers offer; a cleaner approach is to prune services that are no longer in use.

DKIM: The Signature

DKIM stands for DomainKeys Identified Mail. When a mail server sends a message, DKIM adds a cryptographic signature to the headers using a private key held by the sending service. The matching public key is published as a DNS record on your domain, under a specific selector name.

The receiving mail server reads the public key, verifies the signature, and confirms that the message has not been altered in transit and that it was signed by a service authorised to use that selector on your domain.

Each sending service has its own selector. Microsoft 365 uses selectors like selector1 and selector2. Google uses a selector you create yourself when turning on DKIM in the Workspace admin. Mailchimp, SendGrid, Xero and the rest each have their own.

The common DKIM mistake is turning on the service but forgetting to publish the DNS record. The service signs the mail, but the receiver cannot verify the signature because the public key is not published. The messages pass through, often with a 'none' DKIM result, and the protection is not actually in place.

DMARC: The Policy

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It ties SPF and DKIM together, through a concept called alignment, and tells receiving mail servers what to do with messages that fail authentication.

A DMARC record has a policy. There are three options.

The 'p=none' policy means do not take any action, just send me reports. This is the correct starting point for most businesses. It gives you visibility of what is being sent in your name without risking legitimate mail.

The 'p=quarantine' policy means put failing messages in the recipient's spam folder. This is the sensible middle step once the reports show that your legitimate mail streams are all passing.

The 'p=reject' policy means refuse the message outright. This is the goal state for a well-maintained domain, because it is the policy that genuinely prevents direct impersonation of your domain.

DMARC also publishes an address that receiving mail servers can send aggregate reports to, under the 'rua' tag. These reports are machine-readable XML and are not useful to a human by themselves. A DMARC monitoring service parses them and gives you a dashboard of who is sending mail in your name, from where, and whether the mail is passing or failing authentication.

Alignment Is The Part Most Businesses Skip

A message can pass SPF or DKIM technically and still fail DMARC if the visible from-domain does not align with the authenticated domain. This is why adding tools casually breaks mail authentication over time. If your marketing platform sends from mail.sendingservice.com but the From header shows yourbusiness.com.au, alignment considerations apply, and the setup needs to be adjusted on the sending service to use your domain where supported.

The Soft-Start Approach

The safe sequence to adopt DMARC is to start at p=none, monitor the reports for four to six weeks, add any legitimate services that are failing authentication to your SPF and DKIM, move to p=quarantine for another month, and then move to p=reject once the reports are clean. Jumping directly to p=reject on a domain with unaudited mail streams will reliably break a newsletter, a payment receipt or an automation that nobody mentioned.

What It Does Not Protect Against

DMARC protects against direct impersonation of the exact domain. It does not protect against lookalike domains, where an attacker registers yourbusiness-accounts.com and sends mail from there. It does not protect against display-name spoofing in some mail clients, where the From field shows a familiar name even though the underlying address is different. It does not protect against a staff mailbox that has been compromised and is being used to send authentic, DMARC-passing mail from the inside.

The remaining defences are human: trained staff, verification of payment changes by phone, and a clear culture that nobody is embarrassed to double-check an unusual request.

A Short Scenario From South-East Queensland

A construction business in south-east Queensland was asked by what appeared to be their steel supplier to update the bank account details on file. The accounts clerk did so. The next invoice, for $87,000, was paid to the new account. It took six weeks and the involvement of two banks to recover a fraction of the funds. The impersonating email had come from a domain one letter different from the real supplier, and the construction business's own domain had no DMARC in place. Separately, their steel supplier's domain had SPF only and no DMARC either, which had been part of why the fraud chain was easy to construct.

The construction business published DMARC on their own domain within a fortnight, moved to p=quarantine within three months, and introduced a phone-callback rule for any payment change. The supplier followed suit after being approached about the incident.

A Second Scenario

A professional firm turned on DMARC at p=reject as the first step, on a Friday afternoon. By Monday they had missed invoices, newsletter signups and automated reminders. A legacy marketing automation tool, a signing platform and a case management system had all been sending mail in their name for years without DKIM. The policy was rolled back, SPF and DKIM were adjusted, and the move to p=reject happened properly a few weeks later.

Who Should Do The Work

Publishing SPF, DKIM and DMARC is a DNS task. Whoever manages your DNS, usually the person or company that holds the registrar or the DNS provider account, is the right person to make the changes. The content of the records should be prepared by someone who understands your mail stack, which may be an internal IT lead, your email migration provider or an IT consultant.

Ask your DNS or IT provider for a plain-English sender inventory before approving any move to a stricter DMARC policy. If they cannot list the senders, you are not ready for p=reject.

Keep A Change Log

DNS records disappear when people tidy up zones they do not fully understand. Keep a change log for authentication records, with the date of each change, the person who made it, and the record state before and after. When mail suddenly starts failing, that log is where troubleshooting starts.

How Business Vault Fits

Business Vault can observe the public DNS of your domain and record whether SPF, DKIM at common selectors, and DMARC are present. It reports a status based on what is published, and marks unknown values honestly where a selector cannot be guessed. The record sits with the domain and the email asset, so when the business reviews email security quarterly, the current state is already written down. Business Vault does not publish DNS records on your behalf.

Email authentication is one of the few areas where a few hours of work on a quiet afternoon produce a meaningful, measurable reduction in a specific class of fraud. The three records are not glamorous. They are, however, the baseline every business that sends email in Australia should be working towards.