SPF, DKIM, and DMARC
The underlying email security required before a BIMI logo can be shown
BIMI doesn't work on its own. It's a reward layered on top of email authentication that should already be in place: your logo only shows up once a receiving mail server can prove an email claiming to be from you is actually from you. That proof comes from three DNS-based standards — SPF, DKIM, and DMARC — configured together.
This guide explains what each one does and why BIMI depends on it. It also includes the technical detail (record syntax, tags, rollout steps) in the event that someone else on your team manages your DNS or email infrastructure.
If your organization already sends authenticated email reliably, e.g. your marketing and transactional emails don't land in spam, you may have some or all of this in place already. It's still worth reviewing against the specific requirements below, since "good enough to avoid spam" isn't always the same as "good enough for BIMI."
How to think about the roles of each
Imagine your company's email domain is a venue, and every email you send is a guest trying to get in.
- SPF is the guest list. It's a public record saying which mail servers are allowed to send email on your behalf.
- DKIM is a tamper-evident wristband. It cryptographically signs each email, so the receiving server can tell the message wasn't altered in transit and really did originate from a server you authorized.
- DMARC is the policy at the door. It tells the receiving server what to do if a message shows up without a valid wristband or from someone not on the list, and it's what ties the "from" address people actually see to the checks above.
BIMI's logo is essentially a badge the venue hands out, but only to guests who cleared the door policy. If your DMARC policy doesn't actually enforce anything (or SPF/DKIM aren't configured correctly), there's no reliable door policy, so BIMI has nothing to attach the badge to.
Setup ording matters
These three should be set up in sequence, not all at once:
- SPF and DKIM first. These authenticate individual messages.
- DMARC second, and sometimes gradually. DMARC relies on SPF and DKIM working correctly, and moving straight to a strict DMARC policy before you're sure every legitimate sending source is accounted for can cause real email (invoices, password resets, marketing campaigns) to get silently rejected.
What to gather before you begin
Before you begin auditing and updating your domain(s) DNS records in preparation for BIMI, you'll want to start by gather the following first:
- All of the domains you use for email sending (e.g. example.com).
- A list of the services you send email from where you'd like to have your logo appear. Typically high trust sources are what provide the most impact. Transactional email services, billing systems, support desks, CRMs, marketing platforms just to name a few.
Note that you'll want to keep a list of the domains you use for email sending as that will also be needed for purchasing a mark certificate later.
SPF (Sender Policy Framework)
What is it
A DNS TXT record listing every mail server or service authorized to send email for your domain.
Why it's important for BIMI
SPF is one of the two ways a message can pass DMARC authentication (the other is DKIM). It's also usually the easier one to get wrong, because most organizations send email from more services than they initially realize, an email marketing platform, a helpdesk tool, an HR or payroll system, in addition to normal employee email.
What it looks like
northloopfinancial.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"v=spf1marks it as an SPF record.include:adds an authorized sending source. There's one for every service that sends email as your domain.-allat the end means "nothing else is authorized," a hard fail. A softer~allexists, but a hard fail is the stronger, recommended setting.
SPF has a hard limit of 10 DNS lookups per check. Organizations using several sending services can hit this without realizing it, which causes SPF to fail silently. This is worth flagging to whoever owns your DNS, since it's a common, easy-to-miss failure mode.
Who typically handles this
Whoever manages DNS, usually IT or infrastructure, working from a list of every service that sends email on the company's behalf. Building that list is often the part that requires input from marketing, sales, and support teams too, since they may use tools that send email without IT's direct involvement.
DKIM (DomainKeys Identified Mail)
What is it
A cryptographic signature added to each outgoing email, verified using a public key published in your DNS.
Why it's important for BIMI
DKIM is the more resilient of the two authentication methods, because it stays valid even when a message is forwarded (SPF typically breaks on forwarding, since the forwarding server isn't on your authorized list). DMARC alignment via DKIM is generally the more reliable path to a consistently passing, BIMI-eligible message.
What it looks like
Each sending service generates its own key pair and gives you a DNS record to publish, typically at a subdomain called a selector:
google._domainkey.northloopfinancial.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."- The selector (
googlehere) lets you run multiple DKIM keys at once, one per sending service. p=is the public key itself, provided by the sending service.
Who typically does this
This one's mostly hands-off for DNS. Each sending platform (your email provider, ESP, CRM, etc.) generates the key and gives you exact instructions and the exact record to add. IT/infrastructure just needs to add what each vendor provides to your domain's DNS records. So if you send email from 5 different services, you should have 5 DKIM records. One per service.
DMARC only needs SPF or DKIM to pass, so a service without DKIM isn't automatically disqualified. But SPF alignment is fragile, it breaks on forwarding and is capped at 10 DNS lookups, so a service relying on SPF alone is at real risk of failing DMARC. When that happens, the logo simply won't appear on mail from that specific service, even though it shows up fine on everything else. This is one of the more common reasons a company's logo shows up on some of their emails but not others: one sending service, e.g. a helpdesk or marketing tool, was never given its own DKIM key. Setting up DKIM for every sending service is the reliable way to avoid this.
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 toquarantineorreject. A policy ofp=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=rejectis 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=100applies 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:
p=none— Publish DMARC in monitoring mode. Nothing is enforced yet, but you start receiving reports on what's passing and failing.- Review the reports for a few weeks and fix any legitimate sending sources that are failing SPF/DKIM.
p=quarantine— Move to enforcement once reports look clean. This is enough to qualify for BIMI.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.
Summary: what BIMI specifically requires
| Record | Minimum requirement for BIMI |
|---|---|
| SPF | Valid record authorizing all legitimate sending sources |
| DKIM | Configured and passing for all legitimate sending sources |
DMARC policy (p=) | quarantine or reject (p=none does not qualify) |
DMARC coverage (pct=) | 100 |
| Alignment | At least one of SPF or DKIM must align with the visible "From:" domain |
Who should be involved
This work almost always sits with IT, infrastructure, or security, whoever already has access to your DNS provider and visibility into which services send email on your domain's behalf. If that's not you, this guide is written so you can hand it directly to them. The one thing worth doing before you hand it off: a list of every tool or platform that sends email using your domain, since that's the input they'll need to build SPF and DKIM correctly, and it's often faster for someone outside IT to compile.