SPF: who may send
A DNS record lists the mail services allowed to send for your domain. Keep it accurate and avoid creating multiple SPF records, which can invalidate the check.
A review of 275 accounting firms found most could be impersonated. SPF, DKIM and DMARC close the domain-spoofing door; a trusted-number check closes a different one.
Read the 275-firm findingAccountants Daily checked the email-authentication posture of 275 Australian accounting firms and reported that most could be impersonated by email. The issue was not a misspelt lookalike alone. Weak or unenforced domain controls can let a scammer place the firm's real domain in the visible From field.
At tax time, that credibility can turn a routine-looking fee invoice, refund message or “updated” payment instruction into a direct path to clients. The recipient sees a familiar name and address. Without an enforced policy, the receiving mail system may have too little reliable instruction to reject the forgery.
CPA Australia also warns that accounting firms hold valuable financial and identity information, making both firms and their clients attractive targets. Email security therefore needs an owner, a maintained technical control and a human procedure for consequential requests.
Email was designed to move messages, not to make the visible From address self-authenticating. A criminal can attempt to send a message that claims to come from [email protected] even though it left a server the firm has never used.
The receiving mail service looks for evidence in DNS. SPF asks whether the sending infrastructure is authorised. DKIM checks a cryptographic signature. DMARC connects those results to the domain visible to the recipient and publishes the domain owner's requested treatment for failures.
If those records are missing, broken or left at monitoring-only policy, a forged message has a better chance of reaching the inbox. Correctly configured enforcement gives receiving services a clear instruction to quarantine or reject it.
SPF, DKIM and DMARC authenticate the sending domain and message path. They do not prove that the human using an authorised mailbox is honest, uncompromised or permitted to change a client's bank details. They also do nothing to authenticate a caller.
How real mailboxes are compromisedA DNS record lists the mail services allowed to send for your domain. Keep it accurate and avoid creating multiple SPF records, which can invalidate the check.
Your mail service adds a cryptographic signature. Receiving systems use the public key in DNS to check that an authorised service signed the message and its signed content was not changed.
DMARC checks whether the visible From domain aligns with SPF or DKIM, tells receivers whether to monitor, quarantine or reject failures, and provides reports that reveal legitimate senders and abuse.
Publishing a DMARC record is the start, not the outcome. The useful destination is an accurate sender inventory, aligned SPF or DKIM, monitored reports and an enforced policy that rejects unauthorised use without breaking legitimate mail.
List Microsoft 365 or Google Workspace, the practice platform, invoicing, payroll, marketing, forms, scanners and any vendor that sends mail using the firm's domain.
Authorise only current services, remove retired includes and check the ten-DNS-lookup limit. Use a subdomain for high-volume or third-party mail where appropriate.
Turn on DKIM for every capable sending service. Confirm the signing domain aligns with the address clients see in From, and rotate selectors according to the provider's guidance.
Publish DMARC at _dmarc.yourdomain with an aggregate-report mailbox. Begin at p=none while the inventory is tested; use a reporting service or IT provider to interpret XML reports.
Use reports to find forgotten senders, forwarding behaviour and alignment errors. Configure each service correctly rather than broadly authorising infrastructure you do not control.
Move to p=quarantine and ultimately p=reject once legitimate mail passes. Increase pct in controlled steps, monitor delivery and include subdomains deliberately with an sp policy.
Register obvious high-risk variants where proportionate, monitor newly registered lookalike domains, and give clients a known website and phone number for checking unusual requests.
New billing, marketing or practice software can silently break alignment. Make email authentication part of vendor onboarding, offboarding and the firm's recurring security review.
The attacker signs in to the client's or firm's real account. The authorised service signs the message correctly, so authentication can pass.
The message is authenticated for a newly registered domain that resembles the firm's. DMARC protects your domain, not every deceptive spelling of it.
A caller uses details gathered from an inbox, social media or stolen records. Email controls are not involved in the call at all.
That is why client-facing warnings such as “we never change bank details by email” help but are not enough. Firms need a procedure staff and clients can actually follow when a message or call asks for a consequential change.
For changed refund accounts, fee destinations or authorities, return to a trusted mobile number that predates the instruction. Do not authenticate an email by replying to it, and do not authenticate a caller using a new number they supply.
Flag changed bank details, fee destinations, contact numbers, authorities and urgent exceptions as high-risk instructions.
Do not reply to the suspect message or call a number in its signature. Return to a trusted mobile number already held in the practice system.
Send a one-time SMS code to that mobile number and ask the person reached to read it back.
Stop and escalate mismatches, failed checks or requests to substitute a new number before the check is complete.
Keep the email, authentication clues, verification outcome, approval and final action connected in the client or incident record.
With Vericode, staff highlight a phone number already visible in a browser-based practice system, tax portal or email client, right-click and send a one-time SMS code. The person reads the code back. Verification messages are sent through Australian SMS provider MobileMessage, using Vericode's ACMA-registered sender ID, VERICODE.
Each authorised-contact check creates a timestamped, hash-chained record of who requested it, the masked target, method and outcome. Compliance-authorised users can export the audit as PDF or CSV. The record proves the contact check, not bank-account ownership or the authenticity of the email itself.
Vericode stores the data needed to dispatch and evidence a verification: recipient details, message and provider metadata, timestamps, actors, outcomes and audit events. The product is not a document repository and does not require customers to upload client matter files to complete a verification.
Customer and verification data (recipient details, messages and verification records) is hosted in Australia. Staff sign-in is handled by our identity provider, WorkOS, in the United States; see the subprocessor information below.
Public guidance is cited for context. No Accountants Daily or CPA Australia endorsement of Vericode is implied.
Give your IT provider the DMARC checklist, give staff a trusted-number procedure and give clients one clear route to challenge an unexpected instruction.