Security
Disclaimer
The following security implementations are documented for informative and educational purposes only and I am not advising that you enable these features, as not all of them are ideal in all circumstances and scenarios. Please research which security features can and should be used for your domain before doing implementing them. I am not liable for any issues that may occur to your domain if you choose to follow these steps. Follow these steps at your own risk.
Introduction
This page covers the security implementations that apply to the domain "RyderCragie.com". The following security implementations ensure that my visitors have a safe and secure experience when connecting to my website, and they also ensure that emails sent from my domain are actually coming from me and that they are transported safely and securely when being delivered to external email servers.
General Domain/Website Security
Cloudflare
I use Cloudflare and the majority of the security features they offer. They're one of the world's largest networks for website security and prevention against attacks. Nothing more needs to be said.
DNSSEC
DNSSEC is short for Domain Name System Security Extensions.
DNSSEC provides cryptographic assurance of the authenticity and integrity of responses; it's intended as a defence against network attackers who are able to manipulate DNS to redirect their victims to servers of their choice. Without DNSSEC, a man-in-the-middle attack could send you to a totally different website but still show the genuine domain in your browser's address bar. I believe DNSSEC is crucial, especially for anything that shows a login page like forum.RyderCragie.com. Without it, the login page could be spoofed, while looking genuine, and if you filled it out you'd probably be sending off your details to a hacker in another country.
DNSSEC is hosted in a public DNS record.
CAA
CAA is short for Certification Authority Authorization.
CAA is a standard that allows me to restrict my domain name to certain Certificate Authorities (e.g. DigiCert or Let's Encrypt) and only the specified Certificate Authorities are allowed to issue certificates for my domain. This can help to reduce the chance of misissuance, either accidentally or maliciously.
CAA is used on my domain due to a combination of manually added CAA records and the Real AMP URL feature that Cloudflare offer.
CAA is hosted in a public DNS record.
HTTPS
HTTPS is a protocol used to connect to most websites nowadays. It ensures that traffic to a web server from your network is safe, secure and encrypted.
HSTS
HSTS is short for HTTP Strict Transport Security.
There is a file that all Chromium-based browsers, and Safari, look at which contains a huge list of every domain that is HSTS preloaded. This means that all of my domains and subdomains can only be accessed via the HTTPS protocol. This is completely different from an HTTP to HTTPS redirect as it is hardcoded into your browser.
My logic is that if you can’t serve a webpage over a secure HTTPS connection, you shouldn’t be serving it at all.
The links to the file and submission form are below for those who are interested. You’ll see my domain in this list if you click "Show raw contents", press CTRL + F, then type "RyderCragie" or any of my other domains.
Email Security
Below you will find features such as SPF, DKIM, DMARC, TLS and MTA-STS which all complement the security of outgoing and incoming emails.
SPF
What Is SPF?
SPF is short for Sender Policy Framework.
Having an SPF record in place is another way to prevent email spoofing. The primary differences are that it does not support any kind of monitoring or reports as DMARC does, and SPF also allows you to specify the IP addresses of email servers that are approved to send emails from my domain (in my case, the IP addresses Zoho Mail's email servers).
DNS Record
My SPF policy is publicly available to view via any TXT lookup tool and is located on the root of my "RyderCragie.com" domain:
v=spf1 include:_spfcf1.rydercragie.com include:spf.zoho.eu include:eu.transmail.net -all
SPF Record Analysis
Below is my SPF record separated into sections (officially known as "Prefixes", "Types" and "Values"), so I can explain what each part of the record means.
v=spf1
This part of my SPF record determines the purpose of the record, which is that it is an SPF record, followed by the version number of SPF, which Version 1 is currently the latest and only supported version of SPF.
include:_spfcf1.RyderCragie.com include:zoho.eu include:eu.transmail.net
Other SPF records and email servers specified just after the "+" Prefix (not present in this particular record) and the "Include" Type will be classified as email servers that are approved to send emails from my domain.
By analysing this part of my SPF record, you can see that it references another DNS record (spfcf1.RyderCragie.com). The contents of that record are publicly available to view via any TXT lookup tool:
v=spf1 ip4:185.20.209.0/24 ip4:31.186.226.0/24 ip4:31.186.243.0/24 ip4:89.36.170.0/24 ip4:185.20.211.0/24 ip4:185.172.199.0/24 ip4:91.135.68.104/29 ip4:185.230.214.0/23 ip4:136.143.168.0/22 -all
-all
Fail: All emails will be rejected if they do not match any of the Zoho Mail server IP addresses listed above.
-all
Fail: All emails will be rejected if they do not match any of the Zoho Mail server IP addresses listed above.
~all (Soft Fail) is also an SPF policy type. Emails will be accepted but might be marked as spam or insecure.
+all (Pass) is also an SPF policy type. This policy means all emails will be accepted.
DKIM
What Is DKIM?
DKIM is short for DomainKeys Identified Mail.
Having a DKIM record in place means my emails are cryptographically signed, which is essentially yet another way to help prevent email spoofing.
DNS Record
My DKIM DNS record is publically available to view via any TXT lookup tool and is located on the "ZMail._domainkey.RyderCragie.com" sub-subdomain:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuYV+gbp5ptlG3CwbK2zpw5Dm710tsCbTwu3YRQg99IbRv7KNYxS9IRCSH/oH7eqfgz6Urt65yP2k9Gl0PgM4o/QunyeVlKk3osneZzTy3pZQqqJdUXN0tqvEbrdF4Q60lqMYkyugCMtRUSJ1rmw+LyjQHyvjJ6yFdHIZelrMUKSN0AhO8VTS6xz0m4BAgzu4BVk7l2nlt0/gVYF50/nNqFDC+t5FBAun/BIdK4lwvZfX7HiR1jNRaCBuJLl5TcVb7ggPr8rxJm41rqM3nJDRFQ7Pbtwj/LO7vBmKNxPQFkJGu1jswXdYTaDDo3ktgf+pYc4C3OJB+z9/QT1G3J+vuwIDAQAB
DKIM Record Analysis
Below is my DKIM record separated into sections (officially known as "Tags" and "TagValues"), so I can explain what each part of the record means.
v=DKIM1
This part of my DKIM record determines the purpose of the record, which is that it is a DKIM record, followed by the version number of DKIM, which Version 1 is currently the latest and only supported version of DKIM.
k=rsa
This part of my DKIM record specifies the length of the cryptographic key using "bits" as the measurement. In this case, it is RSA (2048 bits).
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuYV+gbp5ptlG3CwbK2zpw5Dm710tsCbTwu3YRQg99IbRv7KNYxS9IRCSH/oH7eqfgz6Urt65yP2k9Gl0PgM4o/QunyeVlKk3osneZzTy3pZQqqJdUXN0tqvEbrdF4Q60lqMYkyugCMtRUSJ1rmw+LyjQHyvjJ6yFdHIZelrMUKSN0AhO8VTS6xz0m4BAgzu4BVk7l2nlt0/gVYF50/nNqFDC+t5FBAun/BIdK4lwvZfX7HiR1jNRaCBuJLl5TcVb7ggPr8rxJm41rqM3nJDRFQ7Pbtwj/LO7vBmKNxPQFkJGu1jswXdYTaDDo3ktgf+pYc4C3OJB+z9/QT1G3J+vuwIDAQAB
This part of my DKIM record is the 2048-bit cryptographic key itself.
DMARC
What Is DMARC?
DMARC is short for Domain-based Message Authentication, Reporting, and Conformance.
Having a DMARC policy in place ensures that fake emails pretending to come from RyderCragie.com will be junked or blocked altogether. This means that if you get an email from RyderCragie.com (meaning the "From" field and not the "Sender Name" field, as the "Sender Name" can be spoofed) it has definitely come from my domain and it is not coming from another domain.
DMARC also allows you to receive reports which include the mail servers that have been sending emails on behalf of my domain (e.g., emails that I send legitimately, or emails that someone else sends in an attempt to spoof my domain).
Types Of DMARC Reports
First, the different types of DMARC reporting need to be understood and explained.
Aggregate Reports (RUA)
RUA is short for Reporting URI(s) for Aggregate Data.
Aggregate reports have the following properties:
Combined data on a group of sent emails.
Not real-time. They are sent every day by default.
XML file format.
No personally identifiable information is included.
Supported by all DMARC-compliant mailbox providers.
Forensic Reports (RUF)
RUF is short for Reporting URI(s) For Failure Data.
Forensic reports have the following properties:
Details of an individually sent email.
Real-time. Sent almost immediately after any failures.
TXT file format.
Personally identifiable information is included.
Supported only by a handful of mailbox providers.
DNS Record
My DMARC policy is publically available to view via any TXT lookup tool and is located on the "_dmarc.RyderCragie.com" subdomain:
v=DMARC1; p=reject; rua=mailto:ac916a4e488c43058046889432174d68@dmarc-reports.cloudflare.net,mailto:DMARC+RUA@RyderCragie.com; ruf=mailto:DMARC+RUF@RyderCragie.com; fo=1; adkim=s; aspf=s
DMARC Record Analysis
Below is my DMARC record separated into sections (officially known as "Tags" and "TagValues"), so I can explain what each part of the record means.
v=DMARC1
This part of my DMARC record determines the purpose of the record, which is that it is a DMARC record, followed by the version number of DMARC, which Version 1 is currently the latest and only supported version of DMARC.
p=reject
This part of the record specifies the DMARC policy, which in turn advises receivers how to treat emails sent on behalf of RyderCragie.com, but fails to provide sufficient authentication (such as no SPF and DKIM alignment).
Below are all of the DMARC policies that can be used.
None: Monitoring only and emails are still accepted (the monitoring function will be explained in greater detail further down).
Quarantine: Emails are put in the Spam folder.
Reject: Emails are dropped and not delivered at all.
rua=mailto:ac916a4e488c43058046889432174d68@dmarc-reports.cloudflare.net,mailto:DMARC+RUA@RyderCragie.com
Email addresses specified just after the "rua" Tag will receive aggregate reports only (explained above).
By analysing this part of my DMARC record, you can see my aggregate reports are sent to the following email addresses:
Cloudflare DMARC Management: ac916a4e488c43058046889432174d68@dmarc-reports.cloudflare.net
My standard email inbox, powered by Zoho: DMARC+RUA@RyderCragie.com
Cloudflare DMARC Management will analyse the XML files provided by the RUA DMARC reports and show them to me in an easy-to-understand dashboard, so I can see the exact results of the reports.
ruf=mailto:DMARC+RUF@RyderCragie.com
Email addresses specified just after the "ruf" Tag will receive forensic reports only (explained above).
By analysing this part of my DMARC record, you can see my aggregate reports are sent to my standard email inbox, powered by Zoho: DMARC+RUF@RyderCragie.com
fo=1
DMARC reports will be generated if:
Anything fails.
adkim=s
The "s" part of this means the DKIM policy is "Strict". "r" for "Relaxed" is also an option.
aspf=s
The "s" part of this means the SPF policy is "Strict". "r" for "Relaxed" is also an option.
DMARC External Validation
What Is DMARC External Validation?
Since I also own other domains such as RyderCragie.co.uk and RyderCragie.uk, I like DMARC reports regarding those domains to be sent to an email address on RyderCragie.com. To allow this, I configured DMARC External Validation, which is a way to allow and control which domains can send my domain DMARC reports.
Why It May Be Necessary To Configure External DMARC Validation
If External DMARC Validation is not configured, you will only receive DMARC reports about the same domain (if configured), and other domains that attempt to send DMARC reports to your domain will bounce back to the sender to prevent them from being able to spam your mailbox, and send you unnecessary information. So if you have other domains and would like to receive DMARC reports for them, you must configure DMARC External Validation, as any email servers adhering to RFC will only accept DMARC reports from the domains you specify (excluding the same domain, hence "External").
How DMARC External Validation Works & How It Is Configured
If you perform a DMARC lookup on RyderCragie.co.uk, you will find that MXToolbox states "DMARC External Validation - All external domains in your DMARC record are giving permission to send them DMARC reports". This is because I added a TXT DNS record, following the below convention, to the RyderCragie.co.uk._report._dmarc.RyderCragie.com hostname with a value of v=DMARC1.
DMARC External Validation DNS Record Convention
SenderDomain.com._report._dmarc.ReceiverDomain.com
This means that RyderCragie.co.uk is permitted to send DMARC reports to the RyderCragie.com domain. Domains that do not have this configured will state "External Domains in your DMARC are not giving permission for your reports to be sent to them" in an MXToolbox lookup and those receiving domains will likely reject those reports from external senders.
This means that, from a security perspective, I am able to review and analyse DMARC reports for all of my domains due to them being approved.
Alternative DMARC External Validation Configuration Option
It is also possible to add a TXT DNS record on *._report._dmarc.ReceiverDomain.com with a value of v=DMARC1 which will permit all external senders the ability to send you DMARC reports. If you have firm spam filtering in place and have many domains sending you DMARC reports, this may be an ideal option.
TLS
What Is TLS?
TLS is short for Transport Layer Security.
Having TLS 1.2 or later in place means that emails will be guaranteed to remain private when moving between email providers (e.g., emails that I send). Encryption in Transit is a way of scrambling your email so that if it is intercepted while being transferred over an untrusted network, such as the internet, the person trying to read this will only see gobbledegook.
All 3 of Zoho Mail's email servers support TLS 1.2 with certificates issued by DigiCert, one of the biggest providers of SSL and TLS certificates.
No DNS record is required for TLS to work. I do however have a DNS record set up for TLS-RPT, but this is only for internal reports for me to analyse - this does not contribute anything to TLS and the way it works as its own individual factor so I will not be discussing it here. However, if you're interested, please feel free to email me and I'd be happy to explain it in greater detail for you.
MTA-STS
What Is MTA-STS?
MTA-STS is short for Mail Transfer Agent Strict Transport Security.
Emails crossing the internet use secure connections encrypted using Transport Layer Security (TLS). However, there remain vulnerabilities in this method of protecting the confidentiality of emails, whereby a person-in-the-middle can trick incoming connections to send to another server and/or send information in the clear. MTA-STS is a standard designed to address these vulnerabilities.
DNS Record
My MTA-STS DNS record is publicly available to view via any TXT lookup tool and is located on the "_mta-sts.RyderCragie.com" subdomain:
v=STSv1; id=19102023;
MTA-STS Record Analysis
Below is my MTA-STS record separated into sections (officially known as "Tags" and "TagValues"), so I can explain what each part of the record means.
v=STSv1
This part of my MTA-STS record determines the purpose of the record, which is that it is a MTA-STS record, followed by the version number of MTA-STS, which Version 1 is currently the latest and only supported version of MTA-STS.
id=19102023
A short, unique and made-up string ID that allows senders to quickly check if the recipient’s MTA-STS policy has changed. If the ID is the same the sender can apply the previously cached MTA-STS policy. In this case the ID is the date the record was last updated (19th October 2023).
Hosted File
Having MTA-STS in place also requires hosting a TXT file on the "mta-sts" subdomain of my domain at the path "/.well-known/mta-sts.txt". My MTA-STS hosted TXT is publicly available to view via any MTA-STS lookup tool and is located at https://mta-sts.RyderCragie.com/.well-known/mta-sts.txt.
version: STSv1
mode: enforce
mx: mx.zoho.eu
mx: mx2.zoho.eu
mx: mx3.zoho.eu
max_age: 604800
MTA-STS Hosted TXT File Analysis
Below is my MTA-STS hosted TXT file separated into sections (officially known as "Keys"), so I can explain what each part of the file means.
version: STSv1
This part of my MTA-STS hosted TXT file determines the purpose of the record, which is that it is an MTA-STS file, followed by the version number of MTA-STS, which Version 1 is currently the latest and only supported version of MTA-STS.
mode: enforce
There are 3 types of "modes" (policies) available for use with the MTA-STS system.
Enforce: In this mode, Sending MTAs must not deliver the message to hosts that fail MX matching or certificate validation or that do not support certain versions of TLS.
Testing: In this mode, MTA-STS will have no effect on your email and can only be used for TLS-RPT reporting (as mentioned above at the bottom of the "TLS" section of this page).
None: In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy.
mx: mx.zoho.eu
mx: mx2.zoho.eu
mx: mx3.zoho.eu
My email servers, one per line.
max_age: 604800
The "max_age" field in seconds is the maximum permissible time that a sending email service can cache the policy.
S/MIME
Not yet implemented. In progress.
DANE
Not yet implemented. In progress.
Conclusion
Should you have any questions or concerns regarding the security of my domain, webiste or email, or would just like further elaboration, please feel free to email me and I'd be happy to answer.