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.
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
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 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 sitting under a desk in another country with a mask on.
DNSSEC is hosted in a public DNS record.
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 hosted in a public DNS record.
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 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 View RAW Contents > CTRL + F > Type "RyderCragie.com" or any of my other domains.
Below you will find features such as DMARC, SPF, DKIM, TLS and MTA-STS which all complement the security of outgoing and incoming emails.
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).
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.
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=quarantine; rua=mailto:firstname.lastname@example.org,mailto:email@example.com,mailto:DMARC@RyderCragie.com; ruf=mailto:firstname.lastname@example.org,mailto:DMARC@RyderCragie.com; fo=0:1:d:s; pct=100; adkim=r; aspf=r
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.
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.
My DMARC policy advises receivers how to treat emails sent on behalf of RyderCragie.com, but fails to provide sufficient authentication (no SPF and DKIM alignment - I'll explain SPF and DKIM further down).
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.
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: email@example.com
My standard email inbox, powered by Zoho: DMARC@RyderCragie.com
Both Cloudflare DMARC Management and MXToolbox 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.
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 forensic reports are sent to the following email addresses:
My standard email inbox, powered by Zoho: DMARC@RyderCragie.com
MXToolbox will analyse the TXT files provided by the RUF DMARC reports and show them to me in an easy-to-understand dashboard, so I can see the exact results of the reports.
DMARC reports will be generated if:
The percentage of emails that DMARC applies to.
The "r" part of this means the DKIM policy is "Relaxed". "s" for "Strict" is also an option.
The "r" part of this means the SPF policy is "Relaxed". "s" for "Strict" is also an option.
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).
My SPF policy is publically 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:zoho.eu ~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.
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.
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 publically available to view via any TXT lookup tool:
v=spf1 ip4:22.214.171.124/24 ip4:126.96.36.199/24 ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11/24 ip4:18.104.22.168/24 ip4:22.214.171.124/29 ip4:126.96.36.199/23 ip4:188.8.131.52/22 -all
Fail: All emails will be rejected if they do not match any of the Zoho Mail server IP addresses listed above.
Soft Fail: Emails will be accepted but might be marked as spam or insecure.
+all is also an SPF policy type. This policy means all emails will be accepted.
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.
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=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUM6GuFzdOx0LZcx4Pp5qpOvjR6PRBaisS+U2zr26ci2UVUQ8R+P9D5I0NHhAQEuR1AkOzLyb5koXOUPDjV4lI7MGeBXxygyqFmlmV1YAzDmD9+14FD/vdNtiJPhaXCXdwV8Tw5E91/djDYB9NdqnEsnqIVv8PmMdhl6akA88EwIDAQAB
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.
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.
This part of my DKIM record specifies the length of the cryptographic key using "bits" as the measurement. In this case, it is RSA (1024 bits).
This part of my DKIM record is the 1024-bit cryptographic key itself.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
My email servers, one per line.
The "max_age" field in seconds is the maximum permissible time that a sending email service can cache the policy.
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.