Email Authentication for SMBs: SPF, DKIM, and DMARC

If your customers or partners sometimes mark your mail as junk—or worse, someone sends mail that looks like it came from you—the problem often sits in DNS, not in Outlook settings.

SPF, DKIM, and DMARC are email authentication records. Together they help receiving servers decide whether a message claiming to be from your domain is allowed to use that name. For San Antonio and Hill Country businesses, this is practical hygiene: invoices, quotes, and password resets all ride on trust in your domain.

You do not need to become a DNS engineer. You do need a clear picture of what each piece does and which mistakes we see over and over.

What each record does

SPF (Sender Policy Framework)

SPF is a public list—published as a DNS TXT record—of servers allowed to send mail for your domain. When another company receives a message from you@yourcompany.com, it can check: “Did this come from an IP your SPF record allows?”

If you send through Microsoft 365, Google Workspace, a marketing platform, and a postage meter or scanner that emails PDFs, each of those senders may need to appear in SPF (or be covered by a provider you already include).

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to outgoing messages. The receiving server uses a public key in your DNS to verify the signature. If the message was altered in transit, or signed with the wrong key, the check fails.

Think of SPF as “which mail trucks are allowed” and DKIM as “this package still has the original seal.”

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receivers what to do when checks fail: monitor only, quarantine, or reject. It also lets you request reports so you can see who is sending as your domain—including systems you forgot about.

DMARC is where policy lives. SPF and DKIM are the building blocks. Without a DMARC policy, receivers have less guidance, and you get less visibility.

Common misconfigurations we see

Multiple SPF records. DNS should have one SPF TXT record for the domain, combining mechanisms into a single string. Two separate SPF records often mean receivers treat SPF as broken. Merging carefully matters more than adding another line “just in case.”

Soft-fail forever. An SPF ~all (soft fail) or a DMARC p=none policy is a fine place to start while you inventory senders. Staying there forever means forged mail may still land in inboxes. The goal is to move toward stronger handling once legitimate senders are covered—not to set “monitor only” and forget it.

Forgotten senders. Payroll, CRM mailers, survey tools, and that old web form host still send as @yourcompany.com. They break SPF/DKIM until you include them or stop using them.

DKIM never enabled. The Microsoft 365 or Google admin toggle was left off, or the selector published in DNS does not match what the mail server signs with. SPF alone is not the full story.

DMARC reports ignored. Guaranteed noise at first. Still useful. Reports show the gap between “we think we know our senders” and reality.

None of this requires inventing scary inbox volumes. One confused customer about a fake invoice is enough motivation.

Authentication is one layer, not the whole stack

Healthy email security for a small business usually stacks three things:

  1. Filtering — spam and malware screening on the way in (and sometimes on the way out)
  2. Authentication — SPF, DKIM, and DMARC so your domain is harder to abuse and easier to trust
  3. Habits — how people verify payment-change requests, share files, and report odd messages

Skip any one layer and the others work harder. Fancy filters do not fix a domain anyone can spoof. Perfect DNS does not stop someone from clicking a bad link in a well-authenticated message from a compromised mailbox. Training without technical basics leaves you playing whack-a-mole.

AEH’s view is boring on purpose: get the records right, keep filters current, and keep human checks simple enough that busy people will use them.

A practical order of operations

For most SMBs on Microsoft 365 or similar:

  1. Inventory who sends mail as your domain (office suite, website, billing, marketing)
  2. Publish or correct a single SPF record that covers those senders
  3. Turn on DKIM at the provider and publish the DNS keys
  4. Add DMARC at p=none with a reporting address so you can see results
  5. Fix gaps the reports reveal, then tighten policy when traffic looks clean

Do this during a quiet window, not the morning of a big customer mailing. Changes are usually quick; patience for DNS to settle and for reports to arrive is the real schedule.

Where AEH fits

Email authentication sits inside broader Microsoft 365 and security hygiene—DNS, admin consent, mailbox rules, and backup of critical mail. When AEH manages or reviews an environment, we treat SPF/DKIM/DMARC as standard checklist items, not optional extras for enterprises only.

If your domain has grown organically—new tools added over years with no DNS owner—an email security review is often the fastest way to see what is actually sending in your name.

Next step

Curious whether your SPF, DKIM, and DMARC setup matches how you really send mail? AEH Solutions can review it as part of an email security check or a free IT assessment for San Antonio and Hill Country businesses.

Request your free IT assessment or contact us when you are ready. We will explain findings in plain language and leave you with clear next steps—not a pile of acronyms.

Scroll to Top