Phishing via fake emails sent from your own domain name is one of the most widely used attack methods. Three standards — SPF, DKIM and DMARC — protect your domain effectively, but a large share of SMEs still do not have them correctly configured. Read how it works and what you can do today.
Phishing and email fraud have ranked among the top five most-used attack methods for years. What many businesses fail to realise is that their own organisation's email domain can be abused by attackers without anyone inside the company noticing. Someone sends a message that appears to come from your@yourcompany.com, but the sender is entirely fake. Recipients see your name and domain and trust the message. This is called email spoofing, and it is technically straightforward if your domain is not protected.
Three standards together form the defence: SPF, DKIM, and DMARC. They have existed for years, but research from government bodies and cybersecurity organisations consistently shows that a large portion of SMEs have not configured them at all, or not correctly. In 2024, Google and Yahoo made email authentication mandatory for bulk senders. The expectation is that other major mail providers will follow, and that regulators under NIS2 will check for compliance with increasing frequency.
The three standards work together but each has its own function. SPF (Sender Policy Framework) records in a DNS entry which mail servers are authorised to send email on behalf of your domain. Such a record tells receiving mail systems: 'only Microsoft's servers may send email from @yourdomain.com'. Email arriving from an unauthorised server can be rejected or flagged as suspicious.
DKIM (DomainKeys Identified Mail) adds a digital signature to every email your server sends. The receiving server verifies via a public key in your DNS whether the email was tampered with in transit and whether it genuinely originated from an authorised source. A forged email either lacks that signature or the signature does not match the content.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer on top of SPF and DKIM. DMARC tells receiving mail servers what to do with messages that fail the SPF or DKIM check: do nothing but report, place in the junk folder, or reject outright. Additionally, DMARC sends daily reports to an address you specify, giving you visibility into who is sending email using your domain name.
The pressure to configure email authentication correctly has increased sharply over the past two years. Google and Yahoo made DMARC verification mandatory in February 2024 for senders sending more than five thousand messages per day to Gmail or Yahoo addresses. Lighter requirements apply to smaller senders, but the direction is clear: messages without authentication are increasingly being blocked or placed in the junk folder.
Meanwhile, attackers have refined their techniques. Business Email Compromise (BEC), where an employee or supplier is deceived via a forged email, was the most costly form of cybercrime for SMEs in 2025 and 2026. A properly configured DMARC policy at p=reject makes it considerably harder to abuse your domain name for such attacks, because forged messages are blocked before they reach the recipient.
An additional benefit: correct DMARC configuration improves the deliverability of your legitimate email. Domains with a strong reputation, partly determined by correct authentication, see higher open rates and less risk of false-positive spam classifications by recipients.
Implementation proceeds in three phases. The first phase is configuring SPF. Log in to your DNS manager, your domain registrar or hosting provider, and add a TXT record for your domain. If you send exclusively via Microsoft 365, the record typically looks like: v=spf1 include:spf.protection.outlook.com -all. If you also send via other services such as a marketing platform or an external CRM, those must also be included. Important: you may only have one SPF record per domain.
The second phase is enabling DKIM. In Microsoft 365, you do this via the Defender portal under Email authentication. Microsoft generates a key pair and provides two CNAME records that you enter at your DNS provider. After verification, Microsoft automatically signs all outgoing email on behalf of your domain with that key. For other email services you use, each platform has its own DKIM configuration that must be set up separately.
The third phase is setting up DMARC. Add a TXT record named _dmarc.yourdomain.com with a value such as: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Always start with p=none, monitoring mode. This blocks nothing yet but sends you daily reports. After two to four weeks of analysis, you switch to p=quarantine and ultimately to p=reject.
DMARC reports are XML files that arrive daily from all major mail providers that receive email claiming to originate from your domain. They contain information about the sending server, the IP address, whether SPF and DKIM checks passed, and how many messages were processed.
Raw XML reports are difficult to read. There are free and paid tools that convert the reports into understandable dashboards: Postmark, Dmarcian, EasyDMARC, and Valimail are well-known names. With a free tier you can already gain sufficient insight to determine when you can safely move from p=none to p=reject.
What the reports typically show in the first weeks: your own Microsoft 365 sending passing correctly, your marketing platform potentially failing if DKIM has not yet been configured there, and the occasional rogue sender attempting to abuse your domain. That last category disappears once you are on p=reject.
Five mistakes that regularly occur at SMEs. First: moving too quickly to p=reject without analysing the reports. This can result in legitimate email, for example from a marketing platform not yet configured for DKIM, being blocked and never reaching your customers.
Second: forgetting subdomains. Email via a subdomain such as newsletter.yourdomain.com falls outside your main domain DMARC policy. Add separate records for subdomains that send email, or use the sp= parameter to extend the subdomain policy from your main record.
Third: overloading the SPF record. SPF has a hard limit of ten DNS lookups. With multiple external email services you can exceed this quickly. Use an SPF flattening tool to keep the record compact and within the limit.
Fourth: not tracking new email services. Every new tool that sends email on behalf of your domain, from a CRM to a helpdesk system, must be added to SPF and configured for DKIM. This is regularly forgotten when new software is adopted.
Fifth: no DMARC record for non-sending domains. If your company has registered additional domains that are not actively used for email, they are still attractive targets for spoofing. A simple DMARC record with p=reject and an empty SPF record (v=spf1 -all) prevents those domains from being abused.
Three steps to start immediately. First: check your current situation. Search for 'DMARC check' and use a free online tool to see whether your domain has SPF, DKIM, and DMARC records and whether they are correctly configured. This takes less than five minutes and provides immediate insight into what is missing.
Second: if there is no DMARC record, or the policy is set to p=none without a reporting address, add a monitoring record today. That is the fastest step with the least impact on your day-to-day operations.
Third: schedule a moment within four weeks to review the reports and determine when you can scale to p=quarantine. Most well-prepared SMEs reach p=reject within six to eight weeks. Email authentication is one of the most effective and affordable security measures your organisation can take. It protects your customers and partners from phishing in your name, and protects your own reputation as a trustworthy sender. Want help configuring DMARC, analysing your reports, or conducting an email infrastructure audit? Contact Zarioh.
