What Email Authentication Records Do Small Businesses Need in 2026

What Email Authentication Records Do Small Businesses Actually Need in 2026

If you run IT for a small business and someone tells you to "set up SPF, DKIM, and DMARC," you are not alone. Most guides on this topic are written for enterprises with dedicated email security teams. This one is for the rest of us.

Here is the short answer: SPF and DKIM are required for any business sending email. DMARC is strongly recommended and becoming expected. Everything else - BIMI, MTA-STS, ARC - is optional for most small businesses.

Now the longer answer.

Why Email Authentication Matters for Small Businesses

You might think email authentication is something only big companies worry about. That is not true. Small businesses are frequent targets of email spoofing precisely because attackers assume smaller organizations have weaker controls. If a criminal wants to send phishing emails that appear to come from a credible small business, they will look for domains without proper authentication.

The consequences are not abstract. Spoofed emails that appear to come from your domain can be used to phish your customers, your vendors, or your own employees. Those emails damage your reputation even if they do not originate from your servers. Email authentication does not prevent all of that, but it makes it significantly harder and gives receiving mail systems a reason to reject suspicious mail.

SPF - What It Does and Why You Need It

SPF stands for Sender Policy Framework. It is a DNS record that tells receiving mail servers which servers are allowed to send email for your domain.

If your business uses Microsoft 365, the SPF record tells the world that only Microsoft's servers are authorized to send email from your domain. When a receiving server gets an email from your domain, it checks your SPF record. If the sending server is not on the list, the email is treated as suspicious.

The basic SPF record for Microsoft 365 looks like this:


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

If you also send marketing email through Mailchimp or another third-party platform, you add their servers to the same record. The challenge most small businesses run into is adding too many includes, which can push you over the 10 DNS lookup limit that SPF allows. Exceed that limit and SPF breaks silently, which is one of the most common misconfigurations I see in practice.

How to check your current SPF record: use a free DNS lookup tool and look for a TXT record starting with v=spf1.

DKIM - The Signature That Proves Your Email Is Real

If SPF says which servers are allowed to send, DKIM says the email has not been tampered with in transit. It works by cryptographically signing the email with a private key. Receiving servers use the public key published in your DNS to verify the signature.

Microsoft 365 enables DKIM by default for your primary domain, but you often need to set it up manually for custom domains you use for sending. Third-party platforms like Mailchimp each have their own DKIM configuration, which is separate from your domain's main DKIM setup.

The important distinction for small businesses: your domain can have multiple DKIM records from different senders. Microsoft 365 has one. Mailchimp has another. That is normal and fine.

How to check: run a DNS lookup for selector1._domainkey.yourdomain.com. If you get a DKIM record back, DKIM is configured for that selector.

DMARC - The Record That Tells Receivers What To Do With Failures

DMARC builds on SPF and DKIM. It does two things SPF and DKIM alone cannot do: it tells receiving servers what to do when authentication fails, and it lets you receive reports about authentication results.

The DMARC record sits in your DNS as a TXT record at _dmarc.yourdomain.com. It has three policy options:

p=none: monitor only. You get aggregate reports about who is sending email for your domain, but receivers take no action on failures. This is where most small businesses start.
p=quarantine: receivers treat emails that fail authentication as suspicious and move them to spam or quarantine.
p=reject: receivers reject emails that fail authentication outright. This is the strictest setting and the end goal for most organizations.

Most guides tell small businesses to move to p=reject as fast as possible. That advice is too aggressive. Moving to p=reject before you have resolved alignment issues will break legitimate email from vendors, partners, or internal systems that send on your behalf but do not authenticate correctly.

The recommended path for a small business: start with p=none, review your aggregate DMARC reports for 30 to 60 days, fix the legitimate senders that are failing, then move to p=quarantine. Only move to p=reject when quarantine is clean.

This is where most small businesses get stuck. DMARC aggregate reports arrive as XML files full of authentication results, disposition states, and DKIM alignment data. Reading them without tooling requires a skill most IT teams do not have time to develop. The result is that p=none monitoring becomes a box-ticking exercise instead of a diagnostic one. DMARCFlow parses those reports and shows which specific legitimate senders are failing and why, so the monitoring period produces actionable fixes rather than a folder full of unread XML.

BIMI - Your Logo in the Inbox

BIMI stands for Brand Indicators for Message Identification. It lets you display your company logo next to your emails in supporting mail clients. Gmail, Apple Mail, and other major providers support it.

The catch for small businesses: BIMI requires a Verified Mark Certificate (VMC), which costs money and requires a trademark registration in some jurisdictions. Some email platforms offer BIMI without a VMC using a self-signed certificate, but those are not supported by most major receivers.

If you have a trademark and want the visual credibility of BIMI, it is worth looking into. For most small businesses on a budget, it is a nice-to-have, not a need-to-have.

MTA-STS - Enforcing Encrypted Email Delivery

MTA-STS (Mail Transfer Agent Strict Transport Security) enforces TLS encryption when your domain receives email. Without MTA-STS, a receiving server can choose to deliver mail over an unencrypted connection. MTA-STS says: if you cannot deliver this email securely, do not deliver it at all.

This matters most for businesses handling sensitive communications - legal, medical, financial. For a typical small business, MTA-STS is worth knowing about but rarely urgent. It is also relatively easy to misconfigure in ways that cause mail delivery failures, so approach it carefully if your email setup is complex.

Common Mistakes Small Businesses Make with Email Authentication

These mistakes appear repeatedly across small business email setups.

SPF lookup limit exceeded. SPF allows a maximum of 10 DNS lookups in a single record. Every include:, redirect=, or a: directive counts as one. Small businesses that add includes for M365, Mailchimp, their website form, and a few other tools can easily exceed 10. When that happens, SPF validation returns a permanent error and receivers treat it as a failure. Use an SPF flattening service or consolidate your includes if you are approaching the limit.

DKIM keys not rotated after changing email vendors. When you switch from one email platform to another - say from Mimecast to Proofpoint, or from SendGrid to Mailchimp - you need to publish the new DKIM public key and remove the old one. Failing to do this is a common cause of suddenly broken email deliverability.

Third-party senders breaking DMARC alignment. If you send marketing email through Mailchimp using a custom domain, Mailchimp will DKIM-sign those emails with their own keys, not yours. Without DMARC alignment, those emails will fail DMARC when evaluated against your domain's policy. The fix is usually to ensure Mailchimp authenticates using your domain in their settings, not theirs.

No monitoring period before moving to p=reject. Jumping straight to p=reject without reviewing aggregate reports first is the fastest way to break legitimate email. At minimum, spend 30 days at p=none looking at what is actually failing and why.

FAQ

Do I need SPF, DKIM, and DMARC if I only send a few emails a day?

Yes. Authentication records protect your domain's reputation regardless of volume. Even if you send five emails a day, if someone spoofs your domain to send phishing emails to your customers, your domain can get blacklisted. Proper authentication makes spoofing harder and gives receivers a reason to reject spoofed mail.

I use Microsoft 365. Does that not already handle email authentication?

Microsoft 365 enables SPF automatically for its own sending. DKIM needs to be manually enabled for custom sender domains. DMARC is entirely separate and needs to be set up in your DNS. Using M365 covers your first-party sending but does not protect you from third parties spoofing your domain.

What happens if I skip DMARC?

Your domain remains a target for spoofing. Without DMARC, you also do not receive aggregate reports about who is sending email for your domain, which means you have no visibility into unauthorized use of your domain. Several major email providers are moving toward requiring DMARC for certain sending categories, so skipping it is increasingly a deliverability risk.

Can I set this up once and forget about it?

SPF and DKIM are relatively static, but they need to be reviewed when you change email platforms or add new sending tools. DMARC requires periodic review of aggregate reports, especially at the p=none stage. If you are at p=quarantine or p=reject, a monthly check of your DMARC reports is good practice.

My MSP says they have set up email authentication. How do I verify?

Run a free DMARC checker or DNS lookup for your domain. Check for an SPF TXT record, a DKIM record at selector1._domainkey.yourdomain.com, and a DMARC record at _dmarc.yourdomain.com. If any of these are missing or misconfigured, ask your MSP to fix them. Authentication setup is not complete until all three are in place.

What to Check First

If you are starting from zero, here is the priority order:

1. Check your current SPF record. If you do not have one, add it for your primary email platform first.
2. Check DKIM. In Microsoft 365, go to the Exchange admin center and verify DKIM is enabled for your sending domains.
3. Add a DMARC record at p=none. Yes, even if you do nothing else with it.
4. Review your first aggregate DMARC report after 7 to 14 days. Look for legitimate senders that are failing.
5. Fix alignment issues before moving to p=quarantine.
6. Move to p=quarantine when quarantine is clean, then reassess p=reject.

Email authentication is not a project you finish. It is a baseline you maintain. But getting the foundations right - SPF, DKIM, and a monitored DMARC record - takes you further than most small businesses and makes your domain significantly harder to impersonate.