DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

How to Set Up DMARC for Small Business From Scratch

By DMARCGuardian Editorial Team ·

Why small businesses need DMARC

If you run a small business, you probably send email from your own domain: info@yourcompany.com, support@yourcompany.com, invoices@yourcompany.com. That makes you a target.

Email spoofing is cheap and easy. Anyone can send mail that appears to come from your domain. Most of it is phishing. Some of it is invoice fraud. A convincing email from your domain lands in a customer's inbox, asking them to update payment details. That is not a hypothetical - it happens to small businesses regularly.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the email security layer that stops this. It tells receiving mail servers whether to accept, quarantine, or reject mail that claims to come from your domain but does not come from your actual email system.

Without DMARC, spoofed mail from your domain has a good chance of reaching people's inboxes. With DMARC set to reject, it does not.

The good news: you do not need to be a security expert to set this up. You need a clear sequence and some patience. Here is that sequence.

What you need before DMARC: SPF and DKIM in plain terms

DMARC builds on two older authentication methods: SPF and DKIM. Think of them as checks that happen before DMARC gets involved.

SPF (Sender Policy Framework) tells the world which mail servers are allowed to send email from your domain. You publish an SPF record in your DNS. Receiving servers check it when mail arrives. If the sending server is not on the list, the mail fails SPF.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outbound mail. Receiving servers verify that signature against your public key in DNS. If the signature does not verify, the mail fails DKIM.

DMARC sits above both. It checks whether the mail passed SPF and DKIM, and whether those results align with the domain that appears in the From address. A mail can pass SPF and DKIM individually but still fail DMARC if the domains do not align.

The correct order is: SPF first, then DKIM, then DMARC. Skip SPF or DKIM and DMARC has nothing meaningful to check.

How to check if you already have SPF and DKIM

Before you add anything, check what you already have. Run these lookups using any public DNS lookup tool or the dig command:


dig TXT yourdomain.com +short | grep SPF
dig TXT default._domainkey.yourdomain.com +short

If you see an SPF record in the first result, you have SPF configured. If you see a DKIM record in the second, you have DKIM configured.

If you use Microsoft 365 or Google Workspace, both platforms publish SPF automatically when you set up your domain. DKIM is usually off by default and needs to be enabled manually in the admin panel. Both platforms have step-by-step guides for this.

Step 1: Set up or fix SPF

If you do not have an SPF record, you need one. If you have one but it is broken or incomplete, you need to fix it.

A basic SPF record for a single email platform looks like this:


v=spf1 include:_spf.youremailprovider.com ~all

The v=spf1 identifies it as an SPF record. The include: pulls in the SPF rules for your email provider. The ~all means "soft fail" - mark mail that does not match as suspicious but still accept it. When you are ready, you will change this to -all for hard fail.

If you use multiple email sending services (your main platform plus a marketing tool or CRM), your SPF record needs an include for each one. Be careful not to exceed the 10 DNS lookup limit - SPF records that require more than 10 lookups fail silently and break your email.

Step 2: Set up or fix DKIM

DKIM is a digital signature. Your email platform generates a private key, signs outgoing mail automatically, and publishes the public key in DNS for receiving servers to verify.

In Microsoft 365, you enable DKIM through the Exchange admin center or Microsoft Entra. In Google Workspace, you enable it in the Admin console under Apps > Google Workspace > Gmail > Authenticate email. Both platforms give you a DKIM record to add to your DNS.

The record looks like this:


selector._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=yourpublickey..."

The selector is a name you choose (often "default"). Your email platform tells you what to use. Publish the record, wait a few minutes for DNS to propagate, then use your platform's built-in test or a public DKIM checker to confirm it is working.

Step 3: Create your first DMARC record

Now you add DMARC. Start with p=none. This tells receiving servers to do nothing with mail that fails DMARC - but you will start receiving aggregate reports that tell you exactly what is passing and failing. This is the monitoring phase.

Your first DMARC record:


_dmarc.yourdomain.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"
  • v=DMARC1 - version, always DMARC1
  • p=none - policy at monitoring-only for now
  • rua - aggregate report destination (DMARCFlow can collect and display these reports for you)
  • pct=100 - apply to 100% of mail (you can start with pct=0 during testing if you prefer)

Add this as a TXT record at _dmarc.yourdomain.com (the subdomain, not the root domain).

Wait 24 to 48 hours for reports to arrive. Most large email providers (Google, Microsoft, Yahoo) send aggregate reports daily.

Understanding DMARC reports: what they tell you

DMARCFlow collects and parses these reports for you, so you get a daily summary instead of hunting through raw XML attachments.

A good DMARC monitoring tool parses these reports and shows you:

  • Which sending sources are passing DMARC and which are failing
  • The failure reason (SPF alignment failure, DKIM alignment failure, or both)
  • Which receiving domains are accepting or rejecting your mail
  • Evidence of spoofing attempts from third parties

When you first enable DMARC, expect to see failures. These are normal. Common causes:

  • Email forwarded from your domain to a mailing list (the forwarding server rewrites the From address, breaking alignment)
  • Legacy systems or IoT devices that send mail from your domain but do not use your main mail server
  • CRM or marketing platforms that send on your behalf without proper DKIM signing

The goal in the monitoring phase is to identify all your legitimate sending sources, make sure each one passes DMARC, and reduce the failure rate to near zero before you move to a stricter policy.

How to safely move from p=none to p=quarantine

Once your aggregate reports show near-zero failures for at least two weeks, you can tighten the policy. Move to p=quarantine:


_dmarc.yourdomain.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

p=quarantine tells receiving servers to treat failing mail as suspicious - it typically goes to the recipient's spam folder rather than being rejected outright. This is a safer intermediate step than jumping straight to p=reject.

During the quarantine phase, watch your reports closely for two to four weeks. If legitimate mail starts landing in spam, something in your sending infrastructure has changed and needs to be fixed before you can proceed.

How to safely move from p=quarantine to p=reject

When quarantine shows no issues with legitimate mail, move to p=reject:


_dmarc.yourdomain.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

p=reject is the strongest protection. Receiving servers refuse to deliver any mail from your domain that fails DMARC. Spoofed mail is blocked at the door.

Even at p=reject, keep monitoring. DMARC reports are your early warning system. A sudden spike in failures often means a vendor changed something in their sending infrastructure, a new internal system was added, or an attacker is testing your domain.

What happens if something breaks

DMARC misconfiguration is a common cause of email delivery problems. The most frequent issues:

SPF alignment failure after changing mail servers - If you switch your email platform, update your SPF record before the cutover. An outdated SPF record causes legitimate mail to fail.

DKIM signature breaks after DNS migration - DKIM keys are stored as DNS records. If your DNS migration does not preserve DKIM records, all outgoing mail fails DKIM signing. Verify DKIM after any DNS change.

Forwarding breaks DMARC - When mail is forwarded, the forwarding server may rewrite the From address to its own domain, breaking alignment. This is a known limitation. Solutions include using ARC (Authenticated Received Chain) or using a dedicated subdomain for forwarding-prone communications.

Third-party senders fail DMARC - Any service that sends mail from your domain needs its own DKIM key and SPF entry. If you use a CRM, invoicing tool, or any other platform to send from your domain, it must be configured for DMARC alignment.

The fastest way to diagnose a new email problem is to check your DMARC reports. They tell you exactly which sources are failing and why.

How DMARCFlow makes ongoing management easier

Reading raw DMARC aggregate reports is not practical for most small businesses. The XML format is dense, reports arrive at unpredictable intervals from each receiving provider, and the data is hard to action without a tool.

DMARCFlow parses your aggregate reports daily and presents the findings in plain language. You see at a glance which sources are passing, which are failing, and whether the failure rate is changing. When a new sending source starts failing, you get an alert before it becomes a customer-facing problem.

For small businesses without a dedicated IT person, this matters. You set up DMARC once, and DMARCFlow handles the ongoing monitoring. When something needs attention, you hear about it. When everything is working, you do not have to think about it.

FAQ

What is the minimum DMARC setup for a small business?

At minimum: an SPF record, a DKIM record, and a DMARC record set to p=none. This gives you visibility into your email authentication with no risk to delivery.

How long does DMARC setup take?

You can set up your first DMARC record in under an hour. The monitoring phase (p=none) typically lasts two to four weeks while you identify and fix failures. Moving to p=quarantine and then p=reject each requires two to four weeks of clean reports before advancing.

Does DMARC affect my regular email sending?

No. As long as your email passes SPF and DKIM alignment with your own mail servers, DMARC does not affect legitimate mail. Only failing mail is impacted.

Can I set up DMARC without a monitoring tool?

Yes, but you will receive raw XML aggregate reports directly in your inbox. Most small businesses find these difficult to interpret. A monitoring tool converts them into a daily summary that tells you what matters.

What does p=none mean?

p=none is monitoring-only mode. Mail that fails DMARC is still delivered. You receive reports but take no action. It is the correct starting point before tightening your policy.