SPF and DKIM
The underlying email security required to validate you as a sender
BIMI isn't a standalone email feature you configure at different email service providers. It's the final visual layer on top of email authentication standards that prove a particular email you sent did indeed come from you. You may already have some form of email authentication in place but that is transparent to your end recipients without BIMI. What's great about this is that you may want your logo to show for brand awareness or for polish in your emails, but with BIMI you're actually also getting the benefit of increasing your email security posture too.
This guide explains the first two layers of email security required for BIMI, Sender Policy Framework (SPF) and Domainkeys Identified Mail (DKIM). You'll learn what they are, how to configure them properly, and how this gets you one step closer to your logo showing in inboxes.
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 to ensure you're setup correctly for BIMI.
What are SPF and DKIM?
These are both types of DNS record you configure for the domains your sending emails from, but, they serve different purposes:, SPF is a DNS record for your domain that says who is (or more specifically which servers are) allowd to send emails on your behalf. For example
- SPF is a DNS record that says who is (or more specifically, which servers) are allowed to send emails on your behalf. If you you use Google Workspace, you'll likely see "google" somewhere in your domain SPF record.
- DKIM is a DNS record that enables a receiving mail server to confirm that a message wasn't altered in transit and did originate from a server you authorized. You often see this with support platforms like Zendesk when you want to respond to support questions from a domain you own vs. the support platform provided one. For any service you use that you send emails from using your own domain, you'll have a separate DKIM record for.
Both of these authenticate individual email message and ensure that the mail server was allowed to send an email with your domain and you authorized that mail server to do so.
What to gather before you begin
Before you begin auditing and updating your domain(s) SPF and DKIM 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 the easier one to get wrong because most organizations send email from many different services like, a email marketing platforms, a helpdesk tool, an HR or payroll system, etc.
What it looks like configured at DNS
Imagine a financial services company is sending emails from northloopfinancial.com. This is the SPF record they may have configured for their domain. Note that this is a single record with multiple senders listed (google, sendgrid).
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.
How to configure SPF for BIMI
For every email sending source, you'll want to add an include in the DNS record for that source to denote that those servers are allowed to send email on your behalf. Imagine if Northloop Financial also used Zendesk for helpdesk software. They might update their SPF record to:
northloopfinancial.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all"Most services that send email will include documentation on how to add their specific information for your domain as this helps reduce the likelyhood of emails they send on your behalf landing in spam. For example, here's the Zendesk article on updating your record to reference Zendesk:
DKIM (DomainKeys Identified Mail)
What is it
There are two pieces that togther make up DKIM. First, it's a DNS record added to your domain just like SPF. It's also cryptographic signature added to each outgoing email which receiving mail servers can use to prove (using the DNS record) an email actually came from the domain it claims to have come from,
Why it's important for BIMI
DKIM enables a mail server to prove that the email came from a source that is authorized to send emails with a "from" of a specific domain. You typically see this with services like helpdesk/support tools when configuring "custom domains" so emails are sent using your own domain which feels more legitimate and means your support emails are less likely to end up in spam. Because BIMI is a visual representation that the sender who who they say they are, having DKIM setup properly is an underlying mechanism to prove it.
What it looks like configured at DNS
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.
How to configure DKIM for BIMI
For the most part, setting up DKIM means going to all the services you send emails from that you use a "custom domain" (e.g. support platforms) and having them generate a cryptographic key that you can use to then update your DNS records. For example, here's Intercomm's guide on setting up a custom domain and authenticating it.
https://www.intercom.com/help/en/articles/9744849-connect-your-email-support-channel#h_b761c867b8
This is common for many platforms you send emails from using your domain as it greatly reduces bounce rates or landing in spam. You could very well already be setup here but it's worth confirming.
What's next
SPF and DKIM are the first two layers of email authentication. But BIMI requires one more configuration to be setup which works with SPF and DKIM. Read about DMARC to fit the final piece of the DNS puzzle together.