Basic Web, Mail, and DNS Configuration

All services on the internet provide a variety of functionalities and features to enhance user experience. Due to ever-growing possibilities and new configuration options, I summarize general concepts and best practices on this page. The goal is to not only secure or extend existing systems, but also to give some hints to some not so well known functions and performance improvements. These configurations are not exhaustive and should be adapted to your specific needs and environment. It also does not only reflect public services, but also include recommended settings for internal domains and services in home and business networks.

I will not get into detail about every technology, but rather give an overview of key concepts and configurations with my personal recommendations. This should give you a solid foundation to build upon and customize according to your requirements.

I will use 2 of my own domains on this page for descriptions:

• bella.network - My main domain, authoritative for all services
• hync.io - A secondary domain, mostly referencing to the main domain

Web

DNS HTTPS & SVCB Records

These relatively new DNS records can help to speed up the connection establishment for HTTPS and HTTP/3 connections. By providing information about supported protocols and server hints, clients can optimize their connection setup process. Clients like Google Chrome, Microsoft Edge and Apple Safari resolve a domain name not only by A and AAAA records, but also check for HTTPS and SVCB records to get additional information about the server capabilities. If such a record is found and valid, the browser can skip some steps in the connection establishment process, connecting first using HTTPS leading to faster load times, improved performance and security.

An HTTPS record is similar to a SVCB record, but specifically for HTTPS services. It provides information about the supported protocols (like HTTP/2 and HTTP/3) and server hints (like IPv4 and IPv6 addresses).

1

bella.network. HTTPS 1 . alpn="h3,h2" ipv4hint="37.120.178.36" ipv6hint="2a03:4000:6:816c::1"

In addition to the DNS record, you should also configure the web server to support HTTP/2 and HTTP/3 protocols. This typically involves enabling the respective modules or settings in your web server software (like Apache, Nginx, etc.). To provide the client with the necessary information to use HTTP/3, you need to configure the server to support the ALPN (Application-Layer Protocol Negotiation) extension in TLS and provide an HTTP header indicating support for an alternative protocol. Note: A network change usually drops the record from the cache. Using the persist=1 tag, you can instruct the client to keep the record even after a network change.

1

Alt-Svc: h3=":443"; ma=2592000, h2=":443"; ma=2592000; persist=1

Note: Some DNS filtering solutions like Cisco Umbrella do not support these records yet and will block them. Users of these services will not benefit from the optimizations.

A new addition is ECH (Encrypted Client Hello) which is a privacy enhancement for TLS 1.3 that encrypts the ClientHello message, preventing eavesdroppers from seeing sensitive information like the Server Name Indication (SNI). To enable ECH, you need to add a DNS record that contains the necessary configuration for ECH.

1

bella.network. HTTPS 1 . alpn="h3,h2" ipv4hint="37.120.178.36" ipv6hint="2a03:4000:6:816c::1" ech="AEX+DQBB(...)Y29tAAA="

ECH isn’t widely supported yet, but major browsers like Google Chrome and Mozilla Firefox have started to implement it. To use ECH, both the client and server must support it. You also need to configure your web server to support ECH, which typically involves enabling the respective modules or settings in your web server software. As of now, a pull request to add ECH support to Nginx is still open: #840.

NEL (Network Error Logging)

Network Error Logging (NEL) is a mechanism that allows clients like browsers to report network errors encountered connecting to your webserver. By implementing NEL, you can gain insights into issues like failed resource loads, failed DNS resolution, connection problems, enabling you to detect and improve the reliability and performance of your web applications.

To configure NEL, you need to add a specific HTTP header to your server responses:

1

NEL: {"report_to":"default","max_age":604800,"include_subdomains":true,"failure_fraction":0.1}

This header tells the browser to report network errors to a specified endpoint (in this case, “default”) and sets the maximum age for the reporting configuration. Using the report_to field, you can specify a group of endpoints to receive the reports. This allows for more flexible reporting configurations, such as sending reports to different endpoints based on the type of error or the resource being requested.

1

Reporting-Endpoints: default="https://reports.bella.network/reports/receive"

This solution is especially useful for mission-critical applications where uptime and performance are paramount. By proactively monitoring network errors, you can address issues at the moment they occur.

HSTS

HSTS (HTTP Strict Transport Security) is a security feature that helps to protect websites from man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It does this by enforcing the use of HTTPS and preventing the use of HTTP.

To implement HSTS, you need to add the following HTTP header to your server responses:

1

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This header tells the browser to only connect to your site using HTTPS for the next 31536000 seconds (1 year) and to include all subdomains in this policy. The preload directive indicates that you want your site to be included in the HSTS preload list maintained by major browsers. After adding the header, you can submit your domain to the HSTS preload list to ensure that browsers will always use HTTPS when connecting to your site.

Usually after a few months, the preload list which includes your domain will be included in browser updates, so that users will benefit from HSTS even on their first visit to your site. This is especially important for new users who have never visited your site before, as they will not have the HSTS policy cached in their browser.

Keep in mind that once you enable HSTS, it can be difficult to revert back to HTTP. If you need to disable HSTS for any reason, you will need to wait until the max-age period has expired, your domain isn’t included in the preload list anymore and all browsers are updated which can take a long time.

CSP

CSP (Content Security Policy) is a security feature that helps to prevent cross-site scripting (XSS) attacks and other code injection attacks. It does this by allowing you to specify which sources of content are allowed to be loaded on your website. In a real-world scenario, you might use CSP to restrict the sources of scripts, styles, and other resources to only those that you trust. From my experience, CSP is not only one of the most effective ways to improve the security of your web applications, but also one of the most complex to implement correctly.

As a starting point, you can use the following CSP header:

1

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Additional HTTPS Headers

Referrer-Policy restricts the amount of information sent in the Referer header when navigating from your site to another site. This can help to protect user privacy and prevent information leakage.

1

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy restricts the use of certain browser features and APIs, such as geolocation, microphone, and camera. This can help to prevent unauthorized access to sensitive information and improve user privacy.

1

Permissions-Policy: geolocation=(), microphone=(), camera=()

X-Content-Type-Options prevents browsers from MIME-sniffing a response away from the declared content-type. This helps to reduce the risk of drive-by downloads and other types of attacks that rely on content-type misinterpretation.

1

X-Content-Type-Options: nosniff

Cross-Origin-Opener-Policy helps to isolate your website from other origins, preventing potential cross-origin attacks. This is especially important for sites that handle sensitive information or perform critical operations.

1

Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Resource-Policy helps to control how your resources can be shared with other origins. This is important for preventing unauthorized access to your resources and protecting user privacy.

1

Cross-Origin-Resource-Policy: same-origin

Precompression of Static Assets

Precompressing static assets like HTML, CSS, and JavaScript files can significantly improve the performance of your website by reducing the amount of data that needs to be transferred over the network. This is especially important for users with slow internet connections or limited bandwidth. By precompressing these files, you can reduce the time it takes for them to load including the reduction of CPU usage on the server side, resulting in a faster and more responsive user experience. The most common compression algorithms used for this purpose are Gzip and Brotli, since Chrome 115 also supports Zstd compression.

To implement precompression, you can use tools like gzip and brotli to compress your static assets before serving them to users. You can also configure your web server to automatically serve the precompressed files when a client supports the corresponding compression algorithm.

For this task I use GitLab CI to automatically compress and upload the static assets to my web server whenever I update my website. This ensures that the precompressed files are always up-to-date and available for users. Nginx is then configured to serve the precompressed files when a client supports the corresponding compression algorithm.

Note: Zstd compression is not yet widely supported by all browsers and servers. Nginx does only support Zstd compression using a third-party module, which needs to be compiled into Nginx. Make sure to test the compatibility of Zstd with your target audience before implementing it.

Here is an example Nginx configuration to serve precompressed files:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

http {
	...
	gzip on;
	gzip_static on;

	brotli on;
	brotli_static on;;

	zstd on;
	zstd_static on;
	...
}

The following Bash script can be used to precompress static assets using Gzip, Brotli, and Zstd:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/bin/sh

# List of given files which should be precompressed for faster serving with nginx
for singleFile in favicon.ico sitemap.xml style/*.css images/*.svg fonts/* script/*.js; do
	if [ -f "${singleFile}" ]; then
		cat "$singleFile" | gzip - > "${singleFile}.gz"
		touch -r "$singleFile" "${singleFile}.gz"
		cat "$singleFile" | brotli - > "${singleFile}.br"
		touch -r "$singleFile" "${singleFile}.br"
		cat "$singleFile" | zstd - > "${singleFile}.zst"
		touch -r "$singleFile" "${singleFile}.zst"
	fi
done

# Files in directories which should be precompressed
for singleFile in `find fontawesome/ -type f`; do
	if [ -f "${singleFile}" ]; then
		cat "$singleFile" | gzip - > "${singleFile}.gz"
		touch -r "$singleFile" "${singleFile}.gz"
		cat "$singleFile" | brotli - > "${singleFile}.br"
		touch -r "$singleFile" "${singleFile}.br"
		cat "$singleFile" | zstd - > "${singleFile}.zst"
		touch -r "$singleFile" "${singleFile}.zst"
	fi
done

Mail

Mail is one of the most common communication methods on the internet. However, it is also one of the most complex systems to set up and maintain. Below are some best practices and configurations to ensure a secure and efficient mail system, beginning with broad well-known settings and moving to more advanced options.

SPF, DKIM & DMARC

These three technologies work together to protect your domain from being used in email spoofing and phishing attacks.

• SPF (Sender Policy Framework): This DNS record helps to specify which mail servers are allowed to send email on behalf of your domain. It helps to prevent spammers from sending messages that appear to come from your domain.

• DKIM (DomainKeys Identified Mail): This technology adds a digital signature to your emails, which helps the receiving mail server verify that the email was indeed sent by your domain and has not been altered in transit.

• DMARC (Domain-based Message Authentication, Reporting & Conformance): This policy allows you to specify what should happen if an email fails SPF or DKIM checks. It also provides a way for you to receive reports about email authentication issues.

Microsoft announced on 2025-04-02 that they will enforce SPF, DKIM and DMARC on all high volume senders, improving security and trust in email communication. Source

As long as your server supports signing of outgoing emails with DKIM, there are no downsides to implement these three technologies. However, be aware that incorrect configurations can lead to legitimate emails being marked as spam or rejected.

As I manage multiple domains, I implemented a centralized system to manage records within SPF. For example the following configuration is used by domains managed by me:

1
2
3
4
5
6

# Main domain:
bella.network. TXT "v=spf1 include:_spf.bella.network -all"
_spf.bella.network. TXT "v=spf1 ip4:2.59.135.197 ip6:2a0d:5941:1:5db:0:feed:dead:beef include:spf.protection.outlook.com -all"

# Other domains:
hync.io. TXT "v=spf1 include:_spf.bella.network -all"

This allows me to configure SPF centrally for all domains from a single location (_spf.bella.network), making management easier and more efficient. I do not recommend to use SPF macros as some mail providers and filtering systems like Forcepoint do not respect RFC 7208 and will mark emails as spam where a private IP is used to signal a permitted sender. This results in legitimate emails being blocked or marked as spam.

For DMARC I use the following configuration, which rejects all emails that fail authentication and sends reports to a dedicated email address:

1

_dmarc.bella.network. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:mailreport@bella.network; ruf=mailto:mailreport@bella.network; rf=afrf; fo=1; pct=100; ri=86400"

Note that the email address needs additional authorization if a different domain is used. If you want to use one centralized email address for reports, you can set up an additional DNS record like this:

1

hync.io._report._dmarc.bella.network. TXT "v=DMARC1"

This allows hync.io to use an @bella.network email address for DMARC reports.

DKIM is typically generated and provided by your mail server software or email service provider. The public key is then added to your DNS records as a TXT record. The exact configuration will depend on the software or service you are using. The only thing to consider is to choose a key length of at least 2048 bits RSA for security reasons. Unfortunately, ed25519 keys are not widely supported yet.

BIMI

BIMI (Brand Indicators for Message Identification) is an email specification that allows organizations to display their brand logo next to their authenticated emails. This not only helps with brand recognition but also increases trust with recipients.

To implement BIMI, you need to create a DNS record that points to the location of your brand logo (in SVG format). The logo must be a square image and meet specific requirements outlined in the BIMI specification. Due to the extremely high cost of a Verified Mark Certificate (VMC), I use the default option without VMC. In this case, some providers will not show the logo as there isn’t a verification that you are the trademark owner of the used logo. But still, some providers will show the logo, so it’s worth implementing it.

1

default._bimi.bella.network. TXT "v=BIMI1;l=https://thomas.bella.network/images/appimage.svg"

Note: For BIMI to work, you must have a valid DMARC policy in place with a policy of quarantine or reject. Additionally you need to provide the logo in SVG Tiny P/S format, which is a subset of SVG with specific requirements.

In addition to the DNS record, you can use Gravatar to assign your (company) logo to your email address. This can help increase the chances of your logo being displayed in email clients. For example I registered my noreply@bella.network/noreply@hync.io email address at Gravatar to show my logo in supporting email clients.

MTA-STS & TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism that allows domain owners to declare their ability to receive secure (TLS) email. It helps to prevent man-in-the-middle attacks and ensures that emails are only delivered over secure connections. Servers supporting MTA-STS will check for the presence of a policy file on your web server and enforce TLS connections if the policy is found.

This is done by adding a DNS TXT record and hosting a policy file on your web server. Here is an example configuration:

1

_mta-sts.bella.network. TXT "v=STSv1;id=20190124143900;"

The path https://mta-sts.bella.network/.well-known/mta-sts.txt must contain the MTA-STS configuration as text file for the domain, for example in my case:

1
2
3
4
5

version: STSv1
mode: enforce
max_age: 604800
mx: mail.bella.network
mx: bmx.bella.network

TLS-RPT (TLS Reporting) is a mechanism that allows domain owners to receive reports about the status of TLS connections to their mail servers. This can help identify misconfigurations or issues with email delivery.

1

_smtp._tls.bella.network. TXT "v=TLSRPTv1; rua=mailto:mailreport@bella.network"

DANE

DANE (DNS-based Authentication of Named Entities) is a protocol that allows the use of DNSSEC to associate X.509 certificates with domain names. This can be used to enhance the security of email communications by ensuring that emails are only sent to servers that have a valid or specific TLS certificate. NOTE: DNSSEC must be properly configured and active for your domain for DANE to work.

I strongly prefer DANE-TA (Trust anchor assertion) as instead of pointing to a specific certificate, it allows you to point to a trust anchor like Let’s Encrypt. This means that all certificates issued by Let’s Encrypt are automatically trusted. This has the benefit that you do not need to exchange the certificate hash on every renewal, but the downside is that any certificate issued by Let’s Encrypt for your hostname is trusted. (It basically restricts your mail certificates to a specific Certificate Authority)

You should only use DANE as an addition when you already have implemented everything else mentioned above. Be sure what you do as DANE configuration is tricky and can lead to email delivery issues if not done correctly.

The following list contains the, as of 2025-09-07, recommended TLSA records for DANE-TA when Let’s Encrypt is used. You need to adapt these if you are using another Certificate Authority.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

_25._tcp.mail.bella.network. TLSA 2 1 1 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba ; R10
_25._tcp.mail.bella.network. TLSA 2 1 1 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 ; R11
_25._tcp.mail.bella.network. TLSA 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 ; R12
_25._tcp.mail.bella.network. TLSA 2 1 1 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d ; R13
_25._tcp.mail.bella.network. TLSA 2 1 1 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 ; R14
_25._tcp.mail.bella.network. TLSA 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 ; E5
_25._tcp.mail.bella.network. TLSA 2 1 1 d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 ; E6
_25._tcp.mail.bella.network. TLSA 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 ; E7
_25._tcp.mail.bella.network. TLSA 2 1 1 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 ; E8
_25._tcp.mail.bella.network. TLSA 2 1 1 f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2 ; E9

DNS based Service Discovery

SRV Records are a type of DNS record that is used to identify the location of servers for specific services. They are commonly used for services like SIP, XMPP, and email. By using SRV records, you can make it easier for clients to discover and connect to your mail servers without needing to know the exact hostname or IP address.

1
2
3
4
5
6

_imap._tcp.bella.network. SRV 0 1 143 mail.bella.network.
_imaps._tcp.bella.network. SRV 0 1 993 mail.bella.network.
_smtps._tcp.bella.network. SRV 0 1 465 mail.bella.network.
_submission._tcp.bella.network. SRV 0 1 587 mail.bella.network.
_sieve._tcp.bella.network. SRV 0 1 4190 mail.bella.network.
_autodiscover._tcp.bella.network. SRV 0 1 443 mail.bella.network.

DNSWL

A DNS-based whitelist (DNSWL) is a list of IP addresses or domains that are known to send legitimate email. By using a DNSWL, you can help ensure that emails from trusted sources are not mistakenly marked as spam. You can register your domain and IP address at DNSWL.org to improve email deliverability. It also provides you an overview of your domain’s reputation.

Besides DNSWL.org, there are other services like Google’s Postmaster Tools and Microsoft’s SNDS which provide insights into your email sending reputation and can help you identify and resolve deliverability issues.

Most mail providers use their own telemetry data to build internal whitelists and blacklists. Therefore, it’s important to maintain a good sending reputation by following best practices for email sending, such as using proper authentication methods (SPF, DKIM, DMARC), avoiding spammy content, and monitoring your sending patterns.

General Tips for Mail Servers

Always create a mailbox or alias for postmaster and abuse as required by RFC 2142. These mailboxes should be monitored regularly to ensure that any issues or complaints are addressed promptly.

DNS

DNS (Domain Name System) is a hierarchical system that translates human-readable domain names (like blog.bella.network) into IP addresses (like 37.120.178.36) that computers use to identify each other on the network. Proper DNS configuration is crucial for the functionality and security of your web services.

DDR

DDR (Discovery of Designated Resolvers) is a mechanism that allows clients to discover DNS resolvers that support specific features, such as DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). By implementing DDR, you can help ensure that clients can find and use secure DNS resolvers, improving privacy and security. To implement DDR, you need to add specific DNS records to primary nameserver of your local network. Here is an example configuration:

1
2
3
4
5

# DDR Records for DoH
_dns.resolver.arpa. SVCB 1 dns.bella.network. alpn="h3,h2" port=443 ipv4hint="10.20.30.40" dohpath="/dns-query"

# DDR Records for DoT
_dns.resolver.arpa. SVCB 2 dns.bella.network. alpn=dot port=853 ipv4hint="10.20.30.40"

These records indicate that the DNS resolver for your domain supports both DoH and DoT, along with the necessary connection details.

DNScontrol

I use DNScontrol to manage DNS records for multiple domains from a single configuration file. This tool allows me to define DNS records in a structured way and then push updates to various DNS providers. Using simple JavaScript like configurations, I can create reusable components and templates for common record sets, making it easier to manage multiple domains with similar configurations. In connection with GitLab CI, I can automatically deploy changes to my DNS providers whenever I update the configuration file in my Git repository. Additionally using Scheduled Pipelines, I can regularly check and enforce that the DNS records are always in the desired state - making all DNS records easily auditable and version controlled.

Here is an example, non-complete configuration for DNScontrol which demonstrates the concepts mentioned above:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

// CLOUDFLARE
var DNS_TB_CLOUDFLARE = NewDnsProvider('cloudflare_tb');
var REG_NONE = NewRegistrar('none');    // No registrar.

var ADDR_BRILL_IPV4 = '37.120.178.36';
var ADDR_BRILL_IPV6 = '2a03:4000:6:816c::1';

// Default records for TB MAIL
var DEFAULT_RECS_TB_MAIL_TTL_MISC = '30m';
var DEFAULT_RECS_TB_MAIL = [
	MX('@', 100, ADDR_MAIL_HOST + '.', TTL('1h')),
	MX('@', 500, ADDR_MAIL_HOST_ALT + '.', TTL('1h')),

	// SRV Records for clients, for Main MX
	//                       pr  w  port, target
	SRV('_imap._tcp',         0, 1, 143,  ADDR_MAIL_HOST + '.'),
	SRV('_imaps._tcp',        0, 1, 993,  ADDR_MAIL_HOST + '.'),
	SRV('_submission._tcp',   0, 1, 587,  ADDR_MAIL_HOST + '.'),
	SRV('_smtps._tcp',        0, 1, 465,  ADDR_MAIL_HOST + '.'),
	SRV('_sieve._tcp',        0, 1, 4190, ADDR_MAIL_HOST + '.'),
	SRV('_autodiscover._tcp', 0, 1, 443,  ADDR_MAIL_HOST + '.'),

	TXT('_dmarc', 'v=DMARC1; p=reject; sp=reject; rua=mailto:mailreport@bella.network; ruf=mailto:mailreport@bella.network; rf=afrf; fo=1; pct=100; ri=86400', TTL(DEFAULT_RECS_TB_MAIL_TTL_MISC)),
	// ^ see for more info: https://tools.ietf.org/html/rfc7489#page-17
	TXT('_smtp._tls', 'v=TLSRPTv1;rua=mailto:mailreport+mtasts@bella.network', TTL(DEFAULT_RECS_TB_MAIL_TTL_MISC)),

	//TXT('@', 'v=spf1 mx ~all', TTL(DEFAULT_RECS_TB_MAIL_TTL_MISC)),
	SPF_BUILDER({
		label: '@',
		overflow: '_spf%d', // Delete this line if you don't want big strings split.
		raw: '_rawspf', // Delete this line if the default is sufficient.
		ttl: DEFAULT_RECS_TB_MAIL_TTL_MISC,
		parts: [
			'v=spf1',
			'include:_spf.bella.network',
			'-all'
		]
	}),

	// _domainkey Record with "o=-" to prevent signing of subdomains
	TXT('_domainkey', 'o=-', TTL(DEFAULT_RECS_TB_MAIL_TTL_MISC)),

	// NOTE:
	// As of https://www.gov.uk/guidance/protect-domains-that-dont-send-email - 05.12.2020
	// SPF is also recommended for all subdomains of a domain for full protection
];

// Default records for PK CAA
var DEFAULT_RECS_TB_CAA_LE = CAA_BUILDER({
	iodef: CAA_IODEF,
	issue: [
		"letsencrypt.org",
	],
	issuewild: [
		"letsencrypt.org",
	],
});

D("bella.network", REG_NONE, DnsProvider(DNS_TB_CLOUDFLARE),
	DEFAULT_RECS_GLOBAL,
	DEFAULT_RECS_TB_CAA_LE,
	DEFAULT_RECS_TB_MAIL,

	A('@', ADDR_BRILL_IPV4),
	AAAA('@', ADDR_BRILL_IPV6),
	CNAME('www', '@')
);

D("hync.io", REG_NONE, DnsProvider(DNS_TB_CLOUDFLARE),
	DEFAULT_RECS_GLOBAL,
	DEFAULT_RECS_TB_CAA_LE,
	DEFAULT_RECS_TB_MAIL,

	A('@', ADDR_BRILL_IPV4),
	AAAA('@', ADDR_BRILL_IPV6),
	CNAME('www', '@')
);

D("bella.pm", REG_NONE, DnsProvider(DNS_TB_CLOUDFLARE),
	DEFAULT_RECS_GLOBAL,
	DEFAULT_RECS_TB_CAA_LE,
	DEFAULT_RECS_TB_MAIL,

	A('@', ADDR_BRILL_IPV4),
	AAAA('@', ADDR_BRILL_IPV6),
	CNAME('www', '@')
);

Conclusion

In this post, we’ve covered a range of configurations and best practices for web, mail, and DNS services. By implementing these recommendations, you can enhance the security, performance, and reliability of your online services. This list isn’t exhaustive, and you should always stay informed about new developments and best practices in these areas. Regularly review and update your configurations to ensure they remain effective and aligned with your specific needs and environment.

If you can recommend additional configurations, feel free to contact me so I can update and expand this post. Best practices and technologies are constantly evolving, and staying informed is key to maintaining a secure and efficient online presence.