If you like DNray Forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...

 

Confused in DNS zones

Started by friv10games, Sep 21, 2022, 02:47 AM

Previous topic - Next topic

friv10gamesTopic starter

For the first time, I have installed Zimbra and started working with mail servers. To start using it, I created a legend called "mydomain.com" in the local DNS server and registered MX, A, DKIM, and SPF in it. Mail was being sent within a network via Zimbra, but when sent externally, it was getting spammed.

Moving forward, I needed to enable external network access to receive emails. To do this, I registered "mydomain.com" with web hosting provider "hoster.com". I tried to register A, MX data to be sent to our external address, but got confused about how to implement the scheme. The name of the server inside the domain (in the lock. networks) was "mail.mydomain.com", and the server name in the host (ubuntu) file on the Zimbra server itself was "192.128.0.12 mail.mydomain.com mail".

To resolve this issue, I needed to include something in the dns records of the hosting provider "hoster.com" under the domain "mydomain.com". This would ensure that when a message is sent from, say, @gmail.com, it would reach "mydomain.com" through our external IP, before being processed by our internal dns server and finally reaching Zimbra in the lock. networks.

Finally, I was unsure where to include DKIM and SPF records- on our local dns server in the zone "mydomain.com" or on the external dns zone of the domain "mydomain.com" from the hosting provider. It's important to figure out the correct placement to ensure effectiveness and avoid confusion.
  •  


jessepeterson

To ensure incoming mail works properly, it's important to correctly configure the MX record for the mailbox domain. While the local network address is set to 192.128.0.12, the external IP address of the network should be registered for the domain with port 25 redirection to the internal network at 192.128.0.12.

Under this approach, when mail is sent from an external address, the mail server will connect to the external IP address in use on the local network. It's necessary to register all entries in the DNS domain settings of the hosting provider to enable incoming mail, although it's possible to organize DNS servers on your web servers, delegate the domain to them and edit records locally as well.

The author's task involved sending notifications about registration and payment of services, data from services for clients. Emails were sent from the website (no spam, only at the request of the user, about 10 thousand emails were sent in total per month). DKIM, DMARC, SPF, PTR were configured, but emails often ended up in spam. The author solved the problem by transferring the delivery to Amazon SES, which has better anti-spam systems that are more forgiving towards large service providers. Overall, this experience highlights the benefits of using large service providers for email delivery.
  •  

addy

The following commands were executed:

chain=dstnat action=dst-nat to-addresses=ip_of_zimbra.server protocol=tcp dst-port=22,25,110,143,465,587,993,995,3443,7071,7143,7993,9071,10000

These commands have a long-standing question that could be useful to others. Mail is sent back and forth, despite the absence of public certificates on the test server. Gmail received mail from the test Zimbra and vice versa.

This passage describes the actions taken to configure and test the Zimbra mail server's outgoing and incoming connections. It's interesting to note that even without public certificates, mail was still successfully sent and received. This could be useful information for anyone testing a new mail server or looking to troubleshoot issues with their existing one.
  •  

wzorkat

To ensure that emails sent from external sources (e.g., @gmail.com) can successfully reach your Zimbra server within your local network, you'll need to configure the DNS records on your web hosting provider's platform.

1. A Record: This record maps the domain name "mydomain.com" to your Zimbra server's public IP address. This ensures that when an external email is sent to "mydomain.com", it reaches your Zimbra server's public-facing IP address.

2. MX Record: This record specifies the mail exchange server(s) responsible for handling email delivery for your domain. You'll need to set the MX record to point to your Zimbra server's public-facing hostname (e.g., "mail.mydomain.com"). This ensures that incoming emails are routed to your Zimbra server.

3. CNAME Record: If your Zimbra server's internal hostname is different from the public-facing hostname (e.g., "mail.mydomain.com"), you'll need to create a CNAME record that maps the public-facing hostname to the internal hostname. This allows your Zimbra server to correctly process the incoming emails.

Now, regarding the placement of DKIM and SPF records:

1. DKIM (DomainKeys Identified Mail): DKIM records should be configured on your local DNS server, within the zone for "mydomain.com". This ensures that the DKIM signature is correctly applied to outgoing emails from your Zimbra server, which helps prevent your emails from being marked as spam by receiving servers.

2. SPF (Sender Policy Framework): Similar to the DKIM records, the SPF records should be configured on your local DNS server, within the zone for "mydomain.com". The SPF record specifies the authorized email senders for your domain, which helps receiving servers verify the authenticity of emails from your domain.

By configuring the DNS records correctly on both your local DNS server and your web hosting provider's platform, you can ensure that emails sent from external sources can reach your Zimbra server, and that your outgoing emails are properly authenticated with DKIM and SPF.

Additionally, you may want to consider setting up reverse DNS (rDNS) for your Zimbra server's public-facing IP address. This helps further validate the authenticity of your emails and can also improve deliverability.
  •  

sudhaacademy

If you're confused about DNS zones, they're essentially segments of the DNS namespace that control specific domains or subdomains. Each zone holds DNS records for that area, such as A, MX, or CNAME records. Understanding zones helps in managing domain settings and ensuring proper resolution of your website and email services.






  •  


If you like DNray forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...