This page explains how to set up your DNS to ensure that your incoming mail can reach you.
With most domain purchases, the registrar usually offers a DNS service in with the package. With this DNS you can usually control the IP which the domain converts to and also create multiple sub-domains (codecrafters.com is the domain name, www.codecrafters.com is a sub-domain, mail.codecrafters.com is another sub-domain). Each of these sub-domains can also usually have its own set of DNS information (A, MX, TXT records) which can be useful for load sharing and backup facilities.
This information is stored on the DNS for each domain or sub-domain. It is used to control and direct incoming mail to the correct mail server. To make sure mails for your domain are directed to your server, you must set the MX records to contain the host address of your mail server. If required, you can set more than one MX record and prioritize them accordingly. For example you could use:
mail.yourdomain.com - priority 5 (primary server)
mail2.yourdomain.com - priority 10 (secondary server)
mail.someotherdomain.com - priority 15 (ternary server)
The lowest priority value is used first and if this doesn't respond then the next lowest value is used. This continues until either one of the hosts has responded or all of them have failed. You can also have records with equal priority for load sharing. This system allows you to run backup servers or even share the load with multiple mail servers.
DKIM allows digital signatures to be added to emails. Receiving mail servers can verify this signature to assure that the email came from the domain owner and wasn't modified in transit. DKIM uses strong RSA public key encryption to sign and verify the signature. The sending mail server uses a secret private key known only to them and then publishes a matching public key that can be used to decrypt the signature during verification. This public key should be published to a TXT DNS record under a subdomain of the domain that's signing using a subdomain TXT record of '<selector>._domainkey.<domain>' (e.g. 'selector._domainkey.example.com'). The selector can be any arbitrary value decided by the domain owner to allow them to issue new keys in the future with a new selector while leaving old keys active for a period as required. An example DKIM TXT DNS record would be:
v=DKIM1; k=rsa; p=<base64-encoded-RSA-public-key>
In Ability Mail Server Outgoing Mail settings, under DKIM, you can add domains for DKIM signing and there are tools to generate private / public keys and check that you've added the DNS record for your domains correctly.
SPF records are used to control which IPs are authorized to send outbound emails from your domains. You should put these in a TXT record on the root of your domain (the part after the @ in your email address). An example SPF record that only allows your MX records to send email for your domain would be:
v=spf1 mx -all
Using '-all' leads to a fail for all other IPs than your MX records. You can also use '~all' for a soft fail if you don't want to be as strict.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) and is a reporting platform which ties together DKIM and SPF. Domain owners can create a DNS record to specify a policy for what action should be taken (reject, quarantine, none) if either or both DKIM and SPF fail and also to specify email addresses where individual and aggregate reports of these failures should be sent to. This helps fix any issues with DKIM and SPF DNS records and also be informed when others may be attempting to use your domain for SPAM to help reduce this. DMARC TXT DNS records should be published under a subdomain of '_dmarc.<domain>' (e.g. '_dmarc.example.com'). An example DMARC record would be:
v=DMARC1; p=quarantine; rua=dmarc@yourdomain.com; ruf=dmarc@yourdomain.com
This record tells DMARC enabled mail servers to quarantine any emails that fail DKIM and SPF, usually by moving them to a Junk E-mail folder or similar. The rua and ruf fields allow specifying an email address where failed DMARC results can be sent to. You can increase the suggested action from none to quarantine to reject as you feel more strongly about locking down DKIM and SPF failures when you are confident that email from your domains will not fail. Implementing mail servers can choose to ignore these policies and not all mail servers will support DMARC policies or reporting.
See Also: Preventing SPAM, Outgoing Mail.