How to Stop Scammers Sending Email in Your Company’s Name

A scammer does not need to hack your mailbox to send an email that appears to come from your business.

They can put your domain in the visible From address, copy your logo and ask a client to pay a fake invoice or change bank details. If the receiving mail system cannot verify the sender, the message may still reach the inbox.

This is email spoofing. Three controls called SPF, DKIM and DMARC make it much harder to impersonate your exact domain.

Having the records present is not enough. They need to cover every legitimate sending service, align with the visible address and eventually tell receiving systems to quarantine or reject failures.

Why the From address cannot be trusted on its own

Email was designed around cooperation between mail systems. The visible From address is not proof that a message came from the domain it displays.

Think of it like the return address written on an envelope. The address may look familiar, but the postal system does not know whether the person who wrote it lives there.

Email authentication gives the receiving server evidence it can check. SPF identifies authorised sending systems. DKIM applies a cryptographic signature. DMARC checks whether those results align with the domain the reader sees and publishes a policy for failures.

The Australian Signals Directorate recommends SPF, DKIM and DMARC as a set of controls to help protect an organisation’s domain from impersonation.

SPF lists who may send for your domain

SPF stands for Sender Policy Framework. It is a DNS record listing the services permitted to send email for your domain.

For a small business, that list may include Microsoft 365, a marketing platform, an accounting system, a website form and a ticketing platform. Each legitimate sender needs to be considered.

SPF has some important limits. A domain can publish only one SPF record, and the record has a limit on the number of DNS lookups it can trigger. Copying in a new entry every time a service asks can create an invalid or overly broad record.

SPF also checks the technical sending path, not simply the From address the person sees. That is why SPF works with DKIM and DMARC rather than solving spoofing alone.

DKIM signs legitimate email

DKIM stands for DomainKeys Identified Mail. The sending service adds a digital signature to each outgoing message. The receiving server finds the matching public key in DNS and checks the signature.

A valid result shows that the service holding the private key signed the message and that signed parts of the message were not changed in transit.

DKIM needs to be enabled separately for each service that supports it. Microsoft 365 may be configured correctly while a marketing platform is not. If that platform sends as your business domain without a valid signature, strict DMARC enforcement can affect its delivery.

That is why an inventory of sending services comes before a reject policy.

DMARC joins the checks to the visible domain

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. The name is awkward, but the job is practical.

DMARC checks whether SPF or DKIM passes in a way that aligns with the visible From domain. It then applies the policy published by the domain owner.

The main policy values are:

• p=none, which monitors failures and requests reports
• p=quarantine, which asks receiving servers to treat failures as suspicious
• p=reject, which asks receiving servers not to accept failures

A monitoring policy is useful during rollout, but it does not instruct receiving servers to block spoofed email. A domain can have DMARC and still provide little protection if it remains at p=none indefinitely.

The goal is usually to understand the reports, correct legitimate senders and then move towards enforcement.

Do not jump straight to reject

Publishing p=reject without knowing who sends email for the business can block legitimate messages.

A proper rollout starts by identifying every platform that sends with the domain. This can include systems people have forgotten about, such as an old newsletter service, scanner, CRM, website plug-in or payroll platform.

Next, configure SPF and DKIM where appropriate. Publish DMARC in monitoring mode and review the reports. The reports show which systems are sending, which checks pass and where alignment fails.

Once known services are working properly, increase enforcement in stages. Some organisations quarantine a percentage of failures first, then increase coverage before moving to reject.

This is not a one-time DNS task. New sending services need to go through the same process rather than being added casually.

What DMARC does not stop

DMARC protects the exact domain. It does not stop every type of impersonation.

A scammer may register a lookalike domain with an extra word, missing letter or different ending. They may also use a free email account but set the display name to your managing director or accounts team.

The message may then say that bank details have changed or an urgent payment must be made.

The technical controls still help, but payment verification remains essential. Staff should confirm every change to bank details by calling a known number already held on file, not a number in the email requesting the change.

Clients and suppliers should be given the same expectation. A clear payment-change process is harder for an attacker to interrupt.

Authentication also affects delivery

SPF, DKIM and DMARC are not only security controls. Major mail providers use authentication when deciding whether a message belongs in the inbox.

This matters even if the business does not send thousands of messages a day. A properly authenticated domain builds a clearer sending identity and reduces the chance of legitimate mail looking suspicious.

Marketing platforms also need to send through a domain that the business owns and controls. Using a provider’s shared defaults may be easy at first, but it gives the business less visibility into authentication and reputation.

For Microsoft 365 businesses, proper Microsoft 365 setup includes more than creating mailboxes. Domain authentication, safe administrator access and monitoring all affect whether email can be trusted.

How to check your domain

A public checker can show whether SPF, DKIM and DMARC records exist. That is a starting point, not a complete assessment.

An accurate review also needs to answer:

• Which services legitimately send email for the domain?
• Does each one pass SPF or DKIM with alignment?
• Is the SPF record valid and within lookup limits?
• Are DKIM keys enabled and current?
• Where do DMARC reports go?
• Is someone reviewing those reports?
• Is the policy still p=none?
• Are subdomains covered appropriately?

An empty report or a green icon from one checker is not proof that the domain is fully protected. Testing should include real messages from each sending service and inspection of the authentication results.

Protect the name your business has built

When a spoofed email reaches a client, the financial loss is only part of the damage. The client may believe the business failed to protect its own name or payment process.

For a professional firm in Brookvale, Warriewood or across the North Shore, trust is part of the product. Email authentication helps protect that trust before an incident happens.

Vaelis IT provides cybersecurity support for Northern Beaches and North Shore businesses, including Microsoft 365 and domain configuration. We can identify every legitimate sender, fix SPF and DKIM, interpret DMARC reporting and move the domain towards enforcement without breaking normal email.