SPF, DKIM, and DMARC: what small businesses should actually configure.

Email authentication is often treated as a DNS checklist. The useful question is simpler: can receiving mail systems distinguish legitimate messages from someone pretending to send as your domain?

A business can have strong passwords, multifactor authentication, and good endpoint security while still leaving its email domain easy to impersonate.

That is the problem SPF, DKIM, and DMARC are designed to address. They help receiving mail systems determine whether a message claiming to come from your domain was sent through an authorized system and what to do when authentication fails.

These controls do not stop every phishing email. An attacker can register a lookalike domain, compromise a real mailbox, or send a convincing message from an unrelated address. But properly configured email authentication makes direct spoofing of your own domain substantially harder and gives you better visibility into systems sending mail on your behalf.

For firms that exchange sensitive client information, invoices, payment instructions, tax documents, or healthcare-related communications, that is basic domain hygiene—not an exotic security project.

SPF, DKIM, and DMARC solve different parts of the problem

SPF identifies authorized sending infrastructure

Sender Policy Framework, or SPF, is a DNS record that identifies systems authorized to send mail for a domain. When a receiving server gets a message, it can compare the sending infrastructure against the domain's published SPF policy.

The common mistake is assuming that only the primary email provider sends mail. In a real small business, messages may also come from a CRM, billing platform, website form, copier, ticketing system, marketing service, payroll application, or industry-specific software.

If those sources are legitimate, they need to be accounted for. If they are forgotten, tightening SPF can disrupt valid mail.

There should also be only one SPF record for a domain. Multiple competing SPF TXT records are not a way to authorize multiple services; they create an invalid configuration. SPF records can authorize several sources within one policy.

DKIM proves that an authorized domain signed the message

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outbound email. The receiving system uses a public key published in DNS to verify the signature.

DKIM is valuable because it provides another authentication path and is often more resilient than SPF when mail is forwarded. But simply seeing a DKIM pass is not enough to prove that the visible From address is trustworthy. The signing domain matters.

For normal business email, configure the organization's mail platform to DKIM-sign messages using the business's own domain. Third-party senders should also be reviewed to determine whether they support DKIM signing aligned to your domain.

DMARC connects authentication to the address people actually see

DMARC—Domain-based Message Authentication, Reporting, and Conformance—builds on SPF and DKIM. It checks whether authenticated domains align with the domain in the visible From address and publishes a policy telling receiving systems how to handle messages that fail.

That alignment is important. Without it, a message could authenticate using an attacker's domain while displaying a different domain to the recipient.

DMARC also supports reporting. Those reports can reveal legitimate senders you forgot about, configuration errors, and systems attempting to impersonate your domain.

Do not jump straight to DMARC reject without knowing who sends your mail

A DMARC policy can be set to monitoring only, quarantine, or reject. CISA recommends DMARC enforcement and identifies p=reject as the strongest protection against direct domain spoofing. That is a sensible destination. It is not always the sensible first click.

Before enforcement, inventory the systems that legitimately send as your domain. A tax firm, for example, might have ordinary staff mail, automated messages from its tax or practice-management platform, a client portal, website notifications, and a marketing service. A dental practice may have appointment reminders or patient-communication systems. A retailer may have ecommerce, receipt, and point-of-sale services.

If a legitimate sender is not authenticated and aligned correctly, an aggressive DMARC policy can cause its messages to be quarantined or rejected.

A controlled rollout is usually better:

Common email-authentication mistakes

Adding services to SPF forever

Old vendors often remain authorized long after the business stops using them. That makes the record harder to understand and can create technical problems. Review the sending inventory periodically and remove obsolete sources.

Treating SPF alone as anti-spoofing

SPF by itself does not solve visible From-address impersonation. Microsoft explicitly recommends using SPF together with DKIM and DMARC for stronger protection. The three controls are complementary.

Publishing DMARC but leaving it permanently at monitoring

A monitoring policy is useful during implementation because it provides visibility without requesting enforcement. If the environment is clean and legitimate mail is aligned, however, leaving DMARC indefinitely in monitoring mode gives up much of the anti-spoofing benefit.

Forgetting third-party senders

This is probably the most operationally important failure. SaaS platforms frequently send invoices, alerts, newsletters, appointment reminders, or automated workflows as the business. Each service needs to be evaluated rather than blindly added to DNS.

Assuming authentication guarantees delivery

Passing SPF, DKIM, and DMARC is not a promise that a message will reach the inbox. Spam filtering, sender reputation, content, recipient policies, and other signals still affect delivery. Authentication establishes legitimacy; it does not override every other mail-security decision.

What should a small business ask its IT provider?

You do not need to become a DNS specialist. You should be able to get clear answers to a few questions:

• Which systems are currently authorized to send mail for our domain?
• Do we have exactly one valid SPF policy?
• Is DKIM enabled for our primary mail platform and important third-party senders?
• Is DMARC published, and what policy is currently in effect?
• Who receives or reviews DMARC reports?
• Are old or unknown sending services still authorized?
• If we are not at DMARC enforcement, what is preventing us from getting there?

For a tax or accounting firm, this review also fits naturally into the broader security program. Email is one of the main ways employees communicate with clients and receive sensitive requests, so domain protection should sit alongside MFA, access controls, endpoint security, training, and the firm's written security plan.

The same principle applies to healthcare organizations and other professional services: email authentication is one control within a managed environment, not a substitute for cybersecurity or good operational practices.

Email authentication should be maintained, not merely installed

The configuration can drift as the business changes. A new marketing platform gets introduced. A billing system starts sending statements. A website is rebuilt. An old provider is retired. Someone changes DNS during a migration.

That is why email authentication belongs inside ongoing IT management. New sending services should be reviewed before they go live, and obsolete services should be removed rather than accumulating indefinitely.

The end state is straightforward: legitimate business mail authenticates consistently, unauthorized sources cannot easily impersonate the domain, and somebody is responsible for noticing when that changes.

Authoritative guidance

• CISA: Phishing Guidance — Stopping the Attack Cycle at Phase One
• Microsoft: How email authentication works in Microsoft 365
• Microsoft: SecOps guide for email authentication