My IT ButlerVisit Website →
← Back to blog

Avoid Blocking Customers: DMARC Setup for Business Owners in 2–4 Weeks

September 11, 2026
Avoid Blocking Customers: DMARC Setup for Business Owners in 2–4 Weeks

Publish a DMARC TXT record at _dmarc with p=none and a rua reporting address, but only after you've confirmed SPF and DKIM are both passing. Watch the reports for several weeks, fix any legitimate sender that's failing, then step the policy up to quarantine and eventually reject. If parsing XML reports sounds like a chore, a reporting service or a managed rollout will do it for you.

TL;DR:

  • Confirm you can edit DNS and have a single SPF record that does not exceed ten lookups before publishing DMARC.
  • Ensure DKIM is enabled and aligned with your domain’s visible From address to prevent common message failures.
  • Use a rua address or a reporting service to monitor aggregate DMARC reports, especially when initially setting the policy to none.
  • Start with a p=none record, gradually increase enforcement to quarantine and reject over several weeks based on report insights.
  • Avoid rushing to full enforcement; focus on fixing sender misconfigurations identified through XML reports before blocking legitimate emails.
Myitbutler
Bring DMARC Under Expert Management
Myitbutler provides remote IT support, strategic planning, and proactive management for businesses handling complex international operations.
Visit Myitbutler

Table of Contents

What you need before touching DNS for your DMARC setup

Before you write a single DNS record, confirm four things. Skip any of these and you risk publishing a DMARC policy that either does nothing or, worse, silently blocks legitimate customer emails.

Confirm you can actually edit DNS. You need login access to whichever registrar or DNS host manages your domain, whether that's the same place you bought the domain or a separate provider your web team uses. If you're not sure who controls it, run a quick WHOIS lookup or ask whoever set up your website.

Check for an existing SPF record. Search your DNS for a TXT record starting with v=spf1. Many businesses already have one from years back, and duplicate SPF records are a common cause of authentication failures. You can only have one.

Enable DKIM in your mail platform. Most business email platforms, Google Workspace included, let you generate DKIM keys from an admin panel with a few clicks. If you run your own mail server, this means generating a key pair and publishing the public half as a DNS record.

Build a sender inventory. This is the step almost everyone underestimates. List every platform that sends email using your domain, not just your main inbox provider:

  • Your primary email platform (Microsoft 365, Google Workspace, or similar)
  • CRM and sales tools (HubSpot, Salesforce, Pipedrive)
  • Billing and invoicing software (Xero, QuickBooks, Stripe)
  • Marketing platforms (Mailchimp, Klaviyo, ActiveCampaign)
  • Support desks and helpdesk tools (Zendesk, Freshdesk, Intercom)
  • Any transactional email service tied to your website or app

Miss one of these and DMARC will flag it as a failure once you start enforcing, because that platform is sending as your domain without proper authentication. A quick way to catch stragglers you might have missed: search your own inbox for "sent on behalf of" or check your accounting software's outgoing email log. This inventory step matters more for business email security generally, not just DMARC, so it's worth doing properly once.

How do I verify SPF and DKIM are actually working?

Don't skip straight to publishing DMARC. If SPF and DKIM aren't configured correctly, your DMARC reports will show failures for mail that should be passing, and you'll waste weeks chasing ghosts.

  1. Look up your SPF record. Run dig TXT yourdomain.com (or use an online DNS checker if command lines aren't your thing) and confirm you see exactly one v=spf1 record. If you see two, that's your first fix, merge them into one.
  2. Count your SPF lookups. Each include: mechanism in your SPF record triggers a DNS lookup, and SPF caps out at 10 lookups total. Businesses using five or six different tools often blow past this limit without realising it, which produces a PermError and silently breaks SPF for everyone, according to mxio's DMARC deployment guide.
  3. Check your DKIM selector. Your mail platform's admin panel will show you the DKIM selector name (something like google._domainkey or s1._domainkey). Query it directly with dig TXT selector._domainkey.yourdomain.com and confirm a public key comes back.
  4. Confirm alignment. DMARC wants the domain in your DKIM signature (the d= tag) to match, or at least share a base domain with, your visible From address. Misaligned DKIM is one of the most common reasons DMARC reports show failures for mail that "should" be fine.

If a third-party sender genuinely can't sign with your domain's DKIM, ask them whether they support a custom MAIL FROM domain, or route that traffic through a subdomain you control instead.

Pro Tip: DKIM tends to survive email forwarding far better than SPF does, because the signature travels with the message itself rather than depending on the sending IP address. If your business relies on staff forwarding rules or mailing lists, prioritise getting DKIM rock solid first.

How do I verify SPF and DKIM are actually working? — overview diagram

Should you use a reporting mailbox or a reporting service?

Every DMARC record needs a rua tag, this is the address that receives aggregate reports summarising who's sending mail as your domain and whether it's passing authentication. These reports are the entire point of the exercise. Without them, you're flying blind on enforcement.

There's also a ruf tag for forensic reports, which include details on individual failed messages. In practice, most major mailbox providers don't send them, and the ones that do often strip identifying details for privacy reasons. Don't build your rollout plan around ruf. Treat aggregate reports as the essential piece.

For the mailbox itself, you have two realistic options:

  • Set up a dedicated address like dmarc@yourdomain.com and read the raw, gzipped XML reports yourself.
  • Use a reporting service that ingests the XML automatically and shows you a readable dashboard instead.

Most small businesses land on the second option once they see what a real XML report looks like, because manually parsing gzipped XML files every day isn't a good use of anyone's time. You can also list multiple rua addresses separated by commas if you want reports going to both an internal mailbox and a third-party tool. Expect report volume to scale with how much mail your domain sends. A business firing off a few dozen emails a day might get a handful of reports; one running large marketing campaigns could see dozens daily from different providers.

What does the DMARC TXT record actually look like?

The record itself lives at a specific DNS location and follows a specific syntax. Get either wrong and your DMARC policy simply won't be evaluated, per RFC 7489, the specification that defines all of this.

Add your record as a TXT entry at the host or name _dmarc (some DNS panels auto-append your domain, so you'd enter just _dmarc; others want the full _dmarc.yourdomain.com, check your provider's documentation if you're unsure). Only one DMARC record can exist per domain.

Here's what each tag does:

  • v — always DMARC1, identifies the record type
  • p — the policy: none, quarantine, or reject
  • sp — an optional subdomain policy, separate from your main policy
  • rua — the mailbox for aggregate reports (mandatory in practice)
  • ruf — the mailbox for forensic reports (optional, often ignored)
  • pct — what percentage of failing mail the policy applies to, useful for gradual rollout
  • fo — forensic report trigger options
  • aspf / adkim — alignment mode, strict (s) or relaxed (r)

A starter monitoring record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Once reports look clean, a partial enforcement record might read:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

And a full-enforcement record, once you're confident nothing legitimate is failing:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Setup speed check: publishing a basic monitor-mode record like the first example above takes about 15 minutes and costs nothing. The real work, reading reports and ramping enforcement, happens over the following weeks, not in that first sitting.

After publishing, give DNS propagation an hour or two, then check the record resolves with dig TXT _dmarc.yourdomain.com or a free online DMARC checker before you consider the job done.

How do I read DMARC reports and move to enforcement?

Aggregate reports arrive as XML files (or as readable summaries, if you're using a dashboard tool) listing every sending source, how much mail each one sent, and whether SPF and DKIM passed or failed for each. Your job is to map each failing source back to something in your sender inventory.

  1. Sort by volume first. Fix the sending sources responsible for the most mail before chasing small, occasional senders. A marketing platform sending thousands of emails a week deserves more urgent attention than a one-off invoicing tool.
  2. Match failing IPs to known services. Most reports include a reverse DNS hostname or organisation name alongside the IP address, which usually tells you straight away whether it's Mailchimp, your CRM, or something you genuinely don't recognise.
  3. Fix, then re-check. Add the missing SPF include or correct the DKIM configuration for that sender, then wait for the next reporting cycle (usually daily) to confirm it's passing.
  4. Ramp gradually. Google's guidance and most deployment frameworks agree on the same cadence: run p=none for two to four weeks minimum, move to p=quarantine with a low pct value like 10 or 25, and only reach p=reject once several consecutive reporting cycles show zero legitimate failures.

Use the pct tag to limit how much of your mail the stricter policy affects while you're still confident, and the sp tag if you want a different, often stricter, policy for subdomains that don't send mail at all.

Pro Tip: Schedule your move to p=quarantine or p=reject outside major campaign windows, product launches, invoicing runs, and the like. If something goes wrong, you want to be rolling it back on a quiet Tuesday, not during your busiest sales week.

Keep a rollback plan ready: reverting to p=none takes minutes and immediately stops any blocking, so there's no reason to treat enforcement as irreversible.

Why is legitimate mail failing DMARC, and how do you fix it?

Alignment failures are the most common headache, and they're usually diagnosable from the message headers alone. Open the raw source of a failing email and look at the Authentication-Results header. It'll tell you plainly whether SPF, DKIM, or both failed, and why.

  • Forwarding breaks SPF almost every time, because the forwarding server's IP doesn't match your SPF record. DKIM usually survives forwarding intact, which is another reason to prioritise it. Where forwarding is unavoidable, look into Authenticated Received Chain (ARC) support on the receiving side, or route through a service that preserves DKIM signatures.
  • Mailing lists that modify subject lines or footers often break DKIM signatures too, since any change to the signed content invalidates the signature.
  • SPF PermErrors almost always trace back to exceeding the 10 lookup limit. The fix is consolidating multiple include: statements or using an SPF-flattening tool that resolves nested includes into direct IP entries.
  • DKIM selector mismatches happen when a platform rotates its signing keys but your DNS record still points to the old selector. Check your mail platform's DKIM setup page for the current, active selector name.

If your setup involves staff working across multiple offices, VPNs, or remote connections, it's worth understanding how secure remote access fits alongside your email authentication, since both are part of the same broader security posture.

Which tools confirm your DMARC setup is actually working?

A short verification pass after each change catches mistakes before they cause problems. Run through this before considering any rollout stage complete:

  • Query your DMARC record directly with dig TXT _dmarc.yourdomain.com rather than trusting a DNS panel's preview, which can lag behind the live record.
  • Use a free online DMARC record checker to validate syntax, they'll flag malformed tags or missing semicolons instantly.
  • Send a test email to an external address and inspect the Authentication-Results header to confirm SPF, DKIM, and DMARC all report a pass.
  • Check your rua mailbox (or dashboard, if you're using a reporting service) within 24 to 48 hours of publishing to confirm reports are actually arriving. No reports usually means a syntax error in the record, not a lack of mail traffic.
  • If failures persist after two rounds of fixes and you can't identify the source, that's the point to bring in a managed provider rather than keep guessing.

How does a managed IT partner handle DMARC rollouts?

Myitbutler approaches DMARC the same way it approaches most email security work: methodically, with a paper trail, and without breaking anything a client relies on. The team holds CCNA, CompTIA Security+, and PRINCE2 certifications, and brings more than 15 years of enterprise IT experience to what is, for most small businesses, a rare and unfamiliar task.

For distributed teams working across time zones, a managed rollout removes the guesswork of chasing sender inventories and interpreting XML reports between other jobs. A typical DMARC consultation with Myitbutler covers a full sender audit, the DNS changes themselves, report analysis during the monitoring window, and a staged ramp to enforcement, coordinated with the client throughout rather than left to run unattended.

What actually matters most in a DMARC rollout

The conventional advice on DMARC treats it as a five-minute DNS task, and that's exactly where most businesses go wrong. Publishing the record is trivial. Reading what comes back afterwards is where the real work, and the real risk, sits.

Businesses that get burned by DMARC almost always jumped to p=reject too fast, usually because a vendor or a checklist told them enforcement was the "proper" end state. It is, eventually. But every SPF lookup limit issue, every forgotten marketing tool, every mailing list quirk shows up in the reports before it shows up as a bounced customer invoice, if you give it time to.

If you take one thing from this guide, prioritise the sender inventory over the DNS syntax. The record itself is copy and paste. Knowing which of your dozen connected platforms actually sends mail as your domain is the part that takes judgement, and it's the part most guides skip past in a rush to get to the TXT record.

— Thomas

Get a managed DMARC rollout from Myitbutler

A managed IT partner can be an alternative to hiring an in-house specialist for a task most businesses only do once: a fixed-scope DMARC rollout with no long-term contract attached.

Myitbutler

Such a managed service can cover the full arc, sender inventory, the DNS record changes themselves, ongoing report parsing during the monitoring window, and a staged ramp to enforcement, coordinated with the client rather than run silently in the background. This approach suits business owners and IT managers who'd rather hand the technical detail to a trusted remote partner than parse XML reports between everything else on their plate, whether their team sits in one office or across multiple time zones.

If you want a straightforward next step, book a DMARC consultation to scope the work against your actual sender list, or start with a free discovery call if you're still deciding whether to handle it yourself or hand it over.

Sources

This guide draws on official platform documentation and deployment frameworks rather than opinion. For the technical specification itself, RFC 7489 defines every DMARC tag and evaluation rule referenced here. Microsoft's own DMARC configuration guidance walks through the Microsoft 365 side of setup, while Gmail's sender guidelines cover what Google expects from authenticated senders. For small-business specific timing and cost expectations, SimpleDMARC's setup guide is worth a read, and mxio's deployment guide covers the phased monitor-to-reject approach in more depth than most.

FAQ

How do I set up DMARC correctly?

Confirm SPF and DKIM are both passing first, then publish a DMARC TXT record at _dmarc with p=none and a rua reporting address, monitor for two to four weeks, and only then move to quarantine and reject.

What should my DMARC policy be set to?

Start with p=none while you review reports and fix any legitimate sender issues, then progress to p=quarantine with a gradual rollout, and finish at p=reject once reporting consistently shows no legitimate mail failing.

What is a DMARC setup?

A DMARC setup is a DNS TXT record that tells receiving mail servers how to handle messages that fail SPF or DKIM checks for your domain, and where to send reports summarising that activity.

Do I need to set up DMARC for my business?

Yes, if your business sends email at any volume, since major providers like Gmail expect SPF, DKIM, and a published DMARC policy from senders, and mail without it risks being marked as spam or rejected outright. If the rollout itself feels like more than your team has time for, a managed provider can handle the inventory, DNS changes, and report monitoring for you.