What Is DMARC? Simplify Email Security

DMARC is an email authentication policy that helps receiving servers verify that a message is really from your domain, and it matters because the Canadian Anti-Fraud Centre reported $578.7 million in fraud losses in 2023. In plain English, DMARC helps stop spoofed email by telling other mail systems what to do when a message claims to be from you but can't be verified.

If you own a domain, you've probably had this worry already. A client gets a fake invoice, a supplier sees a suspicious message from your address, or your team starts asking why some legitimate emails land in junk. That's usually when “what is DMARC” goes from a technical acronym to a business problem.

We think of DMARC as a posted rulebook for your domain. It sits in DNS, works with SPF and DKIM, and tells receiving mail servers whether to accept, quarantine, or reject messages that fail authentication. It also gives you reports, which is the part most business owners don't hear about until after something breaks.

Last updated: 2026-06-16

What Is DMARC and Why It Matters Now

A customer gets an invoice that looks like it came from your domain. The logo is right. The sender name is familiar. The reply address even looks close enough to pass a quick glance. By the time anyone questions it, the damage is already in motion.

That is the problem DMARC is meant to reduce.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. In practical terms, it is a rule you publish for your domain that tells receiving mail systems how to treat messages that claim to be from you. It also gives you feedback, which is the part small businesses need most during setup.

The simple definition that actually helps

DMARC works like a front-desk policy for your domain. SPF and DKIM are the badges and paperwork. DMARC tells the receptionist what to do if the person at the desk cannot prove they belong there. Accept them, send them to a side room, or turn them away.

That policy lives in DNS. Once it is published, other mail providers can check whether a message using your visible From address lines up with the rules you set for your domain. For a clear vendor-neutral overview, Cloudflare's DMARC guide explains the standard in plain language.

DMARC matters because spoofing hurts two parts of the business at once. It creates security risk, and it weakens trust in your real messages. If a fake email reaches a customer first, your legitimate email now has to overcome suspicion you did not create.

Practical rule: DMARC protects the name attached to your domain, not just the messages that leave your mail server.

The urgency has increased. Google and Yahoo both tightened sender requirements for higher-volume email in 2024, including DMARC for senders that reach Gmail or Yahoo recipients at scale. Google documents that requirement in its Email sender guidelines.

Why small businesses should care now

Small businesses usually do not send from one system. We often have Microsoft 365 or Google Workspace for staff email, then a newsletter platform, a CRM, accounting software, a booking tool, and maybe a support desk sending on the same domain. Each tool is another possible gap between what we believe is sending our email and what mailbox providers perceive.

That is why DMARC projects fail in real life. The policy itself is simple. The sending footprint is not.

A lot of articles stop at the definition, then jump straight to "set p=reject." For a small business, that can be like locking every door in the building before checking which employees still need keys. Real DMARC work usually starts with p=none, where we watch reports, find every service sending mail on our behalf, fix alignment problems, and only then tighten the policy to quarantine or reject.

That step-by-step path matters more than the acronym. A strict policy protects you only after your legitimate senders are correctly configured.

The fraud risk is also real. The Canadian Anti-Fraud Centre's 2023 annual data reports $578.7 million in victim losses, and impersonation by email remains a common tactic in phishing and business email compromise.

If spoofing is your immediate concern, our guide on how to prevent email spoofing and fortify your email security gives the broader context around where DMARC fits.

How DMARC Works With SPF and DKIM

DMARC doesn't work alone. It sits on top of SPF and DKIM. If those two are the proof, DMARC is the policy that tells other servers how to judge that proof.

SPF is the guest list

SPF or Sender Policy Framework is like the guest list at an event. Your domain publishes a list of which mail servers are allowed to send email for it. When a receiving server gets a message, it checks whether the sending system is on that list.

That helps, but SPF has limits. Forwarding can break it. Third-party tools can complicate it. A message can also pass SPF in a way that still doesn't match what the recipient sees in the From field.

DKIM is the seal on the letter

DKIM or DomainKeys Identified Mail works more like a seal on an envelope. It adds a cryptographic signature to the message so the receiving server can verify that the message hasn't been altered and that it was signed by an approved domain.

DKIM is useful because it survives some situations that SPF doesn't. But DKIM alone still isn't the full answer. A message can carry a valid signature from one domain while showing a different domain in the visible From address.

SPF says who's allowed to send. DKIM helps prove the message is intact. DMARC checks whether that proof lines up with the identity the recipient actually sees.

Alignment is where people get stuck

This is the part most beginner articles rush past. A message passes DMARC only when either SPF or DKIM passes and the authenticated domain aligns with the visible From domain, which is why misconfigured forwarding, third-party senders, or inconsistent subdomain use often cause legitimate mail to fail, as described by PowerDMARC's explanation of DMARC requirements.

Here's a plain-language example:

• Passes DMARC: your visible From address is billing@yourdomain.ca, and either SPF or DKIM also authenticates yourdomain.ca
• Fails DMARC: the visible From address is billing@yourdomain.ca, but the mail is authenticated under a different domain that doesn't align

That's why a normal-looking tool can cause trouble. Your newsletter platform may be properly sending mail, but if it signs mail with its own domain instead of yours, DMARC can still fail.

What domain owners usually miss

Many people think DMARC is a switch. Add record, done. In real life, it's a coordination task across all the systems that send mail using your brand.

Common situations that cause confusion include:

• Forwarded mail: forwarding can make SPF results unreliable
• Third-party platforms: CRM, payroll, and marketing systems may not align by default
• Mixed subdomains: one team sends from news.yourdomain.ca, another sends from yourdomain.ca
• Old tools still active: a forgotten web form or support platform may still send mail

Once you understand alignment, DMARC starts to make sense. Until then, it can feel random.

Choosing Your DMARC Policy

A DMARC policy tells receiving servers what to do when a message fails DMARC. This is the part of the DMARC record that gets the most attention, but the safest way to use it is gradually.

We usually explain it as crawl, walk, run. Start by watching. Then move suspicious mail toward junk. Only reject once you know your legitimate senders are lined up correctly.

DMARC policy comparison

Policy	Instruction to Servers	Best For	Risk to Mail Delivery
p=none	Monitor only. No delivery action requested.	First-stage rollout and discovery	Low
p=quarantine	Treat failing mail as suspicious, often spam or junk	Soft enforcement	Medium
p=reject	Refuse failing mail	Full enforcement after cleanup	Higher if your setup is incomplete

What each option really means

p=none is the safest starting point. It doesn't ask receiving servers to block anything. It gives you visibility through reports so you can see who is sending mail as your domain.

p=quarantine is the middle ground. It tells receiving servers that failing mail should be treated carefully, often by placing it in spam or junk. This is useful when you've cleaned up most issues but still want a softer landing.

p=reject is the strongest setting. It tells receiving servers to block mail that fails DMARC. That's the end goal for many domains, but it's only safe once you know your real senders are authenticating and aligning properly.

One good habit: treat p=none as a discovery phase, not a finish line.

Many small businesses stop at monitoring because it feels safer. The problem is that monitoring alone doesn't stop spoofing. It only tells you what's happening. If you want the strongest protection, you need a path to enforcement.

That path also affects deliverability. If you want a plain-language primer on that side of the issue, our article on what email deliverability means and how inbox placement works connects authentication to real inbox outcomes.

How to Create and Publish Your DMARC Record

A DMARC record is a DNS TXT record. You publish it at _dmarc.yourdomain.com, and it tells receiving servers what your policy is and where to send reports.

That sounds more technical than it is. In practice, you're adding one line of text in your DNS settings.

A basic DMARC record example

A simple starter record looks like this:

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

Each part has a job:

• v=DMARC1 identifies the record as DMARC
• p=none sets the monitoring policy
• rua=mailto:... tells receivers where to send aggregate reports

That's enough to begin safely. You don't need to jump straight to strict enforcement on day one.

Where small businesses usually stumble

The hard part is alignment and rollout. A better question than “what is DMARC?” is often “How do we move from monitoring to enforcement without breaking legitimate mail from payroll, CRM, and marketing tools?” That migration problem is often under-explained, as noted by MXToolbox in its DMARC overview.

That's why a staged checklist helps.

1. Publish a monitoring record first
   Start with p=none so you can collect reports without disrupting delivery.

2. List every system that sends as your domain
   Think beyond your main mailbox provider. Include newsletters, forms, invoicing tools, help desk systems, and HR platforms.

3. Check SPF and DKIM for each sender
   If a service can't align properly with your visible From domain, it can become a problem later.

4. Only tighten policy after review
   Move toward quarantine or reject after you've cleaned up the failures you recognise and investigated the ones you don't.

If you need a broader setup walkthrough, our guide on how to authenticate email with a real-world setup that works covers the surrounding pieces in more detail.

A short visual can make the moving parts easier to see:

Keep the rollout boring

That may sound odd, but boring is good here. DMARC projects go wrong when someone publishes p=reject too early, then finds out the payroll provider or contact form was never aligned.

If you use a hosted mail provider, a privacy-focused option like Typewire can support custom domains and the authentication work around them, but the same rule still applies no matter which provider you choose. You need to know every sender using your domain before you enforce.

Reading and Understanding DMARC Reports

You publish a DMARC record with p=none, feel good about it, and a day later your inbox starts filling with report emails full of XML. For many small businesses, this is the point where the project stalls. The reports look technical, so they get ignored. Then someone jumps to p=quarantine or p=reject without learning from them first, and a legitimate sender breaks.

That is why the report-reading stage matters so much. It is the part that shows whether your move from monitoring to enforcement will be safe.

The two report types

DMARC reports come in two broad categories.

• Aggregate reports give you a summary of what receiving servers saw. They show which IPs sent mail claiming to be from your domain, whether SPF or DKIM passed, and whether those checks aligned with your visible From address.
• Forensic reports can include details about individual failures, but support is inconsistent and many providers send few or none at all.

For a small business, aggregate reports do most of the practical work. They are the weekly inventory count. They help us confirm which services are really sending as our domain, not just which ones we remember paying for.

What these reports look like in real life

Raw DMARC reports are usually XML files. They are built for software, not for busy owners or admins reading email between meetings.

That is why many teams use a reporting tool or parser to turn those files into something readable. The DMARC.org guide to reports explains the same split between raw report data and tools that make it usable for domain owners: https://dmarc.org/wiki/FAQ#What_are_DMARC_reports.3F

Once the data is in a dashboard, four questions matter more than anything else:

• Which senders do we recognize? Your mail host, website forms, newsletter platform, billing system, and help desk should all make sense.
• Which senders do we not recognize? Unknown sources may be harmless misconfigurations, old tools no one retired properly, or outright spoofing attempts.
• Are failures caused by authentication, or by alignment? A message can pass SPF or DKIM and still fail DMARC if the domain does not line up with the visible From address.
• Would enforcement block real business mail today? That is the question that tells you whether you are ready to move beyond p=none.

A helpful way to read DMARC reports is to treat them like a delivery log for trucks using your company logo. Some are your own vehicles. Some belong to approved contractors. Some are unmarked vans you have never seen before. Before we tell security to turn every unknown vehicle away at the gate, we need a clean list of who is actually allowed in.

How to use reports during the move from p=none to p=reject

Many guides often keep things too abstract, so let's make it practical.

At p=none, the job is discovery. We are not trying to block mail yet. We are building a sender inventory and checking alignment. If reports show that Microsoft 365, your CRM, and your invoicing tool are all sending correctly, that is progress. If the reports also show an old ecommerce plugin sending from an IP you forgot about, that is useful too.

At p=quarantine, the job is caution. We should already understand nearly all legitimate traffic by this point. Quarantine lets receiving systems treat suspicious mail more harshly, but it still gives some room for observation. If a legitimate sender starts showing DMARC failures here, we fix that sender before tightening further.

At p=reject, the job is consistency. We should be able to look at the reports and say, with confidence, “the mail that fails is not mail we want delivered.” If we cannot say that yet, we are not ready.

That progression is the essential value of reports. They are not just status updates. They are the evidence we use to decide whether tightening policy is safe.

What success looks like

Early reports often uncover forgotten systems. A booking tool. A copier that emails scans. A support app using the wrong From domain.

Later, the pattern should get quieter. Known senders pass consistently. Unknown sources stand out faster. Policy changes stop feeling like a gamble because the reports have already shown us what normal looks like.

A good DMARC rollout becomes routine. That is the goal.

DMARC FAQs for Small Businesses

Is DMARC enough to stop phishing

A good way to frame this is simple. DMARC protects your domain name from being impersonated in email, but it does not stop every kind of phishing.

An attacker can still register a lookalike domain, compromise a real mailbox, or send from a legitimate account that passes authentication, as explained in IronScales' DMARC glossary. So if you turn on DMARC and still see suspicious messages, that does not mean DMARC failed. It means phishing has more than one path in.

We usually explain it like a lock on your front door. It stops one specific kind of break-in. It does not secure every window in the building.

Will DMARC break my marketing or payroll emails

It can if those services are not set up to authenticate and align with the From domain your customers and staff see.

For small businesses, this is the point where a lot of rollouts go wrong. A payroll app, booking system, newsletter platform, or copier has been sending mail for years, not under DMARC review. At p=none, DMARC helps us spot those senders without blocking them. That gives us time to fix SPF, DKIM, or the From address before we move to p=quarantine or p=reject.

So if a service fails DMARC, the protocol is not creating a new problem. It is exposing a setup issue you had. That is exactly why the migration path matters. We monitor first, clean up legitimate senders, then enforce.

Is DMARC the same thing as a spam filter

No. A spam filter evaluates incoming messages and decides what looks risky or unwanted. DMARC tells receiving mail systems how to handle messages that claim to be from your domain but fail authentication checks.

We want both. One protects your brand identity. The other helps protect your inboxes.

What's the safest path for a small business

The safest path is gradual, and it should feel boring by the end.

We start with p=none to collect reports and build a real sender list. Then we fix the services that are failing. Only after known senders are passing consistently do we move to p=quarantine. p=reject comes last, when we are confident that mail failing DMARC is mail we do not want delivered.

That sequence matters more than the DNS record itself. Small businesses rarely struggle with publishing the record. They struggle with finding every system that sends as their domain.

If you want private email under Canadian control, Typewire offers encrypted email hosting with custom domain support, Canadian data residency, and infrastructure we operate ourselves. If you're sorting out SPF, DKIM, and DMARC for a small business, that gives you a cleaner base to work from while keeping your email under Canadian privacy law.