Email remains the most common channel for both incoming phishing attempts and, less obviously, attackers impersonating your own company’s domain to target your clients and partners. Three technical email authentication standards — SPF, DKIM, and DMARC — work together to prevent this kind of domain spoofing, yet remain unconfigured or only partially configured on a large share of small business domains. This guide explains what each one does and how to set them up correctly.
This is a technical companion to our broader phishing guide, focused specifically on protecting your own domain from being spoofed rather than recognizing phishing attempts sent to you.
Why domain spoofing is a real business risk
Without proper email authentication configured, it is technically possible for an attacker to send an email that appears to come from your company’s domain — invoice@yourcompany.com, for example — to your clients, vendors, or even your own employees, despite having no actual access to your systems. This is used in documented business email compromise attacks to request fraudulent payments, harvest credentials, or damage a company’s reputation with its own clients and partners, who have no easy way to distinguish a spoofed email from a genuine one without the technical protections this guide covers being properly in place.
SPF: authorizing which servers can send on your behalf
Sender Policy Framework (SPF) is a DNS record listing which mail servers are authorized to send email on behalf of your domain. When an email claiming to be from your domain arrives at a recipient’s mail server, that server can check the SPF record to confirm whether the sending server is actually on the authorized list, rejecting or flagging messages from unauthorized servers.
Setting up SPF involves adding a specific TXT record to your domain’s DNS settings, listing every legitimate service that sends email on your behalf — your primary email provider, any marketing email tool, any transactional email service your applications use. A common mistake is setting up SPF once and forgetting to update it when a new email-sending service is added later, which can cause legitimate emails from that new service to fail authentication and potentially be flagged as spam or rejected entirely.
DKIM: cryptographically signing your emails
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing emails, generated using a private key held by your sending mail server and verifiable by recipients using a public key published in your domain’s DNS. This confirms both that the email genuinely originated from an authorized sender and that its content was not altered in transit, providing a stronger guarantee than SPF alone, which only verifies the sending server rather than the message content itself.
Most email providers and transactional email services provide specific instructions and the necessary DNS records for enabling DKIM signing, typically a straightforward process of adding one or more additional DNS records provided directly by your email service.
DMARC: telling recipients what to do with failures
Domain-based Message Authentication, Reporting and Conformance (DMARC) ties SPF and DKIM together, specifying what a recipient’s mail server should do when an email fails either or both checks — reject it outright, quarantine it (typically meaning it lands in spam), or take no specific action beyond reporting. DMARC also enables reporting, sending you regular reports showing authentication results for email claiming to be from your domain, which is valuable for spotting both configuration problems with your own legitimate email and active spoofing attempts against your domain.
DMARC policy should generally be rolled out gradually rather than jumping directly to a strict rejection policy: start with a monitoring-only policy, review the reports to confirm all your legitimate email sources pass authentication correctly, then progressively move to quarantine and eventually reject as you gain confidence that no legitimate email will be incorrectly blocked in the process.
BIMI: an additional visual layer built on DMARC
Brand Indicators for Message Identification (BIMI) is a newer standard that displays your company’s verified logo directly in a recipient’s inbox next to your emails, but specifically requires a strict DMARC policy (quarantine or reject, not monitoring-only) already in place as a prerequisite. While not a core security requirement in the same way SPF, DKIM, and DMARC are, BIMI provides a visible trust signal to recipients and is a natural next step once your DMARC policy has been successfully tightened to enforcement level, giving your organization a small additional incentive to complete that DMARC rollout properly rather than leaving it at monitoring-only indefinitely.
Handling subdomains correctly
DMARC policies can be configured to apply differently to your main domain versus subdomains, which matters if your organization uses subdomains for different purposes — a marketing subdomain sending bulk newsletters versus your primary domain used for direct business correspondence, for example. Review whether any subdomains send email on your organization’s behalf and ensure they are properly covered by your SPF, DKIM, and DMARC configuration rather than assuming your main domain’s settings automatically extend to every subdomain, since DMARC’s subdomain policy behavior specifically needs to be configured to achieve this if it is what you intend.
A practical rollout sequence
For a small team setting this up for the first time, a reasonable sequence looks like: first, set up SPF, listing every current legitimate sending source for your domain. Second, enable DKIM signing through your email provider and any transactional email services you use. Third, add a DMARC record starting with a monitoring-only policy (p=none), which collects reports without affecting mail delivery. Fourth, review the DMARC reports over several weeks to confirm all legitimate email sources are passing authentication and to identify any gaps in your SPF record you may have missed. Fifth, once confident, progressively tighten the DMARC policy to quarantine and eventually reject.
This gradual approach avoids the common failure mode of jumping straight to a strict policy and inadvertently blocking legitimate email from a source that was missed during initial SPF setup.
Common mistakes we see
Setting up SPF and DKIM but never adding DMARC. Without a DMARC policy, recipients’ mail servers have no clear instruction on what to do when SPF or DKIM checks fail, meaning the protection these standards provide is significantly weaker than when all three are configured together.
Forgetting to update SPF when adding a new email-sending service. As mentioned above, this is one of the most common ongoing maintenance gaps, and worth specifically checking whenever a new tool or service that sends email on your domain’s behalf is adopted.
Jumping directly to a strict DMARC reject policy without the monitoring phase. This risks legitimate email being blocked if any sending source was missed during setup, which can be disruptive and hard to diagnose after the fact compared to catching the gap during a monitoring-only phase first.
Frequently asked questions
Do we need technical expertise to set these up, or can we do it ourselves?
Basic setup involves adding DNS records, which is manageable for most small teams with some technical comfort, particularly with clear instructions from your email provider. For a more complex setup involving multiple sending sources or an unfamiliar DNS provider interface, some teams choose to bring in outside help for the initial configuration.
Will this affect our regular email deliverability?
Properly configured SPF, DKIM, and DMARC generally improve deliverability over time, since many receiving mail servers increasingly favor or require proper authentication for inbox placement rather than routing to spam. The main risk is during initial setup if a legitimate sending source is missed, which the gradual DMARC rollout described above specifically protects against.
How do we read and act on DMARC reports?
DMARC reports arrive in a technical XML format that is difficult to read manually at scale; several free and paid DMARC reporting and analysis tools convert these into a readable dashboard format, making it practical to review results without needing to parse raw XML files manually.
Does this protect us from receiving phishing emails, or only from our domain being spoofed?
Primarily the latter — these standards protect your domain’s reputation and prevent others from successfully spoofing your domain. Protecting your team from receiving phishing emails sent from other domains is covered separately in our phishing guide, though a well-configured receiving mail server checking these same standards on incoming email does help filter out some spoofed messages claiming to be from other legitimate domains as well.
How long does it typically take to safely reach a full DMARC reject policy?
This depends on how many distinct email sources your organization has and how quickly you review the monitoring reports, but a cautious rollout for a typical small business often takes several weeks to a few months from initial monitoring-only setup to a confident, fully enforced reject policy, prioritizing correctness over speed given the risk of blocking legitimate email if the process is rushed.
For more on protecting your team and domain from email-based threats, see our full phishing guide and hardening guides section.