What Is DMARC? Plain-English Guide for eCommerce Senders

Every day, scammers send emails pretending to be from brands people trust. Your bank. Your favourite online store. Maybe your store. DMARC is the mechanism that lets you do something about it.

It sounds like an IT acronym buried in a developer’s to-do list. But the concept behind it is simple, the risk of not having it is real, and since 2024 it has been a requirement for anyone sending bulk email to Gmail and Yahoo inboxes.

One thing that comes up consistently when eCommerce brands first look at their authentication setup: DMARC is either missing entirely, or it’s set to p=none which means it exists on paper but isn’t actually protecting anything. Both are problems with straightforward fixes, once you understand what the record actually does.

Here’s what DMARC means, in plain English.

Start With the Problem DMARC Solves

Imagine someone sends an email that says it’s from orders@yourbrand.com. They didn’t hack your account. They just typed your domain name in the “From” field. Email was designed decades ago when this kind of thing wasn’t a concern, so by default, anyone can send an email claiming to be from any address.

Your customers receive it. It looks legitimate. It might ask them to click a link, confirm payment details, or download something. This is called email spoofing, and it’s one of the most common forms of phishing.

Before DMARC existed, there was no standard way for you as the domain owner to tell Gmail: “if you see an email claiming to be from my domain that didn’t actually come from my servers, don’t deliver it.”

DMARC gives you that instruction.

What DMARC Actually Is

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. You don’t need to remember that. What matters is what it does.

It’s a small piece of text you add to your domain’s DNS settings, which is essentially the address book that tells the internet where your website and email live. That text does two things:

First, it sets a policy. It tells Gmail, Outlook, Yahoo, and every other major email provider what to do when they receive an email claiming to be from your domain that fails authentication checks. You have three choices:

• None: Do nothing. Just monitor and send me reports.
• Quarantine: Put suspicious emails in the spam folder.
• Reject: Ask receivers to refuse them. Receivers that honor the policy will, but they may still deliver or junk the message.

Second, it asks for reports. DMARC tells providers to send you a daily report showing every email sent using your domain name, where it came from, and whether it passed or failed. This is how you find out if someone is spoofing your domain, and also how you confirm that your own legitimate emails (Klaviyo campaigns, order confirmations, shipping notifications) are passing authentication correctly.

What a DMARC Record Actually Looks Like

A DMARC record is a line of text that lives in your domain’s DNS. Here’s what a basic one looks like:

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

Breaking that down in plain English:

• v=DMARC1: this is a DMARC record (tells providers which version to read)
• p=reject: the policy, reject emails that fail authentication
• rua=mailto:reports@yourdomain.com: send daily aggregate reports to this email address

That’s it. Three parts. The p= value is the one you control over time as you move from monitoring to enforcing.

A minimal record just to meet Gmail and Yahoo’s requirements looks like this:

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

This says: don’t take any action yet, but start sending me reports. It’s the starting point.

How DMARC Fits With SPF and DKIM

You may have heard of SPF and DKIM alongside DMARC. They’re all part of the same authentication system and they work together. Here’s the simplest way to think about them:

SPF is the approved sender list. It’s a record in your DNS that says “these are the mail servers allowed to send email on behalf of my domain.” When an email arrives claiming to be from your domain, the receiving server checks whether the sending server is on your approved list. If Klaviyo is on your SPF record, emails sent through Klaviyo pass. If a scammer’s server isn’t on the list, it fails.

DKIM is a tamper-evident seal. When your email is sent, a digital signature is attached to it. When it arrives, the receiving server verifies that seal. If the email was modified in transit, or sent by someone without your signing key, the signature fails.

DMARC is the policy on top of both. It answers the question: if SPF fails, or DKIM fails, what should happen to the email?

Without DMARC, the answer is: nothing. The email gets delivered anyway even if both SPF and DKIM failed. DMARC is what gives those checks an actual consequence.

A Real-Life Example

Say you run a Shopify store called Maple & Co. Your customers regularly receive order confirmations from orders@mapleandco.com sent through Klaviyo.

A scammer decides to target your customers. They send an email from orders@mapleandco.com telling recipients their payment failed and asking them to re-enter their card details. The email didn’t come from Klaviyo. It came from the scammer’s own server.

Without DMARC: Gmail receives the email, sees it claims to be from mapleandco.com, and has no instruction from you about what to do with it. It may deliver it straight to the inbox. Your customers get scammed. Your brand takes the reputation hit even though you had nothing to do with it.

With DMARC set to reject: Gmail checks the email against your SPF record. The scammer’s server isn’t on it. It checks the DKIM signature. It’s missing or invalid. Both fail. Your DMARC policy says reject. Gmail can refuse the email or route it to spam, so it does not land in your customer’s inbox. You also receive a DMARC report that day showing the spoofing attempt: where it came from, how many emails were sent, and whether receivers acted on your policy.

That’s DMARC working as intended.

The Three Policy Levels, Explained Simply

p=none: Monitor mode

You’re watching but not acting. Suspicious emails still get delivered to recipients. You receive daily DMARC reports so you can see everything that’s being sent using your domain. This is where most senders start because it lets you check that all your own legitimate email (your ESP, your transactional email provider, any other tools that send on your behalf) is passing authentication before you start blocking anything.

Think of it as installing a security camera before you install a lock.

p=quarantine: Spam folder

Emails that fail authentication go to the recipient’s spam folder instead of the inbox. They’re not blocked entirely, but they’re flagged. This is the middle step: you’re taking action, but there’s a safety net in case a legitimate sending source wasn’t fully configured when you tightened the policy.

p=reject: Ask receivers to refuse

Emails that fail authentication are rejected by receivers that honor the policy. It is not a Gmail or Yahoo requirement for inbox placement, and it can block mail you still send through a forward or a vendor that is not aligned. Move here only after legitimate sources pass. The sequence is moving DMARC from monitoring to enforcement. If you have no record at all yet, no DMARC record found walks through the Klaviyo and Shopify setup.

Gmail and Yahoo still accept p=none. RFC 9989 warns that p=reject is a poor fit for domains that go through mailing lists or forwards, and that receivers are not required to reject solely because you published it.

What “Passing DMARC” Actually Means

This is where many eCommerce senders get tripped up, so it’s worth explaining clearly.

DMARC doesn’t just check whether SPF and DKIM pass. It also checks alignment: the domain used by SPF or DKIM has to match the domain in your From address.

Here’s why that matters. A scammer could technically pass SPF by sending from their own domain, while putting your domain in the From field that your customers see. Without alignment checking, that would look like a pass. DMARC’s alignment requirement closes that loophole.

For most Klaviyo senders using a properly configured custom sending domain, alignment is handled automatically. But misalignment is one of the most common reasons a sender believes their DMARC is set up correctly while their campaigns are still failing authentication. If your DMARC is passing at the record level but your aggregate reports show DMARC failures, alignment is usually the first place to investigate.

Why the Major Providers Now Require It

In February 2024, Google and Yahoo updated their bulk sender requirements to make DMARC mandatory for anyone sending more than 5,000 emails per day. The minimum is a DMARC record with at least p=none. Microsoft followed on May 5, 2025, requiring the same for Outlook, Hotmail, and Live.com recipients, returning a permanent 550 5.7.515 rejection for non-compliant bulk mail.

The requirement started as a filtering rule, but it has teeth now. Starting in November 2025, Gmail began ramping up enforcement on non-compliant traffic, moving a growing share of it from temporary deferrals to permanent rejections rather than just routing it to spam. A missing or broken DMARC record isn’t just a compliance gap anymore; it’s a delivery problem.

A p=none record meets the technical requirement but offers zero protection against spoofing. It’s the compliance floor, not the goal. If you’re sending marketing emails through Klaviyo or any ESP and you don’t have a DMARC record on your sending domain at all, you’re in violation of Google, Yahoo, and Microsoft’s sender requirements, which directly affects your inbox placement.

What DMARCbis Changed (and What It Didn’t)

In May 2026, the IETF published a revised DMARC specification, RFC 9989, known informally as DMARCbis. If your record already works, nothing breaks: existing records stay valid and still use v=DMARC1, and p=none is still the provider minimum. Two things are worth knowing if you’re setting up a record for the first time or touching an old one:

• The pct tag (and the lesser-used rf and ri tags) was removed (Appendix A.6); a new t tag replaces it as a testing flag. If your record still has pct=, it’s not broken, it just references a tag the current standard no longer defines.
• A new np tag sets policy for subdomains that don’t exist, closing a spoofing gap that older records left open. Consider adding np=reject the next time you touch your record, knowing that only receivers that implement RFC 9989 will read it.

Those are the two that matter for a first record. The full list, including how policy discovery works now, is in what RFC 9989 changes.

How to Know If Yours Is Working

The most direct way is to read your DMARC aggregate reports, which show every source sending as your domain and whether it passed. Unknown senders in DMARC reports covers what to do with a source you do not recognize. InboxEagle checks your DMARC policy record every 24 hours and alerts you if it changes; processing the aggregate reports is a separate paid product, DMARC Processing.

You can also check whether a DMARC record exists on your domain by looking up its DNS TXT records. A valid DMARC record starts with v=DMARC1. If there’s no record at all, or if the policy is p=none and you’ve been live for more than a few weeks, those are both worth addressing.

If you’d rather run a quick check than read your own DNS records, our comparison of DMARC checker tools covers free options and what each one actually verifies. If you’re on Klaviyo, the email authentication setup guide for Klaviyo senders covers exactly how to configure SPF, DKIM, and DMARC for your custom sending domain step by step. For data on how DMARC failures affect inbox placement in practice, the DMARC failure and spam folder study covers the findings across 2 million emails. To see how DMARC pass/fail results show up alongside your live campaign placement data, how to check if your emails are landing in spam covers the full InboxEagle Deliverability view. And for the complete set of signals worth monitoring beyond just authentication, what a deliverability dashboard should show covers all eight.

The Short Version

DMARC is a setting on your domain that tells Gmail, Outlook, and Yahoo what to do when someone sends email pretending to be you. It works alongside SPF and DKIM to form the authentication layer that mailbox providers use to decide whether to trust your email.

Without it, your domain is open to spoofing and your inbox placement is at risk. With it enforced correctly, you have protection for your customers and a stronger trust signal with every mailbox provider your campaigns reach.

To keep an eye on your DMARC policy and see where your campaigns land at Gmail, Yahoo, AOL and Outlook after every send, start a free InboxEagle trial. You can also check your record any time with the free DMARC record checker.

Note: Content created with the help of AI and human-edited and fact-checked to avoid AI hallucinations.