What is DMARC? A Complete Guide for Business Owners

Email is the most common attack vector for cybercriminals — and one of the most effective ways they get in is by pretending to be you. DMARC is the email authentication standard that stops them. This guide explains what DMARC is, how it works alongside SPF and DKIM, why Google and Yahoo now require it, and what your business needs to do to get properly configured.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that tells receiving mail servers what to do when an email fails identity checks — and sends reports back to you so you can see what is happening with your domain.

In plain terms: DMARC is a rule you publish for your domain that tells the rest of the internet’s mail servers how to handle email that claims to come from you but cannot prove it. If someone sends a phishing email pretending to be your company, DMARC is what stops it from reaching the recipient’s inbox.

DMARC does not work alone. It sits on top of two other email authentication standards — SPF and DKIM — and acts as the enforcement layer that ties them together. Without DMARC, SPF and DKIM provide some protection but have significant gaps. With DMARC, those gaps close.

The standard is published as a DNS TXT record on your domain. Every major email provider — Gmail, Outlook, Yahoo, and others — checks for it when deciding whether to deliver, quarantine, or reject an incoming message.

How SPF and DKIM fit in

Before understanding DMARC fully, you need to understand the two systems it builds on.

SPF: Sender Policy Framework

SPF is essentially an approved senders list for your domain. When you set up SPF, you publish a DNS record that lists every server or service that is allowed to send email on behalf of your domain. If your email runs through Microsoft 365, you add Microsoft’s mail servers. If you use Mailchimp for marketing, you add Mailchimp. If you use DocuSign, you add DocuSign.

When a recipient’s mail server receives an email claiming to be from your domain, it checks your SPF record. If the sending server is on your approved list, SPF passes. If it is not — as would be the case with a hacker sending from a random server — SPF fails.

The limitation of SPF alone: SPF only checks the technical sending server, not the “From” address that the recipient actually sees. A sophisticated attacker can pass SPF while still displaying a spoofed From address. That is where DKIM and DMARC come in.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic digital signature to every outgoing email. Think of it like a tamper-evident seal on a letter. Your mail server signs the email with a private key, and the corresponding public key is published in your DNS records. When the receiving server gets the email, it checks the signature against your public key.

If the signature matches, two things are confirmed: the email genuinely came from your domain, and the content has not been altered in transit. If the signature does not match or is missing, DKIM fails.

The limitation of DKIM alone: DKIM proves the message was signed by your domain, but it does not prevent a bad actor from using a different domain to sign the email while displaying your domain in the From field.

Why you need both — and DMARC

SPF and DKIM each plug different holes, but neither checks that the domain in the visible From address matches the domain that actually sent the email. DMARC adds that check — called alignment — and enforces it. For an email to pass DMARC, at least one of SPF or DKIM must pass, and the domain used in that check must align with the From address the recipient sees.

That alignment requirement is what closes the gap that email spoofing exploits.

How DMARC works step by step

1. You publish SPF, DKIM, and DMARC records in your domain’s DNS settings.
2. Your business sends an email — a client invoice, a marketing message, a support reply.
3. The recipient’s mail server receives the email and checks your SPF record: is this sending server on your approved list?
4. The server also checks your DKIM record: does the cryptographic signature on this email match your published public key?
5. DMARC then evaluates alignment: does the domain used in the SPF or DKIM check match the domain in the visible From address?
6. Based on your DMARC policy, the server decides what to do: deliver, quarantine, or reject.
7. A report of that evaluation is sent back to the address you specify in your DMARC record.

This entire process happens invisibly in seconds, on every single email your domain sends.

DMARC policy levels explained

DMARC gives you three policy options, which you set in your DNS record. The right choice depends on where you are in your configuration process.

DMARC reporting: a benefit most businesses overlook

One of the most underappreciated features of DMARC is the reporting it generates. When DMARC is active, you receive automated reports — typically daily — from every major mail provider that processes your email. These reports tell you:

• Which servers and services are sending email using your domain
• Which emails are passing or failing SPF and DKIM
• Where in the world emails claiming to be from your domain are originating
• Whether anyone is attempting to spoof your domain

The reports arrive in XML format, which is not human-readable on its own. There are several tools that parse and visualize DMARC report data — Dmarcian, MXToolbox, and others — that make this data actionable. Many businesses are surprised to discover, during the monitoring phase, that third-party tools they use have never been properly added to their SPF record and are quietly failing authentication on every send.

Why DMARC is now required — not optional

For a long time, DMARC was considered a best practice that security-conscious organizations adopted. That is no longer the case. As of February 2024, Google and Yahoo began requiring DMARC, SPF, and DKIM for any sender sending more than 5,000 emails per day. Emails that do not meet these requirements are rejected or marked as spam.

Even if you send fewer than 5,000 emails per day, the practical reality is that major mail providers are increasingly using the presence or absence of proper email authentication as a trust signal. A domain without DMARC is treated with more suspicion than one with it — which affects deliverability even for routine business email.

Beyond deliverability, there is the regulatory angle. Industries including healthcare, finance, and legal services are increasingly incorporating email authentication into their cybersecurity compliance requirements. CISA’s Binding Operational Directive 18-01 has required DMARC for federal agencies since 2017 — the private sector is following.

Third-party tools and DMARC: where most businesses get tripped up

Most businesses do not send all of their email through a single system. Between transactional email, marketing, CRM notifications, e-signatures, and helpdesk tools, a typical small business might have five to ten different services sending email on its behalf. Each one of those needs to be properly configured in your SPF and DKIM records for DMARC to work correctly.

Common tools that send email on your behalf and need to be authenticated:

• CRM platforms like Salesforce, HubSpot, or Zoho
• Email marketing tools like Mailchimp, Constant Contact, or Klaviyo
• E-signature services like DocuSign or Adobe Sign
• Helpdesk platforms like Zendesk, Freshdesk, or HubSpot Service Hub
• Accounting software like QuickBooks or FreshBooks that sends invoices
• Scheduling tools like Calendly or Acuity that send confirmations
• Any custom web application that sends automated emails

If any of these is missing from your SPF record or not configured for DKIM, its emails may fail DMARC and end up in spam — or be rejected entirely if your policy is set to p=reject. This is the most common configuration mistake we see, and it is exactly why the monitoring phase matters before moving to enforcement.

What happens if you do not have DMARC configured

Without DMARC, your domain is an open target for email spoofing. Here is what that looks like in practice:

• Spoofed invoices. A criminal sends a fake invoice to your client that appears to come from your email address. Your client pays — to the criminal’s account.
• Phishing attacks on your staff. An attacker impersonates your CEO or HR department to trick an employee into sharing credentials or transferring funds.
• Brand damage. Recipients who receive fake emails from your domain lose trust in your company, even though you had nothing to do with them.
• Deliverability problems. Without DMARC, major providers increasingly flag your legitimate emails as suspicious, affecting whether clients and prospects actually receive them.
• Compliance gaps. If your business operates in a regulated industry, the absence of DMARC may constitute a compliance failure under your cybersecurity framework.

How to set up DMARC, SPF, and DKIM

Setting up email authentication involves making changes to your domain’s DNS records, which are managed through wherever your domain is registered (GoDaddy, Cloudflare, Google Domains, etc.) or your DNS provider. Here is the high-level process:

Step 1: Audit your sending sources

Before touching DNS, make a list of every service that sends email on behalf of your domain. This is your source of truth for SPF and DKIM configuration. Missing even one legitimate sender is the most common cause of deliverability problems after DMARC is enabled.

Step 2: Configure SPF

Create or update your SPF TXT record to include all approved sending sources. The record follows a specific syntax — for example, a basic Microsoft 365 SPF record looks like: v=spf1 include:spf.protection.outlook.com -all. Each additional sending service adds its own include statement. You can use MXToolbox’s SPF checker to validate your record once it is published.

Step 3: Enable and publish DKIM

DKIM configuration happens in two places: your email platform (where you generate or enable the signing key) and your DNS (where you publish the public key). Microsoft 365, Google Workspace, and most major platforms have built-in DKIM configuration interfaces. Follow the documentation for each service you use.

Step 4: Publish your DMARC record

Create a DMARC TXT record at _dmarc.yourdomain.com. Start with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:[email protected]. The rua tag specifies where aggregate reports should be sent.

Step 5: Review reports and move to enforcement

After two to four weeks of monitoring, review your DMARC reports to confirm all legitimate senders are passing. Fix any that are not, then update your policy to p=quarantine, monitor for another week or two, and finally move to p=reject.

Frequently asked questions about DMARC

Is DMARC required for small businesses?

It is not legally required for most small businesses, but it is effectively required for reliable email deliverability. Google and Yahoo’s 2024 sender requirements apply to bulk senders, but the broader trend is clear: domains without DMARC are treated with increasing suspicion by major mail providers, which affects everyday email — not just bulk campaigns.

Will setting up DMARC break my email?

It can, if done incorrectly or rushed to enforcement before all senders are authenticated. That is why starting with p=none and reviewing reports before moving to quarantine or reject is so important. A properly staged rollout carries minimal risk.

How do I know if I already have DMARC set up?

You can check using a free tool like MXToolbox’s DMARC lookup. Enter your domain and it will tell you whether a DMARC record exists and what policy it is set to.

What is the difference between DMARC quarantine and reject?

Quarantine sends failing emails to the recipient’s spam or junk folder — they still arrive, just not in the inbox. Reject blocks the email entirely before delivery. For full protection against spoofing, reject is the goal, but quarantine is a reasonable intermediate step.

Does DMARC protect against all phishing attacks?

DMARC protects against direct domain spoofing — attacks where the criminal uses your exact domain in the From address. It does not protect against lookalike domains, display name spoofing, or compromised email accounts. It is an important layer of defense, but not the only one your business needs.

How long does it take to set up DMARC?

The technical configuration itself can be done in a few hours for a straightforward setup. The full rollout process — monitoring, fixing misconfigurations, and moving to enforcement — typically takes two to six weeks depending on how many third-party senders you have and how complex your email infrastructure is.

Can I set up DMARC myself?

Yes, if you are comfortable making changes to DNS records and you have a clear picture of all your sending sources. For businesses with multiple third-party tools, complex mail flows, or no in-house IT, working with a managed IT provider reduces the risk of misconfiguration significantly.

The bottom line

DMARC is not a complicated concept, but the configuration details matter. A domain with DMARC set to p=none indefinitely is not meaningfully protected — it is just collecting data. The goal is a properly audited SPF record, functioning DKIM signing across all your sending platforms, and a DMARC policy at enforcement level. That combination makes your domain significantly harder to spoof and keeps your legitimate email reliably in inboxes.

For most small and mid-sized businesses, the challenge is not the concept — it is the audit: figuring out every service that sends email on your behalf, making sure each one is correctly configured, and then maintaining that configuration as your tools change over time. That is where having an IT partner who manages it for you makes a real difference.

Urban IT helps businesses in the Conejo Valley and greater Los Angeles area configure and maintain SPF, DKIM, and DMARC properly — including auditing all third-party senders and managing the rollout to full enforcement. Talk to Urban IT about your email security ↗

External references

• RFC 7489 — DMARC specification (IETF)
• Google — Email sender requirements
• Yahoo — Sender best practices
• CISA — Binding Operational Directive 18-01
• Dmarcian — DMARC report analysis tool
• MXToolbox — DMARC, SPF, and DKIM lookup tools
• FBI Internet Crime Report 2023 (IC3)