English
Magyar
A stricter DMARC policy does not automatically mean greater security. If a legitimate sender is not configured correctly, their messages may end up in the recipients’ spam folders or be rejected altogether. Therefore, setting up a DMARC record begins with a check, and it is only worth tightening the settings based on the data collected. By following the correct sequence of steps, you can minimise the risk of incorrect email settings whilst protecting your domain from fraudulent messages sent in its name.
SPF checks which servers are authorised to send emails on behalf of your domain. DKIM uses a digital signature to help verify the origin of the message, whilst DMARC specifies what should happen if the checks do not match. Before creating the record, please review your domain’s DNS settings and all email services in use.
This guide explains how to set up SPF and DKIM, which TXT records to add to your DNS zone, and how to verify the results. You’ll learn about the role of reports, as well as when it’s advisable to switch from an observer policy to quarantine and then to rejection. This will enable you to implement DMARC more transparently and minimise the risk of legitimate emails failing to reach the recipient.
What is a DMARC record, and what issue does it address for an email domain?
A fraudster may list your domain as the sender, even though the message does not originate from your email system. DMARC helps recipient email systems verify such messages and follow the policy specified by the domain owner. The configuration is carried out via a TXT record published in the domain’s DNS zone.
The aim of DMARC is to provide guidance on how to handle unauthenticated emails based on SPF and DKIM checks, as well as the sender’s domain match. The protocol’s name is derived from the term ‘Domain-based Message Authentication’. The ‘What is DMARC?’ summary provides further background on how it works and its relationship with SPF and DKIM.
DMARC is not a guarantee of delivery and does not, on its own, provide complete protection against phishing. The protocol helps to identify instances where the sender’s domain does not match the authentication results. Based on this, the recipient’s service provider may apply the rule specified in the record, but other factors may also affect delivery.
How do SPF, DKIM and DMARC differ from one another?
The three technologies complement one another, but address different issues:
- SPF: checks whether the server sending the message is listed as an authorised sender in the domain’s SPF record.
- DKIM: uses a cryptographic signature to verify that the signed parts of the message match the sender’s domain’s public key.
- DMARC: evaluates the results of SPF and DKIM checks and verifies whether the domain of at least one successful check matches the sender’s domain as seen by the recipient.
A DMARC check can therefore be successful even if SPF or DKIM are valid and the domain being checked matches the sender’s domain.
When is it necessary to set up a DMARC record?
DMARC is useful for corporate email, confirmation emails from website forms and newsletter systems alike. Before setting up the DMARC record, identify which systems send emails on behalf of your domain. In addition to your own mail servers, make sure to include any external services.
If you have multiple sending sources, check the SPF and DKIM settings for each one. Even a legitimate system that has been omitted may be affected by a strict DMARC policy. The record must be managed in the DNS zone that is actually valid on the domain’s name servers. cPanel is only a suitable interface for this if the DNS zone for the domain in question can be managed there.
What are the prerequisites for setting up a DMARC record?
Successful DMARC implementation begins with an assessment of your sending systems and DNS settings. Before modifying your domain records, make a list of all services that send emails on behalf of your domain. An omitted sending source may later cause an authentication error and make it difficult to determine whether a failed verification is related to legitimate or spam email.
The inventory should include corporate email, notification emails from website forms, and any external newsletter or administration systems. Make a note of which service uses which sender address and where the authentication settings can be found. Email hosting settings are also linked to the domain’s DNS records, so please refer to the documentation for the email system you are using.
The official background to the protocol is set out in the official DMARC.org specification. When preparing to implement it in practice, the most important thing is to be familiar with the SPF and DKIM data associated with your own sending sources, and to know which DNS zone you need to edit.
How to check your SPF and DKIM settings?
Look up the SPF record provided by your email and mailing service provider in their documentation, as well as the records and values required for DKIM. Then compare these with the data already present in your DNS zone. Do not create a new SPF record or replace an existing one without first reviewing the history. Duplicate or conflicting entries may cause problems.
Please check separately that your website, business email and all external mailing platforms have been included in the inventory. If the settings for a particular service are unclear, please check the relevant provider’s guide or contact their customer support first. This reduces the likelihood of a legitimate sender being excluded from the verification process.
Where should the DMARC DNS record be created?
You must add the record to the authoritative DNS zone used by the name servers configured for the domain. The domain registration, web hosting and DNS management are not necessarily provided by the same service or via the same control panel. First, check where the domain’s records can actually be edited.
You should only look for the DNS settings on the cPanel hosting interface if the zone for that particular domain can actually be managed there. The mere presence of cPanel does not in itself mean that the authoritative DNS zone is located there. The exact control panel depends on your domain settings.
Which DMARC policy should you choose: ‘none’, ‘quarantine’ or ‘reject’?
The DMARC policy specifies what the domain owner should request from receiving mail systems if a message fails the DMARC check. During phased implementation, the policy is usually set to ‘observe’ initially; following a review of sender sources and authentication results, the policy can then be tightened. The explanation of the DMARC protocol provides further background on how it works.
| Terms and Conditions | What do you expect from the host system? | What can it be used for? |
|---|---|---|
| p=none | Do not apply any special handling to emails that fail the DMARC check. | For monitoring and assessing the sender’s sources. It does not, in itself, request that the suspicious email be quarantined or rejected. |
| p=quarantine | Treat any failed emails with suspicion; for example, move them to your junk folder. | Gradual validation, once the authenticity of legitimate senders has been verified. |
| p=reject | Reject emails that fail the DMARC check. | Stricter enforcement once the settings for legitimate sending sources have been sorted out. |
The policy instructs the recipient’s email system; it does not directly delete or move the email within your system. The recipient’s provider’s implementation may vary. ‘p=none’ can be a useful default setting, but do not regard it as a definitive security setting: it does not instruct the system to place fake or incorrectly authenticated emails in quarantine or to reject them. To receive and analyse reports, the appropriate reporting setting must also be enabled in the record.
When is it safe to switch to stricter house rules?
Don’t simply tighten security based on a schedule. First, review your DMARC reports and identify which systems are sending legitimate emails on behalf of your domain. If a known sender fails the verification, check the SPF and DKIM configuration, then correct the settings before switching to a stricter policy.
Only tighten your DMARC policy after checking the reports and sender sources. This will help reduce the risk of legitimate emails being quarantined or rejected. If it is not yet clear which service sent the message, or why the authentication failed, remain in the observation phase and clarify the details before making any changes. The DMARC record will only be effectively enforced once all legitimate senders have been properly authenticated.
Step-by-step guide to setting up a DMARC record in your DNS management panel
Once you are familiar with the systems that send emails from your domain and have checked their SPF and DKIM settings, you can proceed to add the TXT record. You must create this entry in your domain’s authorised DNS zone. The names of the fields in the control panel may vary depending on the provider, so before saving, please check that the record’s name and value are entered in the correct fields.
What information should the DMARC TXT record contain?
In the record, v=DMARC1 indicates the DMARC version, whilst p= specifies the policy that receiving systems must follow for emails that fail the check. To start with, you can use p=none, which requests observation only. The rua tag specifies the recipient address for DMARC aggregate reports. Choose a mailbox that you or the staff member responsible for the settings checks regularly.
The example below is for illustrative purposes only; it is not an actual record from aWh. Replace example.hu with your own domain name, and replace the reporting address with a valid email address.
v=DMARC1; p=none; rua=mailto:dmarc-riport@example.hu
How do you add a record?
- Open the authoritative DNS zone. Log in to the DNS management interface at the provider that manages the records for your domain’s name servers.
- Create a new TXT record. The record name or hostname is usually
_dmarc. Some control panels automatically append the domain name, whilst others require the full name. Follow the control panel’s instructions to ensure the domain is not entered twice. - Enter the record value. Paste in the selected DMARC data, such as the example above, which uses an observation policy. Only include the reporting address if it is actually capable of receiving emails.
- Save the change. Check the name, TXT type and full value, then save the record.
- Check the published post. Look up the
_dmarcname in the authorised DNS zone and check that the TXT record you created is readable.
The time it takes for DNS updates to take effect depends on your provider’s settings, so please do not assume there is an error if the record does not appear immediately on all verification platforms. When querying, check the syntax, semicolons and any duplicate DMARC entries. The display of quotation marks may vary from one interface to another. Do not add them manually if the control panel automatically formats the TXT value.
The visibility of the record does not yet confirm that all legitimate sender sources have been properly authenticated. Analyse the reports and the results of legitimate emails before switching to stricter policies. If your domain’s DNS zone can be managed via cPanel, familiarise yourself with cPanel hosting and check the DNS management options available for that account.
Troubleshooting and email protection: what should you do after setting it up?
After publishing the DMARC record, check that email authentication in practice matches the settings. If a legitimate message is quarantined or rejected, do not amend the policy straight away. Compare the record published in the DNS, the results of the DMARC reports and the guidance provided by the relevant email service provider.
Why might legitimate emails end up in quarantine or be rejected?
A DMARC check may fail even if the SPF or DKIM checks are successful on their own, but the domain used for the check does not match the domain shown in the sender’s address. This can occur with external newsletter services, website forms or automated notifications if the delivery path and authentication records are not synchronised.
Use the reports and provider data to identify the source of the failed checks. Then check the relevant SPF and DKIM records, the sender’s domain being used, and which system the message is actually being sent through.
- Missing sender: add the new or previously omitted mailing, form and notification system to the inventory, then check its authentication requirements.
- Syntax error: please check the record value, the separation of the tags and the record name specified in the DNS manager.
- Duplicate record: please check that there are no other DMARC TXT records named
_dmarc. A single valid record is required instead of duplicate entries.
After the fix, query the DNS settings again, then check the results for the affected senders in the reports. Only tighten the policy once the authentication and domain matching of legitimate sender sources have been clarified.
Advanced settings and special cases
In addition to v and p, the record may also contain further optional tags:
rua: the name of the summary reports. The reports are sent daily in XML format by major email systems; if you have high volumes of traffic, it is worth specifying the address of a report analysis service, as it is difficult to process them manually.sp: the policy regarding subdomains, if it differs from that of the main domain (for example,sp=rejectif you never send emails from that subdomain).adkimandaspf: matching strictness. With the default ‘loose’ (r) setting, an email signed from a subdomain also matches the main domain; with the ‘strict’ (s) setting, only an exactly matching domain is accepted. In most cases, ‘loose’ matching is the best choice.pct: applies the policy to only a subset of faulty emails (for example,p=quarantine; pct=25). Useful when introducing stricter policies gradually.
Domains that do not send emails. If a domain (for example, one that has been seized for brand protection or is parked) never sends emails, fraudsters may still misuse it. For such domains, set up an SPF record with v=spf1 -all and a DMARC record with v=DMARC1; p=reject;, so that emails sent in its name are rejected by recipients.
Requirements of major email providers. Since February 2024, Google and Yahoo, and since May 2025, have required senders of large volumes of email to implement SPF, DKIM and a DMARC record with a policy of at least p=none, and emails without authentication are increasingly being sent to the spam folder or rejected, even by smaller senders. Configuring DMARC therefore also improves the delivery of your own emails. Our phishing guide covers the broader context of protection against phishing.
BIMI. If the domain uses a p=quarantine or p=reject policy, the company’s logo may also appear alongside emails in certain email systems under the BIMI standard (in most cases, this requires a separate certificate issued for the logo).
DNS authentication and email hosting are separate tasks
DNS records determine how receiving systems can verify emails sent from your domain. Email hosting, on the other hand, provides the technical infrastructure for email accounts and message delivery. The two areas are related but not the same: the DMARC record must be managed within the domain’s authorised DNS zone, whilst you need to obtain the SPF and DKIM settings from your email service provider.
If you are choosing an email service or checking your existing settings, take a look at aWh’s email hosting solutions and coordinate the necessary authentication details with your domain’s DNS administrator.
Implement DMARC protection with these step-by-step instructions
Setting up a secure DMARC record does not end with the TXT record backup. First, identify all your email sending systems, then check the SPF and DKIM authentication. Next, monitor the DMARC reports, rectify any errors found with legitimate senders, and only switch to a stricter policy based on verified results. This will help you minimise the risk of the protection measures affecting your own, legitimately sent emails.
DNS authentication and email services are related, but they are separate tasks. The record must be published in the appropriate DNS zone and verified, whilst also taking into account the settings of the email service providers you use. When choosing a provider, it is worth looking for a solution that suits your email needs.
On aWh’s cPanel hosting plans, SPF and DKIM can be set up in just a few clicks under the ‘Email Deliverability’ menu, whilst the DMARC record can be added in the Zone Editor. Take a look at aWh’s email hosting solutions and check what settings are required for your domain. With careful preparation and ongoing monitoring, you can build more transparent email security step by step.
Frequently asked questions about the DMARC record
What is a DMARC record?
The DMARC record is an email authentication rule associated with a domain, which is published as a TXT record in the DNS. Receiving mail systems take into account the results of SPF and DKIM checks, as well as whether the authenticated domain matches the sender’s domain. The record also specifies how emails that fail the checks should be handled. It does not in itself guarantee delivery, and proper SPF and DKIM configurations are required for it to function correctly.
How do you set up a DMARC record?
Before setting up the DMARC record, make a list of all systems that send emails on behalf of your domain, then check the SPF and DKIM settings. Next, locate your domain’s authoritative DNS zone and add a TXT record with the name _dmarc. In the value field, enter the protocol version and your chosen policy. After saving, check the published record and monitor the reports.
Where should the DMARC TXT record be created?
You must create the record with the DNS provider that manages the domain’s authoritative DNS zone. This is not necessarily the same as your domain registration, web hosting or email account provider. First, check which name servers the domain uses, then locate the DNS zone in the corresponding control panel. There, create a TXT record for the name _dmarc.
What is the difference between p=none and p=reject?
The p=none setting is for monitoring purposes. It allows you to collect information about DMARC results, but this policy does not require failed emails to be quarantined or rejected. p=reject is a stricter rule: it instructs the receiving system to reject emails that fail the DMARC check. Before switching, ensure that all legitimate sending sources are known and properly authenticated.
Are SPF and DKIM records required to set up DMARC?
Yes, DMARC relies on the results of SPF and DKIM checks. First, take stock of your company’s email communications, website notifications and external email systems, then check the relevant settings. The mere existence of a record is not enough: the sending route and the authenticated domain must also match the sender’s domain correctly. Check the details in the guidelines provided by each email service provider.
Why isn’t the DMARC record appearing or working?
Common causes include an incorrect record name, a typo in the TXT value, an incorrect DNS zone or a DMARC record created more than once. Check that the expected TXT value for the _dmarc_ name is visible on the domain’s authorised name servers, and that there are no other DMARC records under the same name. The time it takes for DNS updates to take effect depends on your provider’s settings. In the reports, also check the SPF and DKIM results.
What do DMARC reports mean, and what should I do with them?
DMARC reports can provide aggregated data on which systems are sending emails on behalf of your domain and how they perform in authentication checks. First, identify the legitimate senders, then compare the results with your SPF and DKIM settings, as well as the data provided by your service providers. Correct any errors identified, and only then consider tightening your policy. The visibility of the record alone does not prove that all mailings are functioning correctly.