Guide

SPF, DKIM and DMARC for small businesses

Reviewed by Alex Rusakovich, Founder ·

SPF, DKIM and DMARC are three DNS records that prove email from your domain really came from you. SPF lists the services allowed to send mail as your domain. DKIM adds a signature to each message that receiving servers check against a public key in your DNS. DMARC ties both checks to the address people see in the From line, tells receiving servers what to do with mail that fails, and sends you reports. A small business should set them up in that order. Publish one SPF record that covers every service that sends your mail. Turn on DKIM in your email platform and in every other service that sends as you. Add DMARC at p=none with a report address, read the reports for a few weeks and fix any real sender that fails. Then move to p=quarantine and finally p=reject. The result is fewer fake messages in your name and real mail that receivers trust.

What do SPF, DKIM and DMARC actually do?

Think of a front desk checking visitors.

  • SPF is the guest list. It is one TXT record in your DNS that names the servers allowed to send mail for your domain. A receiving server checks whether the message came from one of them (Microsoft: set up SPF). The standard is RFC 7208.
  • DKIM is the sealed envelope. Your email service signs each message with a private key, and the matching public key sits in your DNS. The receiver checks the signature, which shows the message came from your domain and wasn’t changed on the way. The standard is RFC 6376.
  • DMARC is the house rule. It checks that SPF or DKIM passed for the same domain shown in the From line. A message passes DMARC if either check passes and matches (Microsoft: set up DMARC). Your DMARC record also says what to do with mail that fails (none, quarantine or reject) and where to send reports. The current standard is RFC 9989, published in 2026.

Why does a small business need all three?

Without DMARC, anyone can put your domain in the From line of a fake invoice, and receiving servers get no instruction from you about it. Microsoft describes these records as protection against the spoofed senders used in business email compromise and other phishing (Microsoft: set up DMARC).

Delivery is the other reason. Gmail requires every sender to use SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail addresses must use SPF, DKIM and DMARC (Google: email sender guidelines). Most small offices never reach that volume, but the bulk-sender rules are a sensible baseline for everyone.

What do you need before you start?

  • Access to your DNS, wherever your domain’s records are managed.
  • A list of everything that sends email as your domain. Think beyond Outlook or Gmail: website contact forms, invoicing and accounting software, newsletters, your CRM, scheduling tools, copiers that scan to email, and phone systems that send voicemail by email. A forgotten sender is the usual reason real mail fails later.
  • A place for DMARC reports. Use a dedicated mailbox or a reporting service, not one person’s inbox. Microsoft recommends the same.

In what order should you set them up?

All records below are examples only. Replace example.com with your domain and copy exact values from your own providers.

  1. Publish SPF. List your main email platform and every other sender in one record.

    Example only, Microsoft 365 as the only sender:
    v=spf1 include:spf.protection.outlook.com -all

    Example only, Google Workspace as the only sender:
    v=spf1 include:_spf.google.com ~all

    Two rules matter. A domain can have only one SPF record; two records make SPF fail with an error. And SPF allows no more than 10 DNS lookups, where every include: counts at least once (Microsoft: set up SPF). Microsoft recommends ending with -all, while Google recommends ~all (Google: set up SPF). We follow the main email provider’s advice.

  2. Turn on DKIM. On Microsoft 365, you publish two CNAME records, selector1._domainkey and selector2._domainkey, with the exact values Microsoft shows you, then enable signing (Microsoft: set up DKIM).

    Example only (your value will differ):
    selector1._domainkey CNAME selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft

    On Google Workspace, you generate a key in the Admin console, publish it as a TXT record at google._domainkey, wait, then click Start authentication. Google says it can take up to 48 hours to start working (Google: set up DKIM). Then ask each other sender, such as your newsletter or invoicing tool, how to sign with your domain. Most give you a CNAME or TXT record to add.

  3. Add DMARC at p=none. Google advises letting SPF and DKIM run for at least 48 hours first (Google: set up DMARC).

    Example only, host _dmarc, TXT value:
    v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

    With p=none, nothing changes for delivery. You just start getting reports. They arrive as compressed XML files, typically once a day from each mail provider that sends them, so a reporting service or tool makes them readable. If the report address is on a different domain, that domain must publish a record allowing it. Reporting services handle this for you.

  4. Read the reports for a few weeks. For each sending source, ask one question: is this ours? If it is yours and failing, fix that sender’s SPF entry or DKIM signing. If it isn’t yours and failing, that is someone sending fake mail in your name. DMARC will deal with it once you enforce. The standard itself says domain owners usually start at p=none and fix gaps before moving on (RFC 9989).
  5. Move to quarantine, then reject.

    Example only:
    v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

    After a clean period on quarantine:
    v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

    Microsoft’s recommended rollout also ends at p=reject, one cautious step at a time (Microsoft: set up DMARC). Older guides, including some vendor pages, add pct= to phase this in. RFC 9989 removed that tag, so we leave it out.

How do you check that it’s working?

Send a message from each sender to a Gmail address and open “Show original.” You want SPF, DKIM and DMARC to show PASS for your own domain. When we moved our own email in October 2026, our test after turning on DKIM showed a DKIM pass for our domain, where before the switch the signature carried the tenant’s .onmicrosoft.com name. Google notes you can’t confirm its DKIM by emailing yourself, so send to someone outside your domain.

What are the common mistakes?

  • Two SPF records, often left over after changing email providers.
  • An old provider’s include left in place. Ours still named GoDaddy’s servers until we cleaned it up.
  • Too many includes, which pushes SPF past 10 lookups.
  • Forgotten senders, such as the website form or the invoicing tool.
  • Jumping straight to p=reject before reading reports, so real mail bounces.
  • Reports going to an inbox nobody reads.
  • Unused domains left open. For a domain that never sends mail, Microsoft suggests v=spf1 -all and a DMARC record of v=DMARC1; p=reject; (examples only).

If your office runs on Microsoft 365, our Microsoft 365 support includes setting up and checking all three records. Email authentication is also part of our cybersecurity services, next to phishing filtering and staff training.

Need help?

Call us at (330) 741-1331, email support@compitservice.com or use our contact page. Not sure what your records say today? Our free security assessment checks your SPF, DKIM and DMARC records along with your accounts and email filtering, and you get the findings in writing.

Get your free assessment

Tell us what you need. We’ll get back to you within 24 hours.

(330) 741-1331 · support@compitservice.com

Scroll to Top