If your company’s domain gets spoofed, the first sign is usually a phone call from a client asking why they got an invoice from “you” asking for a wire transfer to a new account. This is a plain-English checklist for setting up SPF, DKIM, and DMARC correctly, in the right order.

Why small firms get spoofed

Email spoofing does not require breaking into your systems. Basic SMTP has no built-in check that the “From” address on an email actually belongs to the sender. Anyone can put your domain in the From field and send mail that looks legitimate to a recipient’s inbox, unless the receiving mail server checks whether the sending server was authorized to send on your domain’s behalf.

Small businesses are attractive targets for this because:

• Client and vendor relationships are often informal enough that a spoofed invoice or payment change request looks plausible.
• Many small firms never set up SPF, DKIM, or DMARC at all, so there is no technical barrier to a convincing forgery.
• A single successful spoof (a fake wire request, a fake W-9) can cost real money fast, which makes small firms worth targeting even without a large employee count.

The fix is not complicated, but it has to be done in the right order or you risk blocking your own legitimate mail.

What each record actually does

SPF (Sender Policy Framework)
SPF is a DNS TXT record that lists which mail servers are allowed to send email for your domain. When a receiving mail server gets a message claiming to be from your domain, it can check your SPF record to see if the sending server is on the approved list.

Example SPF record for a Microsoft 365 tenant:

v=spf1 include:spf.protection.outlook.com -all

The -all at the end means servers not on your list get an SPF fail result for your domain. A ~all (soft fail) marks unlisted servers as suspicious rather than an outright fail. What a receiving mail server actually does with a fail or soft fail (accept, quarantine, or reject) is up to that server’s own policy, though DMARC (below) lets you state your preference more directly. Many organizations start with ~all and move to -all once they are confident every legitimate sender is included.

DKIM (DomainKeys Identified Mail)
DKIM adds a digital signature to outgoing email, generated with a private key held by your sending mail server and verified with a public key published in your DNS. If any part of the signed content is altered in transit, the signature fails to verify. This proves both that the message came from a server holding your private key and that the signed content was not tampered with.

DKIM setup is provider-specific: Microsoft 365 and Google Workspace each have their own steps to generate the key pair and publish the DNS record, usually a CNAME or TXT record with a selector prefix like selector1._domainkey.yourdomain.com.

DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC ties SPF and DKIM together with one extra idea that does most of the work: alignment. A message passes DMARC when at least one of SPF or DKIM passes, and the domain that check verified matches the domain shown in the visible From address.

• SPF verifies the envelope sender (the Return-Path, sometimes called the MAIL FROM domain), which the recipient never sees. If that domain does not match the visible From domain, SPF alone does not satisfy DMARC, even though SPF itself passed.
• DKIM verifies the d= domain in the signature, which also has to match the visible From domain for DMARC purposes.
• By default, alignment is relaxed: mail.yourdomain.com aligns with yourdomain.com because both share the same organizational domain. Strict alignment (aspf=s or adkim=s) requires an exact match.

This is why a message can pass SPF and still fail DMARC: the sending server was authorized, but it was sending on behalf of a different domain than the one shown to the reader. DMARC closes that gap and adds reporting. A DMARC record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The p= tag is the policy: none (monitor only, take no action), quarantine (send failures to spam), or reject (block failures outright). The rua tag is where aggregate reports get sent so you can see who is sending mail as your domain, including services you forgot you authorized.

The safe rollout order

Do not jump straight to p=reject. That is how legitimate mail from your own systems starts landing in spam or getting rejected outright, often without anyone noticing until a client complains.

1. Publish SPF first, with all your legitimate sending sources included, ending in ~all (soft fail) while you confirm the list is complete.
2. Set up DKIM for every service that sends mail on your behalf: your main mail provider, plus anything else, such as your invoicing platform or marketing email tool.
3. Publish DMARC at p=none. This does not block or quarantine anything. With the rua tag set, it only turns on reporting, so you can see what is currently sending mail using your domain, both authorized and unauthorized.
4. Read the reports for at least two to four weeks. DMARC aggregate reports are XML and not easy to read by hand; a free or low-cost DMARC report parsing tool makes this practical. Look for legitimate senders you have not yet added to your SPF record or set up DKIM for.
5. Move to p=quarantine once you are confident every legitimate sender passes. This sends failures to spam instead of the inbox, a lower-risk step than outright rejection.
6. Move to p=reject once quarantine has run cleanly for a few weeks with no legitimate mail getting caught. This is the policy that actually stops spoofed mail from being delivered.

Skipping the monitoring period is the single most common cause of “DMARC broke our email” problems.

Common mistakes

• Multiple SPF records. A domain can only have one SPF record. If you have more than one TXT record starting with v=spf1, SPF returns a permanent error (permerror) per RFC 7208 section 4.5, and no message can pass SPF. Merge everything into a single record.
• Hitting the 10-lookup limit. SPF allows a maximum of 10 DNS lookups (each include, a, mx, ptr and exists mechanism counts, and so does the redirect modifier, per RFC 7208 section 4.6.4). Go over that limit and SPF returns a permanent error, which DMARC treats as SPF not passing. This happens quietly as companies add more include statements for new services over time. If you are near the limit, flattening the record (resolving includes to their underlying IP ranges) is the usual fix, but it needs to be re-checked whenever an included provider changes their sending IPs.
• Forgetting third-party senders. Billing platforms, marketing email tools, HR and payroll systems, and CRM platforms often send mail on your domain’s behalf. If they are not included in SPF and do not have DKIM set up, their mail will start failing once you tighten your DMARC policy. This is the most common cause of “wait, why did our invoices stop arriving” after a DMARC change.
• Stale or missing DKIM records after a provider change. If you switch email providers or marketing platforms, two things go wrong. If the new provider’s DKIM record is never published, its mail fails DKIM. And old selector records left in DNS mean the old platform can still sign valid mail as your domain. Publish the new record first, confirm the new provider is signing, then remove the old selectors.

Where this fits with the rest of your security posture

Email authentication stops spoofing of your own domain. It does not stop phishing emails sent from lookalike domains, or protect against a compromised mailbox sending mail from a legitimate but hijacked account. Those need separate controls: mailbox monitoring, MFA, and staff awareness. If a broader review of your email and account security is useful, our Cybersecurity Services page covers what a fuller assessment looks like.

For businesses that also carry cyber insurance, note that some carriers now list SPF, DKIM, and DMARC among the baseline controls they expect to see in place. See Cyber Insurance Requirements: What You Need in Place for the broader list.

Sources

• SPF specification: RFC 7208, IETF. https://datatracker.ietf.org/doc/html/rfc7208
• DKIM specification: RFC 6376, IETF. https://datatracker.ietf.org/doc/html/rfc6376
• DMARC specification: RFC 9989 (obsoletes RFC 7489), IETF. https://datatracker.ietf.org/doc/html/rfc9989
• DMARC aggregate reporting: RFC 9990, IETF. https://datatracker.ietf.org/doc/html/rfc9990
• SPF 10 DNS lookup limit: RFC 7208, Section 4.6.4. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4