[[Category:InboxSys]]
[[Category:Deliverability]]
[[Category:Authentication]]
[[Category:Reputation]]

'''Brand Indicators for Message Identification''', or '''BIMI''', is a specification allowing for the display of brand logos in the inbox. BIMI is currently an RFC [https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/ draft].

=Prerequisites=

BIMI requires a valid and passing [[DMARC]] record, with the policy set to either "reject" or "quarantine".

=DNS record=

By default, a BIMI DNS record is set on a subdomain named '''default._bimi'''. In this case, "default" is the '''selector'''. It contains the following elements:

* A BIMI version (Currently only '''BIMI1''' is available).
* A link to a BIMI '''logo'''.
* Optional: A link to a BIMI certificate ('''VMC''' or '''CMC''').
* Optional: Avatar Preference - in case a user-avatar is also present, which to prefer. Options "bimi" or "personal". In case this is not set, it defaults to "bimi".

BIMI DNS records looks like this:

<pre>
$ host -t txt default._bimi.example.com
default._bimi.example.com descriptive text "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/image/certificate.pem; s=bimi"
</pre>

Alternatively, it's also possible to use a different selector for the BIMI record. For example, if the following record is found:

<pre>
$ host -t txt default._bimi.example.com
default._bimi.example.com descriptive text "v=BIMI1; s=myselector;"
</pre>

The actual BIMI record can be found with this query:

<pre>
$ host -t txt myselector._bimi.example.com
myselector._bimi.example.com descriptive text "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/image/certificate.pem;"
</pre>

==On which domains to set a BIMI record==

BIMI records can, just like DMARC records, be placed on the [[Organisational Domain|organisational domain]] as well as on subdomains. A subdomain that has no BIMI record inherits its BIMI record from the organisational domain. If a given selector is not found on a subdomain, the organisational domain is queried with that same selector.

==BIMI logo==

The logo that's included in the "v"-switch of the BIMI DNS record should comply to the folowing:

* It must be in [[wikipedia:SVG_Tiny_P/S|SVG (Tiny P/S)]] format.
* The "version" attribute must be set to "1.2"
* A <title> element must be included that reflects the company name.
* A <desc> (i.e. the "description") element is not required, but this should be included to support accessibility.
* The image must be sqare. Length and width should have the same value.
* The image size shouldn't exceed 32 Kb.
* No external links or references (other than to the specified XML namespaces) should be included.
* No scripts, animation, or other interactive elements should be included.
* No "x=" or "y=" attributes should be included within the <svg> root element.
* The image should not have a transparent background.

==BIMI certificate==

The optional BIMI certificate is used to digitally sign the logo and the [[RFC5322.From|senderdomain]]. It contains other elements, such as an organisation name, a list of domains signed by this certificate and an expiration date. There are 2 types of certificate: '''VMC''' and '''CMC'''. CMC certificates are slightly less expensive than VMC certificates. They are issued by certification authorities (Entrust or DigiCert) recognized by the [https://bimigroup.org/ BIMI Working Group]. 

It is [https://community.letsencrypt.org/t/verified-mark-certificates/176835 not possible to create valid VMC or CMC certificates] with a free service such as [https://letsencrypt.org Letsencrypt].

===Difference between VMC and CMC certificates===

* '''VMC''' means "'''Verified Mark Certificate'''"
* '''CMC''' means "'''Common Mark Certificate'''"

{| class="wikitable"
|+ VMC vs. CMC
! Requirement !! VMC !! CMC
|-
! scope="row"| Trademark Registration
| Yes
| No
|-
! scope="row"| Logo in use
| Can be used immediately
| Must have been in use since 1 year
|}

=BIMI adoption by ISPs=

{| class="wikitable"
|+ Email clients supporting BIMI
! Client !! VMC !! CMC !! Self-Asserted !! Comment
|-
! scope="row"| AOL / Yahoo!
| No
| No
| Yes
| Only for bulk messages from high-reputation domains
|-
! scope="row"| Apple Mail
| Yes
| No
| No
|-
! scope="row"| Fastmail
| No
| No
| Yes
|-
! scope="row"| Gmail
| Yes
| Yes
| No
| Only VMC certificates get a blue checkmark.
|-
! scope="row"| La Poste
| Yes
| No
| Yes
| Domains without VMCs must be submitted and manually verified by La Poste.
|}

=Useful links=

* [https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/ BIMI draft]
* [[wikipedia:Brand_Indicators_for_Message_Identification]]
* [https://bimigroup.org/creating-bimi-svg-logo-files/ Creating BIMI svg logo files]

Brand Indicators for Message Identification (BIMI)

2025-02-03T18:37:28Z

Sebastian:

DomainKeys Identified Mail (DKIM)

2025-02-01T03:45:24Z

Sebastian:

[[Category:Deliverability]]
[[Category:Authentication]]
'''DKIM (DomainKeys Identified Mail)''' is an E-Mail domain [[:Category:Authentication|authentication]] method, designed to protect E-Mail sender domains ([[RFC5322.From]]) from forgery (spoofing). DKIM is defined in [https://www.rfc-editor.org/rfc/rfc6376.html RFC 6376] with updates in [https://www.rfc-editor.org/rfc/rfc8301.html RFC 8301] and [https://www.rfc-editor.org/rfc/rfc8463.html RFC 8463]. DKIM is a requirement of [[DMARC]].

=Functionality=

Each message is digitally signed by the sending server when it's being sent. DKIM works with a public key and a private key for signing and a selector for identification.

==Selector==

The selector assures that multiple DKIM records can be set on a single sender domain. Selectors can be any phrase. Here's an example from RFC 6376:

<pre>
selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even an individual
user.
</pre>

The selector is used to compile a subdomain for the DKIM DNS TXT record. If, for example, the selector is "reykjavik" and the senderdomain is "email.example.com", the following subdomain should be created: ''reykjavik._domainkey.email.example.com''.

==Public and private key==

The public key is publicly accessible in this [[DNS]] TXT record. The full content of the DNS TXT record may look like this:

<pre>
v=DKIM1; t=s; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0vuPa8g6qdfYLi9TWfbMzFoijdNfJC6/a0uGfIj6fOr+z1fJlOsM1DhKaEaSkNeI0ClKjLx9648CfMl02TxViTvG1Ne2sDsFvGc53NzEd65I2BsPuLpBsHo5zXbZ1ZvLhFm+iOjXlPnD1WlOeQuDhFdIdR+1lWt5aExNwBvIqBr+nYfJt094h9fUwXxMpJ+75GtBdAo3j2nOlWlZtCkWnDmCsXd0j6nNrHz0fO8VqCcJmQsP1ThUgBlO7T3L4PiVg1yHbDpKyTgVb6zHpYt/cXiKmIxVn6nQoDxL9ZfQ2EmVi7hUfMcSoFpWdIpYuOnMmPgPk47J+YZjv4N2X6UpSQIDAQAB
</pre>

There are numerous switches that can be applied to a DKIM record. The ones we see here are:

{| class="wikitable" style="margin:auto"
|+ DKIM record switches
|-
! Switch !! Example !! Description !! Required
|-
! scope="row"| v
|| <code>v=DKIM1</code> || Version || Required
|-
! scope="row"| t
|| <code>t=s</code> || Alignment / Testing || Recommended
|-
! scope="row"| k
|| <code>k=rsa</code> || Key type || Optional
|-
! scope="row"| p
|| <pre>p=LONG KEY</pre>
|| Public key || Required
|}

The long key (p-switch) is the public key that matches the private key on the signing server. This key can be obtained from your [[ISP]]/[[ESP]] or your mail server administrator.

The minimum length for DKIM keys is 1024 bit. The minimum recommended length for DKIM keys is 2048 bit.

Once a message has been received, the DKIM signature can be found in the [[E-Mail header]] and it looks like this:

<pre>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email.example.com;
s=reykjavik; t=1117574938; i=@email.example.com;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
h=To:Message-ID:Date:Content-Type:Subject:From:List-Unsubscribe:
From:To:Cc:Subject;
b=nXiJoG9QuMwPyLsCw0yCx2bCd92K89bGgOb/nUsFpUuHvRfM9M1QnQaPdTaJu7pBm
2Yl7xHdSqXj6cU2Y2MoDeFgBkFpSa14ZiByX7VwPq8eGiNzB2580l52LtBeVxKtWrH
By9oU96j4h7bMxRgYvTe/r7dWaHbGaIwMwNc4eXa=
</pre>

The meaning of the individual switches we see in the example is as follows:

{| class="wikitable" style="margin:auto"
|+ DKIM header switches
|-
! Switch !! Example !! Description !! Required
|-
! scope="row"| v
|| <code>v=1</code> || Version || Required
|-
! scope="row"| a
|| <code>a=rsa-sha256</code> || Key type / Signing algorithm|| Required
|-
! scope="row"| c
|| <code>c=relaxed/relaxed</code> || Canonicalization algorithm(s) for header and body || Optional
|-
! scope="row"| d
|| <code>d=email.example.com</code> || Signing Domain Identifier (SDID) || Required
|-
! scope="row"| s
|| <code>s=reykjavik</code> || Selector || Required
|-
! scope="row"| t
|| <code>t=1117574938</code> || Timestamp || Recommended
|-
! scope="row"| i
|| <code>i=@email.example.com</code> || Sending domain (AUID) || Optional
|-
! scope="row"| bh
|| <code>bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</code> || Body hash || Required
|-
! scope="row"| h
|| <pre>h=To:Message-ID:Date:Content-Type:Subject:From:List-Unsubscribe:
From:To:Cc:Subject;</pre>
|| list of header fields that have been signed || Required
|-
! scope="row"| b
|| <pre>b=nXiJoG9QuMwPyLsCw0yCx2bCd92K89bGgOb/nUsFpUuHvRfM9M1QnQaPdTaJu7pBm
2Yl7xHdSqXj6cU2Y2MoDeFgBkFpSa14ZiByX7VwPq8eGiNzB2580l52LtBeVxKtWrH
By9oU96j4h7bMxRgYvTe/r7dWaHbGaIwMwNc4eXa=</pre>
|| Signature of headers and body || Required
|}

=Alignment=
''Main article: [[Alignment]]''

DKIM is aligned when the sender domain matches the signing domain. In correct phrasing: when the RFC5322.From domain (also "Agent or User Identifier"), represented in the i-switch, matches the "Signing Domain Identifier", represented in the d-switch.

=Double DKIM=
''Main article: [[Double DKIM]]''

=DKIM in InboxSys app=

To check your DKIM record, [[Sending a message to the seedlist|send a message to your seedlist]] and look in the [[:Category:Authentication|authentication]] section of the [[:Category:E-Mail analysis|E-Mail analysis]]. Optionally, you can use the [https://app.inboxsys.com/domainchecker.php domainchecker] to check your DKIM record.

=Useful links=

* [https://international.eco.de/download/223621/ E-Mail authentication for senders]
* [https://international.eco.de/download/209121/ E-Mail authentication for recipients]
* [https://www.rfc-editor.org/rfc/rfc6376.html RFC 6376]
* [https://www.rfc-editor.org/rfc/rfc8301.html RFC 8301]
* [https://www.rfc-editor.org/rfc/rfc8463.html RFC 8463]
* https://www.mailhardener.com/kb/how-to-use-dkim-with-ed25519
* [https://app.inboxsys.com/domainchecker.php Domainchecker]

Sender Policy Framework (SPF)

2025-02-01T03:44:18Z

Sebastian:

[[Category:Deliverability]]
[[Category:Authentication]]
'''SPF (Sender Policy Framework)''' is an E-Mail domain [[:Category:Authentication|authentication]] method, designed to protect E-Mail sender domains ([[RFC5321.MailFrom]]) from forgery (spoofing). SPF is defined as a "proposed standard" in [https://www.rfc-editor.org/rfc/rfc7208.html RFC 7208]. SPF is required for [[DMARC]] and it's the base for [[SenderID]].

=Functionality=

An SPF record is a [[DNS]] TXT record that defines which IPs are allowed to send with the domain in question. An example of a very simple SPF record is:

<pre>
example.com descriptive text "v=spf1 ip4:1.2.3.4 ip4:4.3.2.0/24 -all"
</pre>

In this example, the domain "example.com" is strictly and only allowed to send from IP ''1.2.3.4'' or from the [[CIDR]] network ''4.3.2.0/24'' (4.3.2.1 - 4.3.2.254). This example-record consists of 3 parts:

# Version (v=spf1)
# Method (ip4:1.2.3.4 ip4:4.3.2.0/24)
# Policy qualifier (-all)

==Version==

Since SenderID is deprecated, there is only one SPF version: spf1.

==Method==

SPF offers 8 mechanisms:

{| class="wikitable" style="margin:auto"
|+ SPF methods
|-
! Switch !! Example !! Description
|-
! scope="row"| A
|| <code>A</code> || Matches the domain's A-record.
|-
! scope="row"| All
|| <code>ALL</code> || Matches always. This mechanism is rarely used.
|-
! scope="row"| EXISTS
|| <code>exists:example.com</code> || Matches the IP behind the domain. Can be used with [https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/ SPF macro language] and is rarely used.
|-
! scope="row"| IP4
|| <code>ip4:4.3.2.0/24</code> || Includes IPv4 addresses.
|-
! scope="row"| IP6
|| <code>ip6:2001:db8:a::123/64</code> || Includes IPv6 addresses.
|-
! scope="row"| INCLUDE
|| <code>include:subdomain.example.com</code> || Include the results of the SPF record of another domain.
|-
! scope="row"| MX
|| <code>MX</code> || Matches all IPs in the domain's [[MX-Record|MX-record]].
|-
! scope="row"| PTR
|| <code>PTR</code> || Matches only if the reverse DNS (PTR) for the client's address is in the domain in question and the PTR record resolves back to the domain's A or AAAA record. Should be avoided!
|}

==Policy qualifier==

The policy qualifier defines what to do when all previous methods fail. The following qualifiers are available:

{| class="wikitable" style="margin:auto"
|+ SPF policy qualifiers
|-
! Switch !! Name
|-
! scope="row"| +all
|| PASS || SPF returns PASS, even if it fails. This renders SPF obsolete and is not considered valid by all [[ISP]]s.
|-
! scope="row"| ?all
|| NEUTRAL || SPF returns NEUTRAL, even if it fails.
|-
! scope="row"| ~all
|| SOFTFAIL || SPF returns SOFTFAIL when it fails.
|-
! scope="row"| -all
|| FAIL || SPF returns FAIL when it fails. Can break things when using [[mailing lists]].
|}

Forwarding an E-Mail with the RFC5321.MailFrom unchanged, but from a different IP, breaks SPF authentication. For this reason ''~all'' is sometimes preferred over ''-all''.

=Alignment=
''Main article: [[Alignment]]''

SPF aligns when the RFC5321.MailFrom domain matches the [[RFC5322.From]] domain. In laymen terms: When the envelope-from domain matches the sender domain.

=Controversy around SPF=
''Main article: [[Controversy around SPF]]''

=SPF in InboxSys app=

To check your SPF record, [[Sending a message to the seedlist|send a message to your seedlist]] and look in the [[:Category:Authentication|authentication]] section of the [[:Category:E-Mail analysis|E-Mail analysis]]. Optionally, you can use the [https://app.inboxsys.com/domainchecker.php domainchecker] to check your SPF record.

=Useful links=

* [https://international.eco.de/download/223621/ E-Mail authentication for senders]
* [https://international.eco.de/download/209121/ E-Mail authentication for recipients]
* [https://www.rfc-editor.org/rfc/rfc7208.html RFC 7208]
* [https://app.inboxsys.com/domainchecker.php Domainchecker]
* [[wikipedia:Sender_Policy_Framework]]

Sender Policy Framework (SPF)

2025-02-01T03:44:05Z

Sebastian:

[[Category:Deliverability]]
[[Category:Authentication]]
'''SPF (Sender Policy Framework)''' is an E-Mail domain [[:Category:Authentication|authentication]] method, designed to protect E-Mail sender domains ([[RFC5321.MailFrom]]) from forgery (spoofing). SPF is defined as a "proposed standard" in [https://www.rfc-editor.org/rfc/rfc7208.html RFC 7208]. SPF is required for [[DMARC]] and it's the base for [[SenderID]].

=Functionality=

An SPF record is a [[DNS]] TXT record that defines which IPs are allowed to send with the domain in question. An example of a very simple SPF record is:

<pre>
example.com descriptive text "v=spf1 ip4:1.2.3.4 ip4:4.3.2.0/24 -all"
</pre>

In this example, the domain "example.com" is strictly and only allowed to send from IP ''1.2.3.4'' or from the [[CIDR]] network ''4.3.2.0/24'' (4.3.2.1 - 4.3.2.254). This example-record consists of 3 parts:

# Version (v=spf1)
# Method (ip4:1.2.3.4 ip4:4.3.2.0/24)
# Policy qualifier (-all)

==Version==

Since SenderID is deprecated, there is only one SPF version: spf1.

==Method==

SPF offers 8 mechanisms:

{| class="wikitable" style="margin:auto"
|+ SPF methods
|-
! Switch !! Example !! Description
|-
! scope="row"| A
|| <code>A</code> || Matches the domain's A-record.
|-
! scope="row"| All
|| <code>ALL</code> || Matches always. This mechanism is rarely used.
|-
! scope="row"| EXISTS
|| <code>exists:example.com</code> || Matches the IP behind the domain. Can be used with [https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/ SPF macro language] and is rarely used.
|-
! scope="row"| IP4
|| <code>ip4:4.3.2.0/24</code> || Includes IPv4 addresses.
|-
! scope="row"| IP6
|| <code>ip6:2001:db8:a::123/64</code> || Includes IPv6 addresses.
|-
! scope="row"| INCLUDE
|| <code>include:subdomain.example.com</code> || Include the results of the SPF record of another domain.
|-
! scope="row"| MX
|| <code>MX</code> || Matches all IPs in the domain's [[MX-Record|MX-record]].
|-
! scope="row"| PTR
|| <code>PTR</code> || Matches only if the reverse DNS (PTR) for the client's address is in the domain in question and the PTR record resolves back to the domain's A or AAAA record. Should be avoided!
|}

==Policy qualifier==

The policy qualifier defines what to do when all previous methods fail. The following qualifiers are available:

{| class="wikitable" style="margin:auto"
|+ SPF policy qualifiers
|-
! Switch !! Name
|-
! scope="row"| +all
|| PASS || SPF returns PASS, even if it fails. This renders SPF obsolete and is not considered valid by all [[ISP]]s.
|-
! scope="row"| ?all
|| NEUTRAL || SPF returns NEUTRAL, even if it fails.
|-
! scope="row"| ~all
|| SOFTFAIL || SPF returns SOFTFAIL when it fails.
|-
! scope="row"| -all
|| FAIL || SPF returns FAIL when it fails. Can break things when using [[mailing lists]].
|}

Forwarding an E-Mail with the RFC5321.MailFrom unchanged, but from a different IP, breaks SPF authentication. For this reason ''~all'' is sometimes preferred over ''-all''.

=Alignment=
''Main article: [[Alignment]]''

SPF aligns when the RFC5321.MailFrom domain matches the [[RFC5322.From]] domain. In laymen terms: When the envelope-from domain matches the sender domain.

=Controversy around SPF=
''Main article: [[Controversy around SPF]]''

=SPF in InboxSys app=

To check your SPF record, [[Sending a message to the seedlist|send a message to your seedlist]] and look in the [[:Category:Authentication|authentication]] section of the [[:Category:E-Mail analysis|E-Mail analysis]]. Optionally, you can use the [https://app.inboxsys.com/domainchecker.php domainchecker] to check your SPF record.

=Useful links=

* [https://international.eco.de/download/223621/ E-Mail authentication for senders]
* [https://international.eco.de/download/209121/ E-Mail authentication for recipients]
* [https://www.rfc-editor.org/rfc/rfc7208.html RFC 7208]
* [https://app.inboxsys.com/domainchecker.php domainchecker]
* [[wikipedia:Sender_Policy_Framework]]

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

2025-02-01T03:43:19Z

2024-10-07T14:16:24Z

Sebastian:

[[Category:InboxSys]]
[[Category:Reporting]]
[[:Category:InboxSys|InboxSys]] monitors IPs on a daily base and stores the results for 30 days. Not only the sending IPs of campaigns that have been sent to the [[:Category:Seeds|seedlist]] are tested, but also the IPs that can be found in the default and alternative IPs in your [[Domain and IP settings]] (account settings -> domain settings).

The folowing items are being monitored:

* PTR consistency
* Blocklistings
* Whitelistings
* SenderScore
* and if an [[SNDS|SNDS API key is present in account settings]], SNDS results

Clicking on single IPs visualizes the IP history over the past 30 days. The Date-field allows switching the current view to any date in the past 30 days.

The "search IPs" field can be used to search for single IPs. /24 Netblocks can be found by searching for the first 3 octetts in an IP address. In addition to that, the "search IPs" field will match non-numeric phrases, such as blacklists or whitelists, as well.

The full list, or the current output, can be exported in CSV.