Email authentication was never part of the original specification for email, as email was predominantly used between academics who trusted each other.

With the exponential growth of email’s reach since its inception in 1971, the implementation of robust security measures has become a necessity to counter the escalating security concerns, particularly those arising from malicious email use.

It is outside the scope of this article to discuss each of the four protocols in extensive detail. I wanted to give you a brief introduction and overview of each protocol.

First, some bad news …

Having all four of these perfectly implemented is NOT a magic pill that will guarantee delivery and inbox placement!

These protocols are critically important to secure your email-sending domain and your brand, though. The first three are no longer nice to have; they are a must-have!

Also, be aware that it is EASY to get these wrong, which will cause your email to either go to spam or be rejected outright! Work with someone who knows what they are doing!

Quick summary before diving into the details …

  • SPF – Specify which mail servers are allowed to mail on behalf of your domain
  • DKIM – Digital signature in the email header to ensure the message is not modified during transit
  • DMARC – Policy to tell mailbox providers what to do when either SPF or DKIM fails
  • BIMI – Display brand logos in inboxes when email is fully authenticated to help build brand trust and recognition

Now, let’s dive into a bit more detail on each of these.


What is a SPF record?

An SPF (Sender Policy Framework) record is a special type of DNS record that specifies which mail servers are allowed to send emails for your domain. Think of DNS TXT records as notes that domain owners can add to their domain settings. Originally meant for general information, these records now have various uses, including email authentication.

The SPF system was created because the email-sending protocol, SMTP (Simple Mail Transfer Protocol), doesn’t verify the sender’s address on its own. Without something like SPF, anyone could send an email pretending to be from someone else’s domain, which can be very misleading and harmful.

Imagine SPF records as a guest list at a party. If someone tries to enter but isn’t on the list, the bouncer will turn them away. Similarly, if an email comes from a server that isn’t listed in the SPF record, the receiving server may reject it or mark it as suspicious.

SPF is a fundamental method to check if emails are coming from a trustworthy source.

A while back, SPF records had their own specific type of DNS record, but now they are always stored as TXT records.

How is an SPF record checked?

Here’s how mail servers verify an email using an SPF record:

  • Server A sends an email. Its IP address is, and it uses email@returnpath.domain as the return-path address. (The return-path address is used to handle bounced emails and is different from the “from” address.)
  • The receiving mail server (Server B) looks at the return-path domain and retrieves its SPF record.
  • Server B then checks the SPF record to see if the IP address of Server A is listed as an authorized sender. If the IP address is found in the SPF record, the verification is successful, and the email is accepted. If the IP address is not listed, the verification fails, and the email is either rejected or flagged as spam.

What does an SPF record look like?

What a typical SPF record looks like:

v=spf1 mx a ip4: ip4: ~all

Let’s break that record down:

  • v=spf1 – Basically says that this is an SPF record. Every SPF record has to start with this.
  • mx – Specifies that all MX servers of this domain is allowed to send on it’s behalf.
  • a – Specifies that all A record IPs of this domain is allowed to send on it’s behalf.
  • ip4: – This authorizes specific IP(s) to send email for the domain
  • – The “include” tag tells the server what third-party domains are authorized to send emails on behalf of the domain. This tag signals that the content of the SPF record for the included domain ( should be checked, and the IP addresses it contains should also be considered authorized. Multiple domains can be included within an SPF record but this tag will only work for valid domains.
  • ~all – An SPF record always ends in all. It has 3 different options:
    • ?all: Neutral – Implies no policy, allowing the server to treat emails as it sees fit.
    • ~all: SoftFail – Suggests that emails not matching the policy should be marked but not rejected.
    • -all: Fail – Indicates that emails not matching the policy should be rejected.


What is DKIM?

DomainKeys Identified Mail (DKIM) helps prevent domain impersonation by cryptographically signing a message, proving that it was sent by the actual domain, as well as ensuring that the message was not modified during the sending process by a man-in-the-middle kind of attack.

How does DKIM work?

There are two main parts to DKIM:

  1. The TXT DNS record
  2. The DKIM header of the emails, which gets inserted during the sending process

DKIM uses public-key cryptography to authenticate emails.

There are two keys. One public which is published in DNS and is used by the receiving server to authenticate the message. One private, which is used to create and sign the DKIM header of outgoing emails. The private one is securely stored on the sending servers only.

It is recommended good practice to rotate DKIM keys every 6 months to a year, although for weaker keys like 1024 bit keys, it is better to rotate them more regularly.

All emails sent from a domain include a DKIM header, which contains a section of data that is signed with the private key. An email server can check the DKIM DNS record, obtain the public key, and use the public key to verify the digital signature.

This process also ensures that the email has not been changed in transit. The digital signature will not be verified if email headers or the email body have been altered.

What does a DKIM record look like?

Most DNS TXT records are stored at the root domain level.

DKIM is different here. It uses a special subdomain to identify the specific selector for the key, enabling a single domain to have many DKIM keys.

It looks like this: [selector]._domainkey.[domain]

The domain is the email domain name. ._domainkey. is included in all DKIM record names.

So, what exactly does a DKIM record look like in DNS?


As with SPF, the record starts with a version of DKIM and is always required: v=DKIM1;

The k= part, if present, is the key type. “rsa” is the default, and assumed if k= is missing.

p= is the public key, and like v=, is required for the record to be considered valid.

What does a DKIM header look like?

The sending email server generates a digital signature by using a combination of email headers, the email body (actually a hashed version of the email body), and its private key. This digital signature is then added to the email in the DKIM header.

The DKIM header is just one of many headers attached to an email. Most email programs hide these headers unless the user chooses to view them. For instance, in Gmail, you can see an email’s header by clicking on the three vertical dots in the top right corner of the email and selecting “Show original.”

Here is an example of a DKIM header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;
s=c37; bh=D2X10y20Gt3w37GHIim4YfqGBqXjUaE6Fb8aasGSwjM=;

Lets break that header apart a bit:

  • v= – Version of DKIM
  • a= – This is the algorithm being used to created the hashes in b= and bh=
  • c= – Specifies how the email content has been prepared for signing. It stands for “canonicalization,” which is a way of formatting the email to ensure it looks the same when it’s sent and received. The “c=” tag usually has two parts, separated by a slash. The first part refers to the headers, and the second part refers to the body of the email. For example, c=relaxed/relaxed means both the headers and the body have been “relaxed,” which allows for some minor changes like extra spaces or line breaks. If it were c=simple/simple, it would mean no changes are allowed, and everything must match exactly. By using the “c=” tag, DKIM can still verify an email even if some small, unimportant changes happen during transmission.
  • d= – The sending domain in the “from address”
  • h= – Lists the email headers that are included in the digital signature. These headers are part of what the sending server uses to create the signature. When the receiving server checks the signature, it also checks these headers to make sure the email hasn’t been tampered with. For example, the “h=” tag might look like this in a DKIM header: h=from:subject:to:date;. This means the “from,” “subject,” “to,” and “date” headers are all included in the DKIM signature. If any of these headers are changed, the signature won’t match, and the email might be flagged as suspicious.
  • s= – The DKIM selector used
  • bh= – Holds a special value called the “body hash.” This is like a digital fingerprint of the email’s content. Here’s how it works: before sending the email, the sending server creates a hash (a unique code) based on the email’s body. This hash is then included in the DKIM header as the “bh=” tag. When the receiving server gets the email, it creates its own hash of the email’s body and compares it to the one in the “bh=” tag. If the two hashes match, it means the email’s body hasn’t been altered during transmission. If they don’t match, it means the email’s content might have been tampered with, and the email could be marked as suspicious.
  • b= – Contains the digital signature of the email. This signature is very important because it helps verify that the email hasn’t been changed after it was sent. Here’s how it works: Before sending an email, the sending server uses a private key (a secret code known only to the sender) to create this digital signature based on the email’s content and headers. This signature is then included in the email’s DKIM header as the “b=” tag. When the receiving server gets the email, it uses a public key (a code available to anyone) to check this signature. If the signature checks out, it confirms that the email content and headers have not been altered in transit. If the signature doesn’t match, it could mean the email was tampered with along the way.


What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a policy that tells mailbox providers what you would like them to do with messages that either fail SPF or DKIM.

DMARC, SPF, and DKIM work in tandem, with DMARC not intended to replace the other two but to bolster their effectiveness, forming a robust email authentication system.

Be aware that each individual mailbox provider decides how to implement DMARC. They can most certainly choose to ignore it or take a different action from the one suggested in your record.

What does a DMARC record look like?

Most DNS TXT records are stored at the root domain level.

DMARC is different here. It uses a special subdomain to identify the DMARC record.

It looks like this: _dmarc.[domain]

The domain is the email domain name. _dmarc. is included in all DMARC record names.

So, what exactly does a DKIM record look like in DNS?

v=DMARC1; p=reject; sp=reject;;; adkim=r; aspf=r; pct=100; fo=1;

As with SPF and DKIM, the record starts with a version of DMARC and is always required: v=DMARC1;

Let’s break down the parts of the record:

  • v= – The version tag. The only allowed value is ‘DMARC1’. If it’s incorrect or the tag is missing, the DMARC record will be ignored.
  • p= – The DMARC policy. Allowed values are ‘none’, ‘quarantine’, or ‘reject’. The default is ‘none,’ which takes no action against non-authenticated emails. It only helps collect DMARC reports and gain insight into your current email flows and their authentication status. ‘quarantine’ marks the failed emails as suspicious, while ‘reject’ blocks them.
  • sp= – The subdomain policy. The subdomain inherits the domain policy tag (p=) explained above unless specifically defined here. Like the domain policy, the allowed values are ‘none,’ ‘quarantine,’ or ‘reject.’
  • rua= – Aggregate report sending destination. It’s the ‘mailto:’ URI that Mailbox Providers use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
  • ruf= – Forensic (Failure) report sending destination. It’s the ‘mailto:’ URI that Mailbox Providers use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
  • adkim= – The DKIM signature alignment. This tag follows the alignment between the DKIM domain and the parent Header From domain. Allowed values are ‘r’ (relaxed) or ‘s’ (strict). ‘r’ is the default and allows a partial match, while the ‘s’ tag requires the domains to be the same.
  • aspf= – The SPF alignment. This tag follows the alignment between the SPF domain (the sender) and the Header From domain. Allowed values are ‘r’ (relaxed) or ‘s’ (strict). ‘r’ is the default, and allows a partial match, while the ‘s’ tag requires the domains to be exactly the same.
  • rf= – The reporting format for failure reports. Allowed values are ‘afrf’ and ‘iodef’.
  • ri= – Reporting interval. Marks the frequency of received XML reports in seconds. The default is 86400 (once a day). Regardless of the set interval, in most cases, ISPs send the reports at different intervals (usually once a day).
  • pct= – The percentage tag. This tag works on domains with ‘quarantine’ or ‘reject’ policy only. It marks the percentage of failed emails a given policy should be applied to. The rest falls under a lower policy. For example, if ‘pct=70,’ on a domain with ‘quarantine’ policy, it applies only 70% of the time. The remaining 30% goes under ‘p=none’. Similarly, if ‘p=reject’ and ‘pct=70,’ ‘reject’ applies to the 70% of failed emails, and the 30% go into ‘quarantine.’
  • fo= – Forensic reporting options. Allowed values are ‘0,’ ‘1,’ ‘d,’ and ‘s.’ ‘0’ is the default value, which generates a forensic report when both SPF and DKIM fail to produce an aligned pass. If either of the protocol outcome is something other than pass, use ‘1.’ ‘d’ generates a report when DKIM is invalid, while ‘s’ does the same for SPF. Define the ruf tag to receive forensic reports. Options are:
    • ‘0’: Generate reports if all authentication methods fail.
    • ‘1’: Generate reports if any authentication method fails.
    • ‘d’: Generate reports for DKIM failures.
    • ‘s’: Generate reports for SPF failures.

What is a DMARC report?

A “rua” DMARC report is a type of report that helps domain owners monitor their email security. The “rua” stands for “Reporting URI for Aggregate Data,” and it tells where to send these reports.

Here’s what a rua DMARC report includes:

  • Summary of Email Traffic: It shows how many emails were sent using your domain.
  • Sender Information: It lists which servers sent these emails.
  • Authentication Results: It shows if the emails passed or failed DMARC checks.
  • Actions Taken: It details what happened to emails that failed the checks (e.g., were they rejected, marked as spam, or delivered anyway?).

Because these reports are very detailed and technical, they are meant to be processed by a DMARC monitoring service. This service will analyze the data and present it in an easy-to-understand way, helping you see if anyone is misusing your domain and how effective your email authentication is.


What is BIMI?

Brand Indicators for Message Identification, or BIMI (pronounced bih-mee), is a standard that lets email inboxes show a brand’s logo alongside their verified emails.

BIMI aims to allow trusted senders to manage how their brand appears in email services. For email providers like Yahoo or Gmail that support BIMI, this means that brands using BIMI can have their chosen logo displayed in their recipients’ inboxes.

Do all mailbox providers support BIMI?

No, not at this time.

You can find a complete list of mailbox providers who currently support and who plan to support BIMI here:

How does BIMI work?

Your DMARC policy must be ‘quarantine’ at 100% or ‘reject’ before publishing a BIMI record.

To comply with BIMI, a company must create and publish a new DNS record that contains a URL to their logo. When a mailbox provider checks your DMARC record (in your “From” domain’s DNS TXT record), it also looks for a BIMI record. This BIMI record includes the URL for your brand’s logo and details about any Verified Mark Certificates (VMC) you might have. If everything matches, the mailbox provider will display your logo.

What is this VMC thing?

A Verified Mark Certificate (VMC) proves that you legally own the trademark for your logo. While VMCs aren’t required by all email providers yet, they might become the standard soon. In fact, Gmail already does require a VMC for logo display.

CNN was the first to get a VMC in 2019, but now you can, too. To qualify, your logo must be trademarked. Then, you’ll need to work with a Mark Verifying Authority (MVA), such as Entrust Datacard or Digicert, to obtain your certificate.

Not all mailbox providers require a VMC, though. In those, your BIMI logo will display, even if you don’t have a VMC.

What does a BIMI record look like?

Most DNS TXT records are stored at the root domain level.

BIMI is different here. It uses a special subdomain to identify the specific selector for the key, enabling a single domain to have multiple BIMI records.

It looks like this: [selector]._bimi.[domain]

The domain is the email domain name. ._bimi. is included in all DKIM record names.

For the most part, the BIMI selector will always be ‘default’. There can be others, but selectors other default is not used much at this point in time.

So, what exactly does a BIMI record look like in DNS?

v=BIMI1; l=; a=

As with DMARC, the record starts with a version of BIMI and is always required: v=BIMI1;

Let’s break down the record.

  • v= – The version tag. The only allowed value is ‘BIMI1’. If it’s incorrect or the tag is missing, the BIMI record will be ignored.
  • l= – Specifies the URL where your brand’s logo is located. This URL points to an image file that email providers will use to display your logo next to your authenticated emails. For the best results, the logo should be in SVG format and meet BIMI’s size and quality standards.
  • a= – Specifies the URL for your Verified Mark Certificate (VMC). This certificate proves that you own the trademark for your logo. This tells the email provider where to find your VMC file. The VMC ensures that your logo is authentic and verified, helping to build trust with your email recipients.


Wow, that was a LOT!

If you read everything to the end here, congrats!

I tried my utmost to make these email authentication protocols understandable and digestible. Still, I also realize that none of this is trivial for non-technical people who don’t live and breathe email. I apologize if I left you perhaps feeling even more confused than when you started reading. That was never my intention.

Please don’t hesitate to reach out if you need any further clarification on anything discussed in this post. I’m here to help.