English
Magyar
By 2026, professional email delivery will no longer be a matter of luck, but a strict technical requirement where there is no room for even the slightest syntactic error. We know how frustrating it is when carefully drafted business proposals end up in the spam folder, or when the server bounces back sent emails with incomprehensible error messages. Setting up DKIM and SPF records may seem to many like a complicated, code-heavy process, but in the world of modern email systems, it is the cornerstone of digital trust and secure communication. Given the strict requirements of Google, Yahoo and Microsoft, it is now essential that your technical infrastructure also reflects your company’s professionalism.
This guide will show you exactly how to configure these DNS records correctly so that your emails reach their destination with a 100 per cent delivery rate. We’ll cover the use of 2048-bit DKIM keys and the 2026 security requirements for SPF records, so that your emails finally pass every authentication check. We’ll show you how precise configurations can create a stable and reliable corporate email system, whilst guiding you step by step to avoid the pitfalls arising from confusing DNS syntax.
What are SPF and DKIM records, and why is it mandatory to set them up?
The world of email authentication has changed fundamentally in recent years. Whilst security settings were previously regarded merely as optional fine-tuning, by 2026 the configuration of DKIM and SPF records will have become a basic requirement for successful delivery. SPF (Sender Policy Framework) is essentially a whitelist. This TXT record, stored in the DNS, specifies which servers are authorised to send emails on behalf of your domain. If an email arrives from an IP address not included in this list, the recipient’s system will immediately flag it as suspicious.
DomainKeys Identified Mail (DKIM) provides an additional layer of protection. This technology places a digital signature in the header of emails, verifying that the content of the message has remained unchanged from sending to receipt. The combined use of these two technologies builds up the domain’s reputation (Sender Reputation). Major service providers such as Google and Yahoo have already imposed strict requirements from February 2024, whilst Microsoft made these protocols mandatory in May 2025. If the records are missing, there is a good chance that the emails will never leave the spam folder, or that the servers will immediately reject them.
How do these records prevent abuse?
The primary aim of the authentication process is to prevent email spoofing and phishing. When an email arrives at the destination server, it queries the sender’s domain DNS records in a fraction of a second. The system compares the sender’s IP address against the SPF list and verifies the validity of the DKIM signature. This chain of defences ensures that unauthorised parties cannot misuse your brand name. Professional email hosting services now treat these security layers as standard, with the DMARC policy serving as the final verification mechanism.
Requirements of the 2026 email sending standards
The regulations are particularly strict when it comes to bulk senders. Anyone who sends more than 5,000 messages a day to Gmail or Yahoo addresses falls into the ‘bulk sender’ category and is required to have full SPF and DKIM authentication. Modern standards also require support for the ‘one-click unsubscribe’ feature, which only works reliably with authenticated domains. When configuring DKIM and SPF records, you can also decide on the outcome: ‘Soft fail’ (~all) indicates to the server that the email is suspicious but may be allowed through; ‘Hard fail’ (-all), on the other hand, is a clear instruction to reject it. By 2026, industry recommendations will clearly be moving towards a stricter, more secure approach.
The structure and correct syntax of an SPF record
An SPF record is a special text (TXT) entry in a domain name’s DNS zone that provides guidance to receiving servers regarding authorised senders. Every valid record begins with the version identifier v=spf1. This informs systems that the following string complies with the rules of the SPF protocol. The body of the record consists of various mechanisms that define the authorised sources. The ip4: and ip6: qualifiers allow specific server addresses to be specified, whilst the a and mx mechanisms refer to the domain’s existing A and MX records. When configuring DKIM and SPF records, we most commonly use the include: parameter, which allows us to incorporate external providers’ (such as newsletter senders or CRM systems) own SPF lists into our own.
The record’s closure determines what happens to emails that come from unverified sources. The ~all (soft fail) flag instructs the recipient to treat senders not on the list as suspicious, but not to reject them immediately. In contrast, the -all (hard fail) flag requires strict rejection of all unauthorised sources. In 2026, security trends are clearly moving towards the -all option, as this provides the strongest protection against abuse. It is a critical error to register multiple SPF records for a single domain. In such cases, receiving servers will regard the entire authentication as invalid. If you use multiple service providers, you must consolidate all include entries and IP addresses into a single, coherent TXT record.
Examples of SPF records in different environments
A record associated with a standard aWh hosting account is usually straightforward: v=spf1 a mx include:_spf.awh.hu ~all. However, if your business also uses Google Workspace or third-party marketing software, these must also be integrated: v=spf1 a mx include:_spf.awh.hu include:_spf.google.com include:servers.mcsv.net ~all. It is also important to be mindful of the ‘DNS Lookup Limit’. The SPF standard allows a maximum of 10 DNS lookups during authentication. If too many includes are used, the record becomes invalid. This is why it is essential to understand why both SPF and DKIM need to be configured, as DKIM is not subject to this query limit and provides a safety net even for more complex infrastructures.
Modifying the SPF record in the DNS zone
You can make these changes in the DNS editor within the domain management interface. When adding a new TXT record, you should generally enter the @ character in the ‘Host’ field and the syntax described above in the ‘Value’ field. Pay attention to the TTL (Time To Live) value; a setting of 3600 (one hour) strikes the ideal balance between fast updates and server load. After making changes, it is worth checking that the record is valid. For precise technical details and guides for various control panels, visit the aWh knowledge base, where you can follow the process step by step.
If you’re looking for a professional solution to ensure the security of your email, the automated tools included in modern web hosting plans will help you minimise errors and manage your records correctly.
DKIM record: Setting up the digital signature
Whilst SPF is a simple whitelist, DKIM (DomainKeys Identified Mail) is a far more advanced, cryptography-based solution for authenticating emails. The technology is based on an asymmetric key pair: the private key remains on the sending server, which the system uses to digitally sign every outgoing email. The public key, on the other hand, is placed amongst the domain’s DNS records. When the email arrives, the receiving server retrieves this public key and verifies that the digital signature is valid. Configuring DKIM and SPF records will be critical in 2026 because DKIM can verify that the content of the message has remained intact since it was sent and has not been tampered with by unauthorised parties whilst travelling over the internet.
One of the biggest advantages of DKIM over SPF is its stability. SPF records often fail when an email is forwarded, as the sender’s IP address changes in such cases. The DKIM signature, however, travels in the email header, so it remains valid even after forwarding. The format of the record is strictly defined in the DNS; it generally follows the syntax v=DKIM1; k=rsa; p=[hosszú_karakterlánc]. Security experts recommend that by 2026, only 2048-bit keys should be used, as the earlier 1024-bit versions no longer provide sufficient protection against modern computing capabilities.
Managing DKIM selectors
The selector allows you to assign multiple DKIM keys to a single domain. This is essential if you use several different systems for email. You can specify one selector for your company’s email (for example, default._domainkey) and another for your newsletter software (for example, mailchimp._domainkey). The selector is essentially a prefix in the DNS record that tells the receiving server exactly which public key to look for. To maintain security, it is also recommended that keys be rotated regularly; updating them every six months prevents a key that may have been leaked from being misused for a prolonged period.
Placing the public key amongst the DNS records
Entering the DKIM record into the DNS zone requires technical precision. 2048-bit public keys are extremely long strings, which sometimes exceed the character limit for a single TXT record. In such cases, the record must be split into several parts enclosed in quotation marks within the DNS editor. This process is one of the most important steps in configuring your domain after registration. If your server does not automatically generate the key pair, you can use online DKIM generators; however, the most secure solution is to click ‘Generate Key’ within the control panel of your professional email hosting service. When setting up DKIM and SPF records, always check the syntax using validation tools before applying the changes to avoid any temporary disruption to your email service.
Step-by-step guide to setting up DKIM and SPF records in cPanel
After the technical theory comes the practical implementation. Configuring DKIM and SPF records in aWh’s systems has become extremely straightforward thanks to cPanel’s integrated tools. First, log in to the cPanel interface via the aWh client portal. In the ‘Email’ section, locate the ‘Email Deliverability’ menu item. This application analyses the DNS records associated with your domains in real time and immediately alerts you if it detects any deviations from the optimal settings. Select the domain you wish to configure from the list, then click the ‘Manage’ button.
The system lists the current SPF and DKIM status in detail on the control panel. If the status is ‘Valid’, no further action is required. If you see an error message, cPanel will offer the option to fix it. By clicking the ‘Automatic Generation’ button, the server will generate a 2048-bit DKIM key and the appropriate SPF syntax. At the end of the process, you can also manually check the entries in the DNS zone using the ‘Zone Editor’. This double-check ensures that the records appear on the name servers exactly as required by the receiving service providers.
The benefits of the Email Deliverability tool at aWh
Automated error detection is a huge help to users. If the system displays a ‘Problems Exist’ message, you don’t need to manually code complex TXT records. With the one-click fix feature, cPanel carries out the installation automatically. This is one of the most important convenience features of cPanel hosting, which takes the technical burden off even novice users. The system continuously monitors the domain’s reputation, so you’ll be notified immediately if the chain of authentication is compromised due to a third-party modification.
Common cPanel configuration dilemmas
In many cases, web hosting and DNS management are handled separately. If, for example, you use Cloudflare or another external nameserver, cPanel cannot automatically update the records. In such cases, you will need to manually copy the values generated in the ‘Email Deliverability’ interface to your external DNS provider. Always ensure that you copy the entire string, including the DKIM selector prefix. When configuring DKIM and SPF records, even the slightest typo can lead to delivery errors, so after copying the values manually, always wait for the TTL to expire before testing.
If you want to avoid technical headaches, choose a professional cPanel hosting service where automated systems do the hard work for you.
Common mistakes and maintaining email security
When configuring DKIM and SPF records, even the slightest technical oversight can lead to serious delivery problems. Our experience shows that the most common obstacle is syntactic errors. A spare space at the start of a string, or the incorrect use of double quotation marks in the DNS zone, can invalidate the entire record. Many people forget that TXT records are sensitive to formatting, and invisible characters are often introduced into the code during copy-and-paste operations. Another critical error is the “Too many DNS lookups” issue. The SPF standard allows a maximum of 10 external lookups; if we try to cram too many service providers (such as newsletter senders, CRMs and support team software) into a single record using the ‘include’ mechanism, the authentication will simply fail.
It is important to be patient after making changes. DNS propagation – that is, the updating of records across global name servers – can take up to 24–48 hours. Although with modern systems this often takes just a few hours, it is advisable to wait until the TTL has expired before testing. Once the records are stable, the next step is to implement the DMARC record. This protocol provides the receiving server with final instructions on what to do if the SPF or DKIM check fails. We recommend starting with a more lenient policy for monitoring, then gradually tightening it to achieve maximum protection.
Free tools for checking records
- Mail-Tester: This is one of the simplest and most impressive tools. Based on a test email sent to a unique address, it rates the quality of the email on a scale of 1 to 10 and shows exactly where the authentication chain is failing.
- MXToolbox: The cornerstone of professional DNS diagnostics. It allows you to check the accuracy of your records in detail and see immediately if your domain has accidentally been blacklisted.
- Google Admin Toolbox: If you mainly send emails to Gmail users, this tool shows you how Google’s system views your settings and your domain’s reputation.
Why choose aWh for secure email?
At aWh, we realise that technical details can be daunting in day-to-day business operations. That’s why we provide pre-configured, valid records with every new hosting plan, ensuring that your DKIM and SPF records are already set up correctly from the moment you sign up. Should you nevertheless get stuck in the maze of DNS settings, our expert support team will be happy to assist you with manual fine-tuning. Our stable hardware infrastructure and automated security protocols ensure that your business emails do not end up in the spam folder. Choose from our range of professional email hosting solutions, which we have tailored specifically to the needs of Hungarian businesses.
Don’t risk your company’s digital reputation with unreliable settings and unreliable delivery. Switch to aWh’s reliable email service and forget about the spam folder!
Make your business correspondence professional and secure
By 2026, the security of digital communication will no longer be a matter of choice; authentication will be essential due to the strict regulations imposed by global service providers. The precise configuration of SPF and DKIM records is the cornerstone of business stability and market credibility. Careful attention to detail when setting up DKIM and SPF records directly contributes to high delivery rates, ensuring your messages bypass the spam folder and deliver real value to your customers. Don’t let technical details stand in the way of your business’s growth and effective communication.
With over 10 years’ professional experience and its exceptionally fast, NVMe-based email server infrastructure, aWh provides a stable foundation for your email communications. Thanks to our automated cPanel authentication tools, settings that may seem complicated are no longer an obstacle in your day-to-day work. Take the next step towards seamless and secure business communication today, and enjoy the benefits of modern technology. Start building your professional presence with a reliable partner.
Sign up for professional email hosting and set up your records in minutes!
Frequently asked questions about email authentication
How long does it take for the configured SPF and DKIM records to take effect?
DNS records usually take between 1 and 24 hours to update across global name servers. This process is known as DNS propagation, the duration of which depends on the TTL (Time To Live) value set for the record. If the TTL is set to 3,600 seconds, the change could theoretically take effect within an hour, but due to caching on remote servers, it is advisable to wait a full day before carrying out final testing.
Can I have more than one SPF record for a domain?
No, a domain may strictly have only one valid SPF record. If you specify multiple TXT records beginning with ‘v=spf1’, the receiving servers will consider the authentication invalid, and the emails are highly likely to end up in the spam folder. When configuring DKIM and SPF records, the ‘include’ parameters for all external service providers (such as Mailchimp or Google Workspace) must be combined into a single shared record in the DNS zone.
What is the difference between a ‘soft fail’ and a ‘hard fail’ in an SPF record?
A ‘soft fail’ (~all) indicates to the receiving server that a sender not on the list is suspicious, but the system may still allow the email through, subject to certain restrictions. A ‘hard fail’ (-all), by contrast, is a definitive instruction to reject the email if it comes from an unauthenticated source. By 2026, security trends will already be moving towards ‘hard fail’, but during the transition period it is advisable to start with the ‘soft fail’ setting in order to filter out technical errors.
How can I check whether I have configured the DKIM record correctly?
The quickest way to check the validity of your DKIM record is to use online diagnostic tools such as MXToolbox or Mail-Tester. These tools show whether the public key is visible during a DNS query and whether it matches the signature sent in the email header. Once you have configured the DKIM and SPF records, be sure to send a test email to these services to view the detailed authentication report.
Is a DMARC record also required if you already have SPF and DKIM?
Yes, the DMARC record is an essential component of modern email authentication, particularly for bulk email senders. Whilst SPF and DKIM verify the sender’s authenticity, DMARC specifies the procedure the recipient should follow if authentication fails for any reason. By 2026, the systems of major service providers will already require the presence of DMARC for reliable and secure delivery.
What happens if I use an external email client but authentication isn’t set up?
Without proper authentication, newsletters are almost guaranteed to end up in the spam folder, or the receiving servers will immediately reject them. In such cases, email clients often display a warning message next to the sender’s name, which significantly undermines business trust. All external sending systems must be registered in the domain’s DNS records to ensure successful campaigns.
Do SPF and DKIM settings work with free service providers (e.g. Gmail)?
Modifying SPF and DKIM records is only possible if you use your own domain name; this is not possible with free @gmail.com addresses. If you use a free service provider, you do not have access to the domain’s DNS zone, so you cannot carry out these technical settings. For business correspondence, it is therefore strongly recommended that you register your own domain and use a professional email hosting service.
What is a ‘selector’ in a DKIM record?
A selector is a unique identifier in the DNS that allows you to assign several different DKIM keys to a single domain. This is necessary if you are using multiple systems in parallel, such as your own server and an external email marketing software. The selector enables the receiving server to identify precisely which public key it needs to retrieve in order to verify the signature.