1 - spf check

We want to make sure that the sender address has not been forged/spoofed*.
* = make the message appear from someone other than the actual source

SPF authentication helps us identifying if the message has been sent through an authorized smtp server.
This information is stored in the domain’s dns, that is a safe place, outside the email message.

Only if the message has NOT been authenticated correctly:
the !! (attention) symbol is added to the subject,
one of the following explanatory notes is inserted in the message header, line “X-RealSender”:

:: spf-none ::       the sender domain contains no information to authenticate the email  
:: spf-softfail ::   the smtp server is not listed among the authorized ones but this case should be treated as a "softfail"  
:: spf-fail ::       the smtp server is not listed among the authorized ones and the email should be rejected or discarded

Sometimes the information recorded at domain level is not correct/understandable.

:: spf-permerror ::  a permanent error has occured (eg. badly formatted SPF record)

SPF check is made against the “Mail From” email address, that is hidden in the email headers.
Only the “From” email address is visible. If their root domains are different, this warning is displayed:

:: spf-diff ::       the "Mail From" and the "From" root domains are different

2 - dkim check

DKIM (DomainKeys Identified Mail) allows senders to prove that the email was actually sent by them and has not been modified after being sent.
It achieves this by affixing a digital signature (seal), linked to a domain name, to each outgoing email message.

Only if the message has NOT been signed correctly:
the !! (attention) symbol is added to the subject,
one of the following explanatory notes is inserted in the message header, line “X-RealSender”:

:: dkim-none ::      no DKIM-Signature headers (valid or invalid) were found  
:: dkim-fail ::      a valid DKIM-Signature header was found, but the signature does not contain a correct value for the message  

Sometimes it’s not possible to execute the check:

:: dkim-invalid ::   there is a problem in the signature itself or the public key record. I.e. the signature could not be processed
:: dkim-temperror :: some error was found which is likely transient in nature, such as a temporary inability to retrieve a public key

When the message has been signed using a different domain, a “diff” notice is added:
This warning will NOT appear if the sender passes the SPF check:

:: dkim-diff ::      the message has NOT been signed by the sender's domain

3 - dmarc domain alignment

DMARC (Domain-based Message Authentication, Reporting and Conformance),
is an email authentication standard, developed to combat spoofed domain mail.

In the chapter “3.1. Identifier Alignment” it says:

   Email authentication technologies authenticate various (and
   disparate) aspects of an individual message.  For example, [DKIM]
   authenticates the domain that affixed a signature to the message,
   while [SPF] can authenticate either the domain that appears in the
   RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
   HELO domain, or both.  These may be different domains, and they are
   typically not visible to the end user.

   DMARC authenticates use of the RFC5322.From domain by requiring that
   it match (be aligned with) an Authenticated Identifier.
   
   -- https://tools.ietf.org/html/rfc7489#section-3.1

It simply means:

   when a sender authenticates their email using SPF and/or DKIM,  
   at least one of the domains must align with the sending From domain

This approach is widely accepted and generally considered
a good practice to identify trusted sender domains.

• For SPF authentication
  the root domain of the Mail From address must match the root domain of the From address.
  Relaxed alignment allows any subdomain to be used and still meet the domain alignment requirement.

• For DKIM authentication
  the root of the dkim signing domain must match the From domain.
  Relaxed alignment allows any subdomain to be used and still meet the domain alignment requirement.

1. both the rules are respected
   the sender domain is fully trusted,
   the message arrives unchanged

2. only one of the two rules is met
   the ~ (tilde) symbol is added to the subject,
   one of the following explanatory notes is inserted in the message header

~ ... subject ...
X-RealSender: ~ | spf=pass (domain NOT aligned) | dkim=pass | ~

~ ... subject ...
X-RealSender: ~ | spf=pass | dkim=pass (domain NOT aligned) | ~

1. no alignment at all
   the “:: spf-diff ::” and “:: dkim-diff ::” warnings
   are displayed in the subject

4 - double spam tags

DMARC is being used by more and more companies to protect their senders from spoofing.
Its use requires proper authentication with SPF or DKIM and alignment of From / Mail-From domains.

For more information:
<dmarc> act on fraudulent email

Messages from senders with the _dmarc record,
if they are NOT authenticated, they are highlighted with two [ SPAM ] tags in the subject:

[ SPAM ] ... message subject ... [ SPAM ]

Messages without the _dmarc record, when both SPF and DKIM authentication fail,
are reported with a [suspicious] tag in the subject:

[suspicious] ... message subject ... 

spam filter client side

RealSender’s “spamstop” app is an efficient anti-spam solution when combined with a filter
that splits messages according to senders that are NOT in your address book.

Most email clients offer this feature.
Below is a screenshot of the “Message filter” tool in Thunderbird.