Summary
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that builds on SPF and DKIM to define how receiving mail servers should handle messages that fail authentication checks. It also generates reports that show who is sending email on behalf of your domain, which is valuable for identifying configuration problems and spotting unauthorised use. DMARC is now required by Gmail and Yahoo (since February 2024) and Microsoft (since May 2025) for reliable email delivery. This article explains how DMARC works technically, its three policy levels (none, quarantine, reject), how to implement it progressively without disrupting your email flow, and how it connects to BIMI for brand display in supported inboxes.
DMARC Explained: What It Is, How It Works, and Why It Matters Now
DMARC used to be something email deliverability specialists cared about and most marketing teams did not. That changed in February 2024, when Google and Yahoo made it a mandatory requirement for all senders. Microsoft followed in May 2025. If your sending domain does not have a valid DMARC record, your emails to Gmail, Yahoo, and Outlook addresses are now at increased risk of being rejected or filtered.
Here is what DMARC actually does and how to set it up properly.
What DMARC does
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on two other authentication protocols: SPF, which verifies that the sending server is authorised to send from your domain, and DKIM, which adds a cryptographic signature to outgoing emails to verify they have not been tampered with in transit.
What DMARC adds is the policy layer. SPF and DKIM check whether an email is authenticated. DMARC tells the receiving server what to do if it is not: ignore the failure and deliver anyway, send the message to spam, or reject it entirely. It also specifies where to send reports about authentication results, which gives you visibility into how your domain's emails are being treated across the internet.
The reporting function is genuinely useful. DMARC aggregate reports (sent as XML files to an address you specify) show you how many emails were sent from your domain, which ones passed or failed authentication, and from which IP addresses. If someone is spoofing your domain to send phishing emails, DMARC reports will surface that. If you have a misconfigured sending subdomain, the reports will show you where the failures are occurring.
The three policy levels
When you publish a DMARC record in your domain's DNS, you set a policy parameter (p=) with one of three values.
p=none is monitoring mode. Emails that fail authentication are delivered as normal, but DMARC reports are generated and sent to you. This is the right starting point if you are implementing DMARC for the first time, because it lets you understand what is authenticating and what is not before you start blocking anything.
p=quarantine tells receiving servers to treat non-authenticating emails with suspicion, typically sending them to the spam folder rather than the inbox. Use this once you are confident your legitimate sending sources are properly authenticated.
p=reject is the strictest setting: emails that fail authentication are rejected outright and not delivered. This is the most protective setting and the one recommended for organizations where brand impersonation is a real risk.
The standard approach is to move through these levels progressively: start at none, review your DMARC reports to ensure all legitimate email sources are authenticating correctly, move to quarantine, then to reject once you are confident. Jumping straight to p=reject without reviewing your reports first is the most common way to accidentally block your own legitimate emails.
How DMARC connects to BIMI
BIMI (Brand Indicators for Message Identification) is an emerging standard that allows your brand logo to display alongside your emails in supported inboxes, including Gmail. To qualify for BIMI, your domain needs to have DMARC set to at least p=quarantine. It is one more practical reason to move beyond p=none if you have not already done so.
Setting up DMARC
A DMARC record is a TXT record published at _dmarc.yourdomain.com. A minimal starting record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The rua tag specifies where aggregate reports are sent. Once you have SPF and DKIM in place and have reviewed your DMARC reports, you can update the policy to quarantine or reject.
If you use an email marketing platform like Positive User, check whether it already adds DKIM signatures to your outgoing emails. Most professional platforms do. Confirm your SPF record includes the platform's sending infrastructure, and make sure your DMARC record is published at the domain level you are sending from.
For free verification tools: MXToolbox lets you check your DMARC record directly, and Mail-tester.com will test a live email for full authentication compliance. For the broader requirements from Gmail and Yahoo: Google and Yahoo sender requirements.










