Let's BIMILet's BIMIdocs

DMARC

The final piece of email security needed for BIMI

SPF and DKIM are the first two layers of security for email which authenticate individual messages. DMARC however tells email servers what to do with emails that do not pass authentication. Unlike SPF and DKIM where you are configuring this for each of the different services you use thta will be sending emails using your domain, you are fully in control of your DMARC configuration at the DNS level.

In this guide you'll learn what DMARC is exactly, how to properly configure it for BIMI, and how to roll it out safely so you can ensure you don't silently drop emails on your path to BIMI.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What is it

A DNS TXT record that ties SPF and DKIM together, declares a policy for what to do with messages that fail, and requests reporting so you can see what's passing and failing.

Why it's important for BIMI

This is the record BIMI checks directly. Specifically:

  • Your DMARC policy (p=) must be set to quarantine or reject. A policy of p=none, monitoring only with no enforcement, does not qualify for BIMI, even if SPF and DKIM are both configured correctly.
  • The policy should apply to all mail (pct=100), not a percentage of it.

What it looks like

_dmarc.northloopfinancial.com.  IN TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"
  • p=reject is the enforcement policy: messages that fail authentication are rejected outright. p=quarantine (typically sent to spam) is the other BIMI-eligible option and a common, less aggressive starting point.
  • pct=100 applies the policy to all mail, not a sample.
  • rua= is an address that receives daily aggregate reports showing which sources are passing and failing authentication for your domain, useful both for the rollout below and as ongoing visibility.

Rolling out DMARC safely

Jumping straight to p=reject is the biggest way this step goes wrong, since it will silently reject legitimate mail from any sending source you missed in your SPF/DKIM setup. The standard, safer sequence is:

  1. p=none — Publish DMARC in monitoring mode. Nothing is enforced yet, but you start receiving reports on what's passing and failing.
  2. Review the reports for a few weeks and fix any legitimate sending sources that are failing SPF/DKIM.
  3. p=quarantine — Move to enforcement once reports look clean. This is enough to qualify for BIMI.
  4. p=reject (optional but recommended) — Tighten further once you're confident.

Steps 1–2 are the part most worth doing early and in parallel with the rest of your BIMI prep (logo, mark certificate), since they can take the longest and involve waiting on data, not active work.

If your organization doesn't already work with a DMARC reporting service, you have two good and free options:

  • Clouldflare. If your domain is hosted with Cloudflare and uses Cloudflare DNS, you can get free comprehensive DMARC reporting.
  • Postmark. Postmark is a transactional email service that offers free DMARC reporting tool for simple setups or a version with more features for a small monthly fee.

Either way you go, you may only need DMARC reporting while your safely rollout DMARC.

What DMARC will not protect your from

While DMARC can help, there are still attack vectors for your email sending that it can't protect you from. Here are a few:

Very similar looking domains. An attacker registers northloopfinancial.net (not .com), sets up valid SPF and DKIM, and passes DMARC on their .net own domain. Your policy has no reach over a domain you do not own. To every receiver those emails are fully authenticated.

Display-name impersonation. The name on the mail shows "Northloop Financial Security", but the actual address behind it is [email protected]. DMARC only ever checks the domain. It has nothing to say about the friendly name which is very visible to end users so this doesn't raise any flags.

This is where BIMI becomes immensely helpful. While these senders may still be able to do things that impersonate your brand, if your emails always contain a logo and verified check mark (VMC only), you're training your customers to notice that and while SPF, DKIM, and DMARC may pass on a domain, not seeing a logo will tip them off that something is amiss.

BIMI may be useful brand awareness tool, but it's also a visual indicator of the underlying security of an email.

On this page