Correct email DNS records are essential for reliable delivery, stronger domain reputation, and fewer messages ending up in spam. If you run your email through a hosting platform or control panel such as Plesk, checking SPF, DKIM, and DMARC is one of the fastest ways to confirm that your domain is configured properly. These records tell receiving mail servers which systems are allowed to send email for your domain, how to verify message integrity, and what to do when authentication fails.
If your emails are not reaching inboxes, are being rejected, or are showing warnings in mail clients, the first thing to verify is whether your DNS records match your actual mail setup. This is especially important in a managed hosting environment where mailboxes, web hosting, and DNS can be handled in the same panel, but may still depend on correct values entered in the domain zone.
What to check in your email DNS records
For a domain used for business email, the main DNS records to review are:
- MX records – define where incoming mail for the domain should be delivered.
- SPF record – specifies which servers and services are allowed to send email on behalf of the domain.
- DKIM record – provides a public key that lets receiving servers verify the email signature.
- DMARC record – defines policy and reporting for messages that fail SPF or DKIM checks.
- Optional related records – such as A/AAAA and reverse DNS, depending on how your hosting platform sends mail.
These records work together. A domain can have a valid MX record but still experience poor delivery if SPF or DKIM is missing, incorrect, or duplicated. Likewise, a strong SPF record does not help if it includes the wrong sending hosts or exceeds DNS lookup limits.
How to confirm your MX records are correct
MX records tell the internet where mail for your domain should be delivered. If they point to the wrong server, inbound mail may be delayed or lost.
What to look for
- There should usually be one or more MX records for the domain.
- The priority values should match your mail provider’s recommended setup.
- The destination hostnames should resolve correctly in DNS.
- There should not be old MX records left behind from a previous provider.
In a hosting control panel, check the domain’s DNS zone and compare the MX targets with your email service documentation. If your email is hosted in Plesk or another managed platform, confirm that mail is enabled for the domain and that the MX records point to the correct mail server hostname.
Common MX problems
- MX points to an outdated host after a migration.
- Multiple MX records exist, but one is no longer valid.
- The hostname in the MX record does not have a matching A or AAAA record.
- DNS changes were made recently and have not fully propagated.
If you recently moved your mailbox to a new hosting platform in Europe, allow some time for DNS propagation. Even after the correct record is saved, remote systems may still use cached data for a while.
How to verify your SPF record
SPF helps receiving servers confirm whether a sending server is allowed to send mail for your domain. A correct SPF record improves trust and reduces spoofing risk.
What a correct SPF record should do
- Include all legitimate senders for your domain.
- Use only one SPF record per domain.
- End with an appropriate policy such as ~all or -all, depending on your setup.
- Stay within the DNS lookup limit.
A typical SPF record might include your mail server, your hosting provider, and any third-party services that send email for your domain, such as ticketing systems, CRM platforms, or newsletter tools. If you omit one of these, messages sent from that service may fail SPF checks.
How to check SPF step by step
- Open your DNS zone in the hosting control panel.
- Find the TXT record that begins with v=spf1.
- Confirm that there is only one SPF TXT record for the domain.
- Check whether all active sending services are included.
- Verify that the record uses valid syntax and no extra spaces or unsupported mechanisms.
- Make sure the final policy matches your intended level of enforcement.
Common SPF errors
- Multiple SPF records – only one SPF record is allowed; multiple records can cause a permanent error.
- Missing sender – a service you use to send email is not listed.
- Too many DNS lookups – SPF can fail when the record includes too many include, mx, a, or redirect mechanisms.
- Softfail vs fail mismatch – the policy is stricter than your actual setup supports.
If you use a managed hosting environment with multiple outbound systems, review the SPF record carefully after every change to mail services. A small update in one platform can break delivery if the record is not adjusted.
How to check DKIM for your domain
DKIM signs outgoing email with a private key and publishes a public key in DNS. Receiving servers use this DNS record to verify that the message was not altered and that it came from an authorised source.
What to verify in the DKIM record
- The DKIM selector matches the one used by your mail server or service.
- The public key exists in DNS as a TXT record.
- The record is published under the correct name, usually in the form selector._domainkey.yourdomain.
- The key has not been removed or replaced during migration.
In Plesk and similar control panels, DKIM is often enabled per domain. If you rotate keys or move email between servers, the selector value may change. Always confirm that the DNS record currently published matches the active signing configuration on the mail server.
How to check DKIM step by step
- Open the mail settings for the domain in your hosting platform.
- Find the DKIM selector and public key details.
- Check the DNS zone for the corresponding TXT record.
- Make sure the record name is correct and fully qualified.
- Send a test message and inspect the email headers to confirm DKIM passes.
Common DKIM issues
- The DKIM record exists, but the selector is wrong.
- The public key is incomplete because it was copied incorrectly.
- DKIM is enabled in the control panel, but DNS was never updated.
- An old key remains in DNS after a new key was generated.
If DKIM is missing or broken, messages may still be delivered, but they are more likely to be treated as suspicious by receiving mail systems. For business email, especially in EU markets where trust and deliverability matter for customer communication, DKIM should be active and passing.
How to validate your DMARC record
DMARC builds on SPF and DKIM. It tells recipient servers how to handle mail that fails authentication and where to send reports. Even a basic DMARC policy can improve visibility into sending problems.
What a valid DMARC record includes
- A TXT record published at _dmarc.yourdomain.
- A policy value such as p=none, p=quarantine, or p=reject.
- Optional reporting addresses, such as rua for aggregate reports.
- Correct syntax without extra characters or broken separators.
If you are just starting with DMARC, a monitoring policy is often a practical first step. It lets you see authentication results without immediately blocking mail. Once you are confident that all legitimate senders are covered by SPF and DKIM, you can move to stricter enforcement.
How to check DMARC step by step
- Look for a TXT record named _dmarc in your DNS zone.
- Check that the record begins with v=DMARC1.
- Verify that the policy matches your current deployment stage.
- Confirm that the reporting email address is valid if you use reports.
- Test a message and review whether DMARC passes in the received headers.
Common DMARC issues
- No DMARC record exists, so you have no central policy.
- The record is published under the wrong name.
- Reporting addresses are invalid or not monitored.
- DMARC is set too strictly before SPF and DKIM are fully aligned.
How to test email DNS records outside the control panel
Even if your DNS looks correct in the hosting interface, it is worth confirming what the public DNS actually returns. This helps identify propagation delays, caching issues, or records entered in the wrong zone.
Practical ways to test
- Use a DNS lookup tool to inspect MX, TXT, and CNAME records.
- Check SPF, DKIM, and DMARC records from an external validation service.
- Send a test email to a mailbox that shows authentication results in the message headers.
- Review bounce messages and delivery logs if your hosting platform provides them.
When testing, compare the public result with the value shown in your control panel. If they differ, the issue may be caused by a stale DNS zone, incorrect nameserver delegation, or recent changes that have not fully propagated.
What to inspect in email headers
After sending a test message, view the full headers and look for:
- SPF: pass
- DKIM: pass
- DMARC: pass
- The sending domain and alignment between visible From address and authenticated domains
If SPF passes but DMARC fails, the issue may be alignment rather than record syntax. This is common when the mail is sent from a subdomain or through a third-party platform that is not aligned with the visible sender domain.
Checklist for confirming your email DNS records
Use the checklist below to quickly review a domain in a hosting platform or Plesk environment:
- MX records point to the current mail service.
- Only one SPF record exists for the domain.
- SPF includes every legitimate sender.
- DKIM is enabled and the DNS key matches the active selector.
- DMARC exists and uses the intended policy.
- All records are published in the correct DNS zone.
- There are no old records from a previous provider.
- Test email headers show SPF, DKIM, and DMARC passing.
Typical problems after domain migration
DNS problems are especially common after moving email to a new hosting provider or changing control panels. A migration may leave behind old MX, SPF, or DKIM data, causing inconsistent authentication results.
Watch for these migration issues
- The old mail server is still listed in SPF.
- DKIM keys from the previous platform remain published.
- MX records still point to the former provider.
- DMARC reports are sent to an address no longer monitored.
- The new mail server is configured, but its hostname is missing from DNS.
After a migration, verify not only that inbound mail works, but also that outgoing mail is authenticated correctly. This is particularly important if your business uses both mailbox sending and application-generated email from the same domain.
When to contact support
You should contact your hosting support team if:
- The DNS records appear correct, but authentication still fails.
- The control panel does not allow you to edit the required record type.
- You are unsure which mail services should be listed in SPF.
- DKIM is enabled in the mail settings, but no DNS record is generated.
- You need help interpreting a DMARC report or email header.
When opening a support request, include the domain name, the relevant DNS records, a sample message header, and details about any recent mail or DNS changes. This helps the support team identify whether the issue is in the DNS zone, the mail server configuration, or an external sending service.
FAQ
How do I know if my SPF record is correct?
Your SPF record is likely correct if it exists as a single TXT record, includes every service that sends mail for your domain, and returns pass in message headers. If you receive SPF errors or delivery problems, check for missing senders, duplicate SPF records, or too many DNS lookups.
Why does DKIM pass in the control panel but fail in email tests?
This usually means the DNS record and mail server settings do not match, the selector is wrong, or the public key in DNS is not the same key used to sign the message. It can also happen if the message is altered by an intermediate system after signing.
Can I have more than one SPF record?
No. A domain should have only one SPF record. If you need to authorise multiple services, combine them into a single SPF policy.
What is the safest DMARC policy to start with?
Many administrators begin with p=none to monitor authentication results without blocking mail. After SPF and DKIM are confirmed, they may move to quarantine or reject.
How long do DNS changes take to work?
It depends on the TTL values and caching by resolvers. Some updates appear quickly, while others may take longer to propagate fully across the internet.
Do I need SPF, DKIM, and DMARC if I only send a few emails?
Yes. Even low-volume business email benefits from authentication. These records help improve trust, reduce spoofing, and make it more likely that your messages reach inboxes reliably.
Conclusion
Checking whether your email DNS records are correct is one of the most effective ways to improve deliverability and protect your domain reputation. Start with MX to ensure mail is routed properly, then confirm SPF, DKIM, and DMARC so your outgoing email is authenticated and trusted. In a hosting platform or control panel, these settings are often easy to overlook, especially after migrations or service changes, but a quick review can prevent long-term delivery problems.
If you manage email through a European hosting environment, keep your DNS records aligned with the current mail server setup, test headers after changes, and remove outdated entries as soon as they are no longer needed. A clean and accurate DNS configuration helps your email look legitimate to receiving servers and gives you better control over business communication.