What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For a basic self-hosted email setup, you need MX and A/AAAA records for incoming mail, plus SPF, DKIM, and DMARC records for outgoing-mail authentication. You also need a PTR (reverse DNS) record for each public sending IP, normally set by the provider that controls the IP address. These records help mail systems find and assess your server; they do not guarantee that messages will reach inboxes.
DNS records at a glance
| Record | Where it goes | What it does |
|---|---|---|
| MX | Your email domain, such as example.com |
Directs other mail servers to the hostname that receives mail for your domain. |
| A and/or AAAA | The mail hostname, such as mail.example.com |
Resolves that hostname to the server’s IPv4 address (A) and/or IPv6 address (AAAA). |
| PTR | Reverse DNS for each public sending IP | Maps the sending IP back to a hostname. The IP provider usually controls this record. |
| SPF TXT | The domain used by the SPF-authenticated mail identity | Lists the sources authorized to send using that identity. There must be one SPF record per owner name. |
| DKIM | A selector-specific name under the signing domain | Publishes the public key used by recipients to verify signatures added to outgoing messages. |
| DMARC TXT | _dmarc.example.com |
Sets a policy preference for messages that fail aligned SPF and/or DKIM checks and can request reports. |
Use the exact names and values generated by your mail software and supplied by your hosting or relay provider. The examples below explain where records belong, not values to copy unchanged.
Records for receiving mail
MX: point the domain to your mail host
An MX record tells other mail servers which host should receive messages for your domain. Its target is a hostname, not an IP address. If you publish multiple MX records, lower preference numbers are tried first. Add multiple targets only if you operate or contract for distinct receiving hosts; multiple entries do not provide meaningful failover if they depend on the same unavailable server or network. RFC 5321 specifies SMTP’s MX lookup behavior.
SMTP has an implicit fallback to the domain itself when no MX records exist, but a deliberate setup should publish the intended MX record and make sure its target works.
#1 Best Overall
A and AAAA: make the MX target resolvable
Every MX target must resolve to at least one A or AAAA address record. Publish an A record for IPv4, an AAAA record for IPv6, or both if the server truly accepts SMTP traffic over those address families. Do not add an AAAA record just because the server has an IPv6 address: routing, firewall rules, SMTP service, and reverse DNS must also work over IPv6. A CNAME at the MX target is not a substitute for the required address records under the SMTP standard.
Records for sending authenticated mail
SPF: authorize the actual sending sources
SPF is published in a TXT record and lists sources permitted to send mail for the SPF-authenticated domain. Include only sources you actually use, such as your own mail server or an outbound relay, following the instructions for each. Consolidate the sources into one SPF record at each owner name: RFC 7208 says multiple SPF records for the same owner name are not permitted. If you change providers or add a relay, update the existing policy rather than publishing a second SPF record. RFC 7208 documents SPF; Google Cloud DNS also advises using TXT records beginning with v=spf1, not the deprecated SPF DNS record type (Google Cloud DNS record types).
Rank #2
DKIM: publish the key for your server’s signatures
DKIM lets your mail system sign outgoing messages with a domain identity; receiving systems can use the published public key to verify the signature. Enable signing in the mail software or relay, then publish its public key at the selector-specific DNS name it provides. There is no universal key or safe generic selector to copy: the signing domain, selector, and record format depend on the system. Keep the private key on the signing system and publish only the corresponding public key. Cloudflare’s email DNS guidance describes the roles of SPF, DKIM, and DMARC.
DMARC: set a policy for alignment failures
Publish a TXT record at _dmarc.<your-domain>. DMARC checks whether SPF and/or DKIM authentication aligns with the domain visible to the recipient as the message author, then communicates your preferred treatment for failures. It can also request aggregate reports. Choose a policy based on whether you have identified and authenticated all legitimate sending sources; a stricter policy applied before that work is complete can affect legitimate mail. The exact policy and reporting addresses are choices for the domain operator, not fixed DNS values. See RFC 7489.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11PTR: arrange reverse DNS with the IP provider
A PTR record maps a public IP address back to a hostname. The provider that controls the IP’s reverse-DNS zone usually has to create or change it, so editing your domain’s ordinary forward DNS zone may not be enough. Ask the server or IP-address provider to set the PTR for each public sending IP to your mail hostname, then ensure that hostname resolves forward to the corresponding address. Cloudflare’s DNS guidance and Google Cloud DNS documentation describe the distinction between forward records and reverse DNS.
If your host will not permit outbound SMTP traffic or will not give you usable reverse-DNS control, DNS edits alone cannot remove that limitation. Check provider rules before building the setup around direct sending.
Rank #4
Set up the records in a workable order
- Choose the mail hostname and provider. Confirm that the provider permits the inbound and outbound SMTP traffic you need and can configure reverse DNS for your public sending IP.
- Set forward and reverse addressing. Add A and/or AAAA records for the mail hostname using the server’s actual addresses. Request a matching PTR from the IP provider.
- Publish MX. Point the email domain’s MX record to the mail hostname, then confirm the target resolves to an A and/or AAAA record.
- Configure SPF. Identify every legitimate sending source and put them in one SPF TXT record at the relevant owner name.
- Enable DKIM signing. Generate or obtain the signing key and selector from the mail software or relay; publish the public key in the specified DNS record.
- Publish DMARC. Add the TXT record at
_dmarc.<your-domain>, select a policy suited to your readiness, and review alignment and any reports. - Test the whole path. Check DNS answers, SMTP connectivity, and authentication results on messages sent to accounts you control. A successful DNS lookup alone does not establish delivery or inbox placement.
Choose direct sending or an outbound relay
With direct sending, your server connects to recipient mail servers itself. That keeps the sending path under your control but makes provider permission, reverse DNS, and reputation management your responsibility. An SMTP relay sends on your behalf and can change which sources need to be authorized in SPF and which system signs with DKIM; follow that relay’s configuration instructions. It introduces dependence on another provider, so compare its policies and operational fit rather than assuming it will make every message legitimate or deliverable.
Optional records and features
- Additional MX hosts: useful for a real second receiving system, especially if it can accept or queue mail while the primary is unavailable. They are not a substitute for independent infrastructure.
- AAAA: publish only when SMTP works over IPv6 and the address has working routing, firewall configuration, and reverse DNS.
- Client auto-configuration, MTA-STS, TLS reporting, and DNSSEC: these can serve particular deployments, but they are not universal minimum records for basic SMTP routing and authentication. Their setup depends on the mail and DNS providers involved.
Why correct DNS does not guarantee inbox delivery
MX, SPF, DKIM, DMARC, and PTR help establish routing and identity, but standards do not promise inbox placement. Recipients also make filtering decisions, and delivery can be affected by the server’s IP history and reputation, hosting restrictions, and recipient-specific policies. A relay can provide an alternative sending path, but it does not remove the need to configure authentication accurately or comply with the providers involved. Microsoft’s sender guidance covers additional delivery considerations (Microsoft: email authentication).
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
