What Is DMARC and Why Does It Matter for Your Business Email?

The Problem DMARC Solves

Imagine a criminal sends an email to your clients that appears to come from your business email address — yourname@yourbusiness.com.au — but is actually sent from a server they control. The email instructs the client to pay an invoice to a new bank account. The client trusts the email because it looks like it came from you. They pay. The money goes to the criminal.

This is domain spoofing, and it is one of the most effective fraud techniques used against small businesses and their clients. Without DMARC (and the related standards SPF and DKIM), any email server in the world can send email claiming to be from your domain, and most email clients will display it as if it genuinely came from you.

The Three Email Authentication Standards

SPF (Sender Policy Framework). An SPF record in your domain's DNS lists which email servers are authorised to send email from your domain. Email servers receiving messages from your domain can check whether the sending server is on the authorised list.

DKIM (DomainKeys Identified Mail). DKIM adds a digital signature to outgoing emails, generated using a private key held by your sending mail server. Receiving servers can verify the signature using a public key published in your DNS. If the signature does not match, the email has been tampered with or did not come from an authorised sender.

DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC builds on SPF and DKIM by telling receiving mail servers what to do when an email fails authentication checks: allow it (p=none), send it to spam (p=quarantine), or reject it entirely (p=reject). It also enables reporting so you can see who is sending email claiming to be from your domain.

Why You Need All Three

SPF and DKIM alone are not enough. DMARC is the policy layer that tells receiving servers to act on authentication failures. Without a DMARC policy at p=quarantine or p=reject, failed authentication checks may be ignored and spoofed emails delivered anyway.

The target configuration for a small business protecting against domain spoofing:

• SPF configured and correct
• DKIM active (your email provider — Microsoft 365 or Google Workspace — configures this)
• DMARC policy at p=reject (or at minimum p=quarantine)

Common Objections

"We are too small to be targeted." Invoice fraud against small businesses is automated — criminals scan domain registries, identify businesses without DMARC, and target their clients systematically. Size does not protect you.

"We already have spam filtering." Spam filtering on your own inbox is not the same as DMARC. DMARC protects your clients and suppliers from receiving fraudulent emails that appear to come from you — that happens in their inbox, not yours.

"Our IT provider set this up." Confirm it. Run your domain through a DMARC checking tool (dmarcian, MXToolbox, or EasyDMARC) to see whether your current configuration is at p=reject.

Getting DMARC Configured

DMARC configuration requires DNS access and careful setup — misconfiguration can cause legitimate email to be rejected. Netluma IT configures DMARC, DKIM, and SPF for all managed clients as part of onboarding. Call 1300 521 162 to get this done.

The Three Standards: SPF, DKIM, and DMARC Together

DMARC does not work in isolation — it requires SPF and DKIM to be correctly configured first. Understanding all three and how they work together makes DMARC meaningful.

SPF (Sender Policy Framework). A DNS record that lists the mail servers authorised to send email from your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is on the approved list. An email from an unauthorised server fails SPF.

DKIM (DomainKeys Identified Mail). A cryptographic signature added to every email sent from your domain. The private key is held by your mail server; the public key is published in your DNS. The receiving server uses the public key to verify the signature. Tampering with the email (changing the content or headers) invalidates the signature.

DMARC (Domain-based Message Authentication, Reporting and Conformance). A DNS record that tells receiving servers what to do when an email fails SPF or DKIM checks. Three policy options: "none" (monitor only — take no action but send reports), "quarantine" (move failed emails to spam), and "reject" (do not deliver the email at all). DMARC also specifies where to send reports.

The full chain: an email from your domain arrives at a recipient's server. The server checks SPF (is this mail server on the approved list?), checks DKIM (is the signature valid?), and if both fail, applies the DMARC policy. At p=reject, the email does not reach the inbox.

Setting Up DMARC: The Practical Steps

DMARC configuration happens in your DNS records (managed through your domain registrar or DNS provider). The process:

Step 1: Confirm SPF is configured. Your DNS must have an SPF record. If you use Microsoft 365 for email, Microsoft publishes the required SPF syntax. Check with a tool like MXToolbox (mxtoolbox.com/spf.aspx) that your SPF record is valid and includes all legitimate sending sources.

Step 2: Enable DKIM in Microsoft 365 (or Google Workspace). In the Microsoft 365 Defender portal (or Google Workspace Admin Console), DKIM signing can be enabled with a few clicks. This creates the required DNS records and starts signing outgoing email.

Step 3: Create a DMARC record at p=none. Start with p=none to monitor without affecting email delivery. The DMARC record includes a "rua" tag specifying where to send aggregate reports. These reports (received as XML email files) show all sources sending email claiming to be from your domain.

Step 4: Review the reports. Over two to four weeks, review the DMARC reports. You will see your legitimate mail sources (Microsoft 365, any marketing platforms, any third-party systems that send email on your behalf) and potentially spoofed sources attempting to use your domain.

Step 5: Add legitimate sources to SPF. Any legitimate source not already on your SPF record needs to be added. Marketing email tools (Mailchimp, ActiveCampaign, Campaign Monitor) often have specific SPF records to add.

Step 6: Move to p=quarantine then p=reject. Once you are confident that all legitimate sending sources are covered by SPF/DKIM, move the DMARC policy to p=quarantine for a week, then p=reject. At p=reject, spoofed emails from your domain are blocked at the receiving server.

DMARC Reports: What to Look For

DMARC aggregate reports arrive daily from major email providers (Google, Microsoft, Yahoo). They are XML files that are hard to read directly — tools like Dmarcian, EasyDMARC, or MXToolbox DMARC analytics make them human-readable.

In the reports, look for:

• Unknown sending IPs that are not on your SPF record (could be legitimate sources you forgot to add, or spoofing attempts)
• Failed DKIM alignment (indicates a legitimate source that is not properly signing email)
• High volumes of email from IPs you do not recognise (spoofing activity)

DMARC and Business Email Compromise

DMARC at p=reject closes the most common technical pathway for business email compromise: sending fake invoices or payment change requests from an email address that looks exactly like your domain. If an attacker sends accounts@yourcompany.com.au from a server in Romania, the email fails SPF and DKIM, and DMARC at p=reject prevents delivery.

What DMARC does not prevent: a compromised email account (where an attacker has logged into your actual Microsoft 365 and is sending from your genuine account). That requires MFA and account monitoring.

Netluma IT configures DMARC, DKIM, and SPF for SE Queensland businesses as part of email security setup. Call 1300 521 162 to have your email security posture assessed.