Email Spoofing Checklist: SPF, DKIM, and DMARC for Small Offices

This is a records check, not a full email security program.

Three short DNS records, SPF, DKIM, and DMARC, tell other mail systems which messages really come from your business domain. Below: what each does, how to see if yours exist, and how to tighten DMARC without bouncing your own invoices.

It's for an owner or office manager at a business of about 5 to 50 people on Microsoft 365 or Google Workspace. The lookup takes about 20 minutes. Fixing gaps is usually a ticket for whoever runs your DNS.

How can a small business tell if its email domain is protected from spoofing? Look up three records for your domain: an SPF record, a DKIM record for each service that sends mail as you, and a DMARC record. Then list every service that sends email as your domain and confirm each one is covered. After reading the reports, move DMARC from monitoring to enforcement in small steps.

What the three records do

Microsoft's email authentication overview describes these records as standards that verify a sender, and it names the problem plainly: "Spoofed senders are commonly used in business email compromise (BEC), phishing, and other email attacks."

• SPF (Sender Policy Framework) is a list of the servers allowed to send mail for your domain. Google's SPF setup page puts it this way: "When receiving servers get email messages from your domain, they check the SPF record to verify that the messages came from authorized servers."
• DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. Google's DKIM setup page explains: "Receiving servers use your public DKIM key to read the DKIM signature and authenticate messages they get from your domain."
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the address people actually see and tells receivers what to do when a message fails. Google's DMARC setup page says: "The action options are reject, quarantine, or deliver the message." Its reports show senders you forgot about.

SPF on its own checks a behind-the-scenes address, not the From line. Microsoft's overview says: "SPF doesn't consider the domain in the From address or alignment between the MAIL FROM and From domains." DMARC connects them. That's why all three belong together.

What these records don't cover

DMARC reduces spoofing of your exact domain. It doesn't stop lookalike domains, such as a name one letter off from yours. That domain has its own records. It also doesn't stop display-name spoofing, where a sender shows a trusted name over an unrelated address. It also doesn't help when a real mailbox is taken over. Keep MFA and the habit of confirming payment changes by phone.

Step 1: Look up your records (10 minutes)

Option A: ask your IT host. Send one line: "Please send me our current SPF, DKIM, and DMARC records for each domain we send email from, and the DMARC policy we're at."

Option B: check it yourself. The records are public. Google's SPF page says, "To check if SPF is already set up for your domain, use one of many free tools available on the internet," and its DMARC page says the same for DMARC. Your admin console also shows status:

• Microsoft 365: the DKIM status for each custom domain is in the Microsoft Defender portal, per Microsoft's DKIM configuration guide.
• Google Workspace: the DKIM page in the Google Admin console shows whether signing is on, per Google's DKIM setup page.

What you're looking for:

• An SPF record starting with v=spf1. Microsoft 365 records usually contain include:spf.protection.outlook.com. Google Workspace records usually contain include:_spf.google.com.
• DKIM signing turned on for your own domain, not just the default one.
• A record at _dmarc.yourdomain.com starting with v=DMARC1, and its p= value: none, quarantine, or reject.

One Microsoft 365 trap: DKIM signing for your own domain isn't automatic. For custom domains, Microsoft's DKIM guide says, "Currently, no DKIM signing occurs for outbound mail from custom domains," and lists the steps to turn it on. For the domain on your business cards, DKIM signing has to be set up, and it's worth asking your IT host to confirm it's on.

Step 2: List everyone who sends as you (10 minutes)

Most small offices skip this step, and it's where DMARC rollouts break. Your email platform isn't the only thing sending from your domain. Write down every service that does:

• Microsoft 365 or Google Workspace mailboxes
• Invoicing, accounting, and payroll tools
• Marketing and newsletter tools
• Your website's contact form, booking tool, or store
• Copiers or scanners that email PDFs

Google's DMARC page adds that for third-party senders "you must make sure that messages sent by third-party services are authenticated and pass SPF and DKIM checks: Contact your third-party provider to make sure SPF and DKIM are correctly set up."

Each vendor publishes its own SPF and DKIM steps, often under "domain authentication."

Two rules in Microsoft's SPF configuration guide trip up small offices. First, "only one SPF record is allowed per domain or subdomain," so a new tool joins the existing record. Second, Microsoft says to keep SPF to "fewer than 10 DNS lookups," and each include uses some. If you have many tools, ask your IT host to check the count.

Step 3: Tighten DMARC in stages

Don't jump straight to p=reject. If a forgotten invoicing tool isn't covered, its mail bounces or lands in spam. Customers may never tell you.

Microsoft's DMARC guide says: "A gradual approach to setting up DMARC for your Microsoft 365 domains is recommended."

A staged path:

1. Start at p=none with reports turned on. Mail is delivered as usual, and you get reports on who's sending as you. Google's DMARC rollout page says: "One week is usually enough time for the daily reports to contain data representative of all your mail streams." Consider waiting a full billing cycle so monthly invoices show up.
2. Fix anything legitimate that fails. Each unknown sender in the report is either a tool from your Step 2 list that needs SPF or DKIM, or someone who shouldn't be using your name.
3. Move to p=quarantine for a small share of mail. Google's rollout page says: "After monitoring DMARC reports for at least a week and seeing no issues with your outgoing email, move to a quarantine policy for a small percentage of messages: Messages that don't pass DMARC go to the recipient's spam folder." Raise the percentage in steps.
4. Move to p=reject last, after quarantine at full coverage has run cleanly. Microsoft's guide points to reject as the end state, with testing "along the way."

Reports are machine-readable files. Google notes "You can receive many reports every day." Ask your IT host who will review them. Some reporting tools are paid.

Plan and licensing notes

• All three records live in DNS, at your registrar, web host, or IT provider. Whoever controls that account makes the change.
• Custom-domain DKIM is a setting in Microsoft 365 and Google Workspace. Google says after adding a key, "it can take up to 48 hours for DKIM authentication to start working."
• Some third-party senders limit custom-domain DKIM to certain plans. Check with each vendor.

Where the government guidance fits

CISA's BOD 18-01, Enhance Email and Web Security, issued October 16, 2017, required federal agencies to adopt these records and reach a DMARC policy of reject. It's a federal-agency baseline, not a requirement for private businesses. CISA calls a binding operational directive "a compulsory direction to federal, executive branch, departments and agencies." When we checked, the page was live and not marked archived or revoked. It still dates from 2017. Even for agencies, it required setting p=none within 90 days, ahead of moving to reject.

NIST's SP 800-177 Rev. 1, Trustworthy Email, is the deeper technical reference. NIST says it "applies to federal IT systems and will also be useful for small or medium sized organizations." It's written for your IT host.

Printable email authentication check

Check date: YYYY-MM-DD · Domain(s): · Checked by:

If something is missing

That's common. Don't edit DNS during the check. Send each gap to your IT host as a ticket.

The IT-host renewal card is a good place to add "Who owns our DNS records?" as a standing question.

Related guides

• Microsoft 365 admin hygiene checklist: who has admin power in the tenant where DKIM gets turned on
• Ask your IT host these 8 questions: where these tickets go at renewal
• Houston SMB security gaps mapped to CISA fixes: row 7 covers reporting suspicious email
• Monthly Update Day patch routine: another monthly check to pair with a DMARC report review
• MFA coverage drill: the layer that helps when a real mailbox is the problem
• Resources: CISA and NIST references

Educational content only — not legal, insurance, or compliance advice.