SPF, DMARC, DKIM, BIMI : Domain Security

\It’s no longer about security but about protecting yourself from risks, even the most vigorous protection is subject to scrutiny by a threat actor who is finding ways to cause problems, this means it’s more crucial to get the basics done correctly.

This was created to get you to "low" risk for your email compliance and security controls, as everyone at the minimum by now should have SPF, DMARC and DKIM - but this is about getting people to a low risk assessment as below:

The basics right now these include, but I’m not limited to:

SPF - Sender Policy Framework

This stands for sender policy framework and protects your domain from phishing attacks and other such impersonation as this record will advise the internet what is authorised to send as your domain, if you have no record then anyone can send as your domain which is not good, and a massive security issue.

The record for SPF will need to be hosted on the DNS server for your domain, this is also called a name server (NS) that record will need to be for your root domain and look something like this:

v=spf1 include:spf.forwardemail.net include:_spf.google.com ~all

This authorises mail from my domain to come from forwareemail.net and google.com, you will notice that the include: is a way of added nested IP addresses that if resolved will lookup the sending services actual records, below is a visual example:

You can also use other valid records with the syntax of ip4: and ip6: like for example this

v=spf1 ip4:104.248.224.170 ip4:72.14.192.0/18 ~all
v=spf1 ip6:2a03:b0c0:2:d0::dc4:9001 ip4:149.28.215.223 ~all

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

Note : To manage DMARC I personally use EasyDMARC for my reporting and forensics, check them out here

This stands for Domain-based Message Authentication, Reporting and Conformance and though that is a bit of a mouthful, it was created to block the threat of domain spoofing, which involves attackers using an organization’s domain to impersonate its employees, DMARC requires DKIM or SPF to be in place on an email domain and a DMARC record to be published in the DNS.

The records are broken up into section as below:

1. v=DMARC1: The DMARC version specified.
2. p=none/quarantine/reject: The domain owner’s DMARC policy, all three are shown here
3. rua=mailto:dmarc-report@pokebearswithsticks.com: The email address to which aggregate reports need to be sent. 
4. ruf=mailto:dmarc-forensics@pokebearswithsticks.com: The email address to which forensic reports need to be sent.
5. pct=100: The percentage of email that needs to be subjected to a DMARC policy’s specifications. In this case, 100% of email messages that fail a DMARC test will be rejected by the server.

This will then again be published as a TXT record, this time rather than being the root domain it will prefix the "_dmarc" host and then the data will be the record, this is my record:
    v=DMARC1;p=reject;sp=reject;pct=100;rua=mailto:5474d6ccb3@rua.easydmarc.us,mailto:5d2ac7025acb4874aebd312f9f5678f1@dmarc-reports.cloudflare.net;ruf=mailto:5474d6ccb3@ruf.easydmarc.us;ri=900;aspf=r;adkim=r;fo=0:1:d:s

I have additional parameters not required but optional and these are : 

1. sp=reject - this is the sub-domain policy if applicable and the policy required for those subdomains
2. ri=900 - asks receivers to send a aggregated report sender by no more than 900 seconds, in this case going to 5474d6ccb3@rua.easydmarc.us
3. aspf=r - SPF alignment mode is in relaxed not strict
4. adkim=r - DKIM aligment mode is in relaxed not strict
5. fo=0:1:d:s - this tells DKIM the forensic report mode type

NOTE : If you wish to officially pass DMARC you will need the policy "reject" and that reject will need to apply to 50% or more the messages

DKIM - DomainKeys Identified Mail

This stands for DomainKeys Identified Mail and it is an email authentication method that uses a digital signature to let the receiver of an email know that the message was sent and authorized by the owner of a domain.

This consists of a DNS record that contains the public key which receiving mail servers can use to authenticate the DKIM signature, this record which will live on the NS for your domain

This will then again be published as a TXT record, this time rather than being the root domain it will prefix the "default._domainkey." host and then the data will be the record, this is my record:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrHQpeQmYXIOz89YBnTS+TUdZA9r4nyrO2LO8ZhafMvZnDxwniTax24FenkyWOESgK2vEcSfnX0wXqL+ymeTgiF3dFG3GB1Np+zHMgyfxgjyJuWymQbMaysoiSy/8/MxnfDapjFoUYi2W4ZtKr2iN4REdW0gG1vqqkS5T6V6p6ywIDAQAB;

When sending messages from my mail server, this DKIM public key will be "added" so that you can confirm the messages have come from my mail server and not a impersonation/dodgy mail server, if DKIM fails than DMARC should see that and fail/reject the message.

BIMI - Brand Indicators for Message Identification

BIMI stands for Brand Indicators for Message Identification and this is responsible for the logo or brand image, however as I am an individual for this example, then the image in the green box below is my BIMI.

This is an image of myself that is again added to my DNS records on my public NS records:

This will then again be published as a TXT record, this time rather than being the root domain it will prefix the "default._bimi" host and then the data will be the record, this is my record:

v=BIMI1;l=https://bloguk.z13.web.core.windows.net/bimi/bimi-artic6.svg;a=

The ending of the record with the "a=" is where you can add a security signature in the form of a PEM file which would then secure your BIMI form a trusted supplier like Digicert, Entrust or Verisign - however that is not work the £250 per year for this example, but you do not require this for it to be valid.

If I then check my record against a validator this is what it returns, it is worth noting that the image needs to be be under 32KB in size and it needs to be on an assessable webserver:

Now lets move on to classifications from a "security posture point of view".

High Risk : No Records

You start off if you add zero records like this, here you can see you have no SPF, DMARC, DKIM or BIMI, this is bad, especially since 2nd February 2024 if you have no SPF or DMARC then you are not able to send to Google Mail or Yahoo - this is not a place you want to be at all.

High Risk : Single Invalid SPF record

This is still far from ideal, as you only have the basic record that really offers you little protection from anything malicious or phishing related, also notice here that the SPF record also not configured correctly due to the "amber" rating, you will not be allowed to send emails to Google or Yahoo with this setup anymore.

High Risk : Valid SPF but invalid DMARC

This shows that the SPF is valid, but the DMARC is not valid as its only in policy mode of None or Quarantine, it also should be 100% of emails else the protection is not really enabled in both of these policy modes.

Medium : Valid SPF and DMARC but no DKIM 

This is looking better we have a valid SPF and a valid DMARC (which means it is reject above 50% of messages) at this point you can now send emails to Google and Yahoo without them being blocked, but you still have no DKIM setup or valid which is a crucial setup to email hygiene and compliance.

Low Medium - Valid SPF, DMARC and DKIM

This is really where you need to be to good email hygiene and compliance, this will give you the best chance of protection from one of most dangerous entry points into a organisation, this only addition to confirm your brand is BIMI that would be nice to be added, but with these three enabled you really are in a good place from an email point of view.

Low - Valid SPF, DMARC, DKIM and BIMI

This report from generated from the a6n.co.uk domain, as I like to practice what I talk about :)

Excellent, this is fantastic news, you have done all your can to protect yourself for phishing and emails penetration, however these are only compliance controls for your email delivery which is in a good place.

While these controls are recommended and good practice to have in place, they are only security compliance and management controls, this means nothing if you have an open relay server setup, or you allow far to many "authorised" servers in the SPF record - also as many of these control require DNS you really need to ensure you have DNSSEC enabled - as this prevents poisoning and cache corruption from invalid records and dodgy DNS servers.