How to Secure Your Business Email Against Spoofing with SPF, DKIM, and DMARC

SPF, DKIM, and DMARC are three DNS records that work together to prevent attackers from sending emails that appear to come from your business domain. Without them, anyone can send an email that looks like it came from you@yourcompany.com, and your clients, vendors, and employees have no way to tell the difference.

Why Email Spoofing Is a Serious Problem for Small Businesses

Spoofing means someone sends email pretending to be you or one of your employees. It is surprisingly easy to do. Without proper email authentication records, an attacker can send an invoice that appears to come from your CEO to your bookkeeper, requesting an urgent wire transfer. Or they can send emails to your clients that look like they came from your domain, damaging your reputation and trust.

Beyond the fraud risk, email deliverability is at stake. Google and Microsoft are increasingly blocking or flagging email from domains that lack proper SPF, DKIM, and DMARC records. If your domain does not have these records configured, your legitimate emails may end up in your clients' spam folders.

Setting up all three records is free (they are just DNS entries) and protects your domain from being used in phishing attacks against the people who trust your business.

Understanding the Three Records

Before diving into setup, here is what each record does in plain language:

SPF (Sender Policy Framework) tells receiving mail servers which servers are authorized to send email for your domain. Think of it as a guest list for your email. If an email claims to come from your domain but was sent from a server not on the list, the receiving server knows something is wrong.

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email, proving that the message was not tampered with in transit and that it actually came from your domain. Think of it as a wax seal on a letter. If the seal is broken, the recipient knows the message was altered.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication checks fail. You choose the action: do nothing (monitor only), quarantine the message (send it to spam), or reject it outright (block it). DMARC also sends you reports about who is trying to send email as your domain.

All three work together. SPF and DKIM verify the email is legitimate; DMARC tells the world what to do when it is not.

Step 1: Check Your Current Records

Before making changes, check what you already have in place. Go to MXToolbox.com and run a lookup on your domain. Check for SPF, DKIM, and DMARC records separately.

What you are likely to find: many small business domains have a partial or incorrect SPF record (often missing third-party senders), no DKIM signing enabled, and no DMARC record at all. If your results show all three configured correctly, you are ahead of most small businesses. If not, work through the steps below.

Another useful tool is dmarcian.com, which provides a more detailed analysis and ongoing monitoring.

Step 2: Set Up SPF

SPF is a TXT record added to your domain's DNS settings. You access DNS through wherever your domain is registered (GoDaddy, Namecheap, Cloudflare, etc.) or through your DNS hosting provider.

For businesses using Microsoft 365, the SPF record should be:

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

This tells receiving servers that Microsoft's mail servers are authorized to send email for your domain, and that all other servers should be rejected (-all).

If you use other services that send email on your behalf, such as Mailchimp for newsletters, QuickBooks for invoices, or a CRM that sends from your domain, you need to add their SPF includes to the same record. For example:

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

Important: you can only have one SPF record per domain. If you create a second one, both will break. Combine all authorized senders into a single record.

The difference between ~all (soft fail) and -all (hard fail): soft fail means "treat unauthorized senders as suspicious," while hard fail means "reject unauthorized senders." Start with -all if you are confident you have listed all legitimate senders. Use ~all temporarily if you are still identifying all services that send email as your domain.

Step 3: Set Up DKIM

DKIM requires generating signing keys and publishing them in your DNS. For Microsoft 365, this is done through the Microsoft Defender portal.

1. Go to security.microsoft.com.
2. Navigate to Policies & rules > Threat policies > Email authentication settings.
3. Select the DKIM tab.
4. Select your domain from the list.
5. Click Enable to turn on DKIM signing.
6. Microsoft will display two CNAME records that you need to add to your domain's DNS.

Copy those CNAME records and add them at your DNS provider. The records will look something like:

selector1._domainkey.yourcompany.com -> selector1-yourcompany-com._domainkey.yourcompany.onmicrosoft.com
selector2._domainkey.yourcompany.com -> selector2-yourcompany-com._domainkey.yourcompany.onmicrosoft.com

After adding the DNS records, wait for DNS propagation (this can take up to 48 hours, though it often completes much faster). Then return to the Defender portal and click Enable again to activate DKIM signing. If the DNS records have propagated, DKIM will turn on successfully.

A common mistake is adding the DNS records but forgetting to go back and enable DKIM signing in the portal. Both steps are required.

Step 4: Set Up DMARC

DMARC is another TXT record added to your DNS. Start with a monitoring-only policy so you can see what is happening before you start blocking anything.

Add this TXT record to your DNS at _dmarc.yourcompany.com:

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

Here is what each part means:

• v=DMARC1 identifies this as a DMARC record.
• p=none is the policy. "None" means do not take action on failed messages; just report them.
• rua=mailto:dmarc-reports@yourcompany.com is where aggregate reports will be sent.

The p=none policy does not block anything, but it starts sending you reports about who is sending email as your domain. This is the discovery phase, and it is essential. Skipping straight to a blocking policy risks blocking legitimate email from services you forgot about.

After monitoring for 2 to 4 weeks and reviewing your reports, move to p=quarantine. This sends suspicious emails (those failing SPF and DKIM checks) to the recipient's spam folder instead of their inbox.

Once you are confident that all legitimate senders are properly authenticated, move to p=reject. This is the final goal. With a reject policy, spoofed emails claiming to come from your domain are blocked entirely and never delivered.

Step 5: Monitor DMARC Reports

DMARC sends XML report files to the email address specified in your rua= tag. These reports are dense and difficult to read in raw format. Use a free tool like dmarcian, Valimail, or DMARC Analyzer to parse and visualize them.

What to look for in your reports:

• Legitimate services failing authentication. If your CRM or invoicing software is sending email as your domain but is not included in your SPF record, it will show up as a failure. Add it to your SPF record.
• Unknown senders spoofing your domain. If you see emails being sent from your domain by servers you do not recognize, someone is spoofing you. This is exactly what DMARC is designed to catch.
• The overall pass rate. As you add legitimate senders to SPF and enable DKIM, your pass rate should climb toward 100%.

Review reports weekly during the first month, then monthly once your configuration is stable. Microsoft Defender for Office 365, included with Microsoft 365 Business Premium, also provides email authentication insights in the Defender portal that complement your DMARC reports.

Common Mistakes

These are the issues we see most often when small businesses set up email authentication:

• Multiple SPF records. Only one SPF TXT record is allowed per domain. If you add a second one, both fail. Combine all authorized senders into a single record.
• Jumping to DMARC p=reject before monitoring. This blocks legitimate email from services you forgot to authorize. Always start with p=none, review reports, then move to p=quarantine, and finally p=reject.
• Forgetting third-party senders. Your CRM, invoicing software, marketing platform, and ticketing system may all send email as your domain. Each one needs to be included in your SPF record.
• Adding DKIM DNS records but not enabling signing. The CNAME records in DNS are only half the setup. You must also enable DKIM signing in the Microsoft Defender portal.

Need Help?

Email authentication involves DNS changes that can affect your email deliverability if done incorrectly. If you are not comfortable making DNS changes yourself, or if you want someone to handle the full SPF, DKIM, and DMARC setup and monitoring, contact Athencia. We configure email authentication for small businesses regularly and can have it done correctly in a single session.