Last updated on October 2nd, 2026 at 11:57 am
Someone receives an invoice that looks as though it came from your business. You never sent it. Or you tighten your email security and your own booking confirmations vanish into spam. SPF, DKIM and DMARC help with the first problem, but a rushed setup can create the second. This is a practical guide to understanding the three checks before changing live DNS.
What each check actually does
SPF tells receiving systems which servers may send mail using your domain in the envelope sender address. DKIM adds a cryptographic signature so receivers can check that a message was signed by a domain and was not modified in transit. DMARC checks whether an authenticated SPF or DKIM domain aligns with the domain a reader sees in the From field, and lets you publish a policy and receive reports. See the Australian Cyber Security Centre’s guidance on combating fake emails for the underlying controls.
Passing SPF alone does not mean a message passes DMARC. A third-party service may use its own envelope sender domain, so SPF passes for that service but does not align with your visible From address. A valid DKIM signature can supply the aligned result instead. Do not paste an SPF or DMARC record from an unrelated tutorial without understanding which domains and services it describes.
What DMARC will not stop
DMARC helps receivers handle mail falsely claiming your exact domain. It does not tell a customer that a similar-looking domain is an imposter. It also cannot protect you when a criminal has logged into a real mailbox and sends an authenticated message from it. Protect real accounts with MFA, monitor unusual sign-ins and teach people to verify changed payment details through an independent channel.
Our domain and email continuity checklist covers who controls the registration, DNS and recovery address. That inventory is the foundation for email authentication: it is difficult to manage a domain safely if nobody knows which provider holds its DNS.
Inventory legitimate senders before enforcing a policy
Write down every system that sends using your domain: staff mailboxes, shared mailboxes, CRM, accounting software, invoices, appointment reminders, WordPress contact forms, newsletters, helpdesk, transactional mail and any agency working on your behalf. Some systems use a subdomain or send with a separate From address. Record the provider, visible From domain, envelope sender, DKIM signing domain, owner and a test recipient for each.
Send a test message from each service and inspect authentication results at a receiving mailbox. Don’t rely on the owner’s personal inbox as your only test. Check internal and external recipients, and check a message with an attachment if that is part of the normal workflow. The Google sender guidance explains why SPF, DKIM and DMARC matter for senders to Gmail, though a business must also check its own providers and recipients.
Publish carefully and increase enforcement in stages
Keep one correctly combined SPF TXT record for a domain rather than adding a separate record for every vendor. SPF also has a DNS lookup limit, so blindly stacking include mechanisms can make the record fail. Set up DKIM with the correct keys or selectors for each supported sender. Rotate or remove a departed provider’s keys after confirming it no longer sends. Take a copy of the existing DNS zone and have a rollback plan before editing.
A common first DMARC step is a monitoring policy, p=none, with reports going to a mailbox or analysis service that somebody actually reads. That policy requests reports but does not ask recipients to quarantine or reject unauthenticated mail. Investigate the services that fail alignment. Once legitimate senders authenticate reliably, consider a staged move to p=quarantine, then p=reject. These are requests to receiving systems, not a guarantee every receiver will behave identically. Re-test contact forms and invoices after each change.
Separate sending subdomains may be appropriate for marketing or transactional systems, but they still need owners and their own authentication plan. Check the effect of a DMARC policy on subdomains rather than assuming the root domain’s record covers every sender the way you intend. ACSC’s guidance for email service providers is useful background when reviewing outsourced mail.
A rollout worksheet that fits a small business
- Who controls the authoritative DNS zone and who approves changes?
- Which business systems send mail using the domain or its subdomains?
- For each sender, which SPF or DKIM result aligns with the visible From address?
- Where will DMARC reports go, and who will investigate failures?
- What invoice, booking and website-form messages will be tested after every change?
- How will you roll back if legitimate mail starts failing?
Authentication is not permission to market. Read the Australian spam-law guide before adding newsletters or promotional SMS to your sender inventory. The automation guide covers carrying opt-outs through integrations.
SenseICT can help map your mail senders and DNS dependencies, test alignment and make the policy changes in a controlled order. Explore SenseICT’s ICT solutions or ask Matt about your mail setup. DomainCastle’s managed WordPress hosting is not a substitute for email authentication, and PainlessDNS is an upcoming project, not a service to rely on for a live migration today.
