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: Block them entirely. Don’t deliver them at all.
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.comBreaking 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 authenticationrua=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.comThis 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 blocks the email before it ever reaches your customer. You also receive a DMARC report that day showing the spoofing attempt: where it came from, how many emails were sent, and that they were blocked.
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 — Full block
Emails that fail authentication are rejected outright and never reach the recipient. This is the most protective setting and where every sender should aim to be, but move here only after you’ve confirmed through monitoring that all your legitimate email is passing authentication consistently.
The standard path: start at p=none, read your reports for a few weeks, fix any gaps in your legitimate sending setup, move to p=quarantine, monitor again, then move to p=reject.
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 campaigns show DMARC failures in your monitoring data, alignment is usually the first place to investigate.
Why Gmail and Yahoo 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.
The requirement exists because spoofing and phishing at scale had become a serious problem for mailbox providers. By requiring senders to publish DMARC records, Google and Yahoo can enforce authentication at an industry level.
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 and Yahoo’s sender requirements, which directly affects your inbox placement.
How to Know If Yours Is Working
The most direct way is to look at your actual campaign data. InboxEagle shows the DMARC authentication result for every campaign you send — pass or fail — alongside SPF and DKIM results, right in the campaign’s Deliverability view. If your DMARC is failing on live sends, you’ll see it there alongside the sending domain, IP, and received timestamp for that campaign.
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’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 see how your sending domain’s DMARC is performing across live campaigns, InboxEagle shows SPF, DKIM, and DMARC results for every send alongside your inbox placement data.
Note: Content created with the help of AI and human-edited and fact-checked to avoid AI hallucinations.
