Email authentication records help mailbox providers verify that messages really come from your domain and were not altered in transit. If you manage business email from a hosting control panel such as Plesk, cPanel, or a managed hosting platform, SPF, DKIM and DMARC are three DNS records you should understand before you send important mail. Together they improve deliverability, reduce spoofing, and make it easier for providers to trust your messages.
What SPF, DKIM and DMARC do
SPF, DKIM and DMARC are not email services themselves. They are DNS-based policies and signatures that help receiving servers decide whether an email is legitimate.
SPF: who is allowed to send mail for your domain
SPF stands for Sender Policy Framework. It is a DNS TXT record that lists the mail servers and services allowed to send email using your domain name in the envelope sender. When a receiving server gets a message, it checks whether the sending IP address is included in your SPF record.
SPF is useful when you send email from:
- your hosting server
- your website contact forms
- transactional email services
- third-party platforms such as CRM, ticketing, or newsletter tools
If the sender is not listed, SPF may fail. That does not always mean the email is spam, but it lowers trust and can affect delivery.
DKIM: a cryptographic signature for your messages
DKIM stands for DomainKeys Identified Mail. It adds a digital signature to outgoing emails. The receiving server uses the public key published in DNS to verify that the message was signed by an authorised system and was not changed after it left the sender.
Unlike SPF, DKIM can survive forwarding better because the signature is tied to the content and headers of the message, not only to the sending IP address.
DKIM helps confirm:
- the email was sent by a system approved for your domain
- the message content was not modified in transit
- your domain has a stronger reputation with mailbox providers
DMARC: the policy layer that combines SPF and DKIM
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It tells receiving servers how to handle emails that fail SPF or DKIM checks, and it requires alignment with the domain shown in the visible From address.
DMARC gives you three main functions:
- policy enforcement for failed authentication
- reports about who is sending mail for your domain
- protection against domain spoofing and phishing
In practical terms, DMARC helps you answer two questions: “Is this email really from us?” and “What should receivers do if it is not?”
How these records work together
SPF, DKIM and DMARC are most effective when used together.
- SPF checks whether the sending server is allowed.
- DKIM checks whether the message was signed by your domain and remained intact.
- DMARC checks whether SPF or DKIM passed in an aligned way and applies your policy.
This layered approach is important because modern mailbox providers look at multiple signals before placing mail into the inbox. A single DNS record rarely solves deliverability problems on its own.
For example, if your company sends invoices from a hosting server but also uses a marketing platform, you may need SPF entries for both systems and DKIM keys for each sending service. DMARC then ties everything together by making sure the visible sender domain matches the authenticated domain.
Why these records matter for hosting customers
For businesses using managed hosting or a control panel, email often comes from more than one source. A website form may send through the web server, while support emails come from the mailbox server, and newsletters are sent from a third-party provider. Without proper DNS records, one or more of these sources may fail authentication.
Common problems include:
- mail landing in spam folders
- messages rejected by strict providers
- spoofed emails using your domain
- inconsistent delivery across mailbox providers
- difficulty tracing legitimate vs unauthorized mail sources
In an EU hosting environment, this is especially relevant for business email, customer notifications, and account-related communication where trust and delivery consistency are essential.
Understanding SPF in more detail
An SPF record is published as a TXT record in DNS. It usually starts with v=spf1 and then lists allowed sources using mechanisms such as ip4, ip6, mx, or include.
Example conceptually:
- ip4 and ip6 authorize specific addresses
- mx authorizes the servers that receive mail for your domain
- include authorizes another provider’s SPF policy
- -all signals a hard fail for anything else
Important SPF rules:
- Only one SPF record should exist per domain.
- SPF has a DNS lookup limit, so too many includes can cause failure.
- SPF checks the envelope sender, not necessarily the visible From address.
- Forwarded email can fail SPF even if it is legitimate.
If your hosting control panel lets you edit DNS, you can usually add the SPF TXT record there. If your mail is hosted elsewhere, make sure the record includes that service too.
Common SPF example patterns
A typical SPF record for a single mail server may look like this in principle:
- v=spf1 a mx ip4:203.0.113.10 -all
A domain that uses an external email platform may include that provider’s published SPF mechanism as well:
- v=spf1 a mx include:provider.example -all
The exact value depends on your infrastructure. Never copy a record blindly without checking which services actually send mail for your domain.
Understanding DKIM in more detail
DKIM uses a private key on the sending system and a public key in DNS. When your server sends an email, it signs selected headers and the body with the private key. The recipient fetches the public key from DNS using the selector name, then verifies the signature.
A DKIM DNS record is typically published as a TXT record under a name like:
- selector._domainkey.example.com
The selector identifies which key is in use. This allows you to rotate keys later without breaking existing configuration.
DKIM is valuable because:
- it proves the message was authorised by the domain
- it supports message integrity
- it improves trust with providers that heavily score authenticated mail
In hosting panels, DKIM is often available as a switch you can enable for each domain. On some managed platforms, the key is generated automatically and the DNS record is suggested for you. If email is sent through a third-party service, you may need to publish the provider’s DKIM record instead.
What to check with DKIM
- the selector matches the DNS record
- the private key is installed on the sending system
- the domain in the signature matches the domain you control
- the record has been fully propagated in DNS
Because DKIM depends on both the mail server and DNS, it is a common source of configuration errors after migrations or DNS changes.
Understanding DMARC in more detail
DMARC is published as a TXT record at:
- _dmarc.example.com
A DMARC record defines how a receiving server should treat mail that fails authentication and alignment checks. The main policy values are:
- p=none — monitor only, do not block
- p=quarantine — place suspicious messages in spam or similar folders
- p=reject — reject failing messages outright
DMARC also supports reporting tags, which can send you aggregate and forensic reports from mailbox providers. These reports help identify unauthorized senders, broken configurations, and delivery issues.
Why alignment matters
DMARC does not only check whether SPF or DKIM passed. It also checks whether the authenticated domain aligns with the visible From domain. This matters because attackers can try to pass authentication using a different domain while still showing your brand in the From address.
Alignment helps ensure the email is not only technically authenticated, but authenticated for the same domain the recipient sees.
How to set up SPF, DKIM and DMARC in a hosting control panel
The exact steps vary by platform, but the process is usually similar in Plesk, cPanel, or other managed hosting control panels.
1. Identify all systems that send mail for your domain
Before changing DNS, list every source that sends email using your domain:
- mailboxes on your hosting account
- website scripts and contact forms
- CRM, helpdesk, invoicing, or booking tools
- newsletter and automation platforms
- external SMTP relays or transactional email services
This step is essential. Most SPF problems happen because an organization forgets one sender.
2. Publish or update the SPF record
In your DNS zone, create or edit the SPF TXT record so it includes all authorised senders. Keep the record concise and avoid unnecessary mechanisms.
Best practices:
- use a single SPF record per domain
- include only systems that actually send mail
- keep DNS lookup count within the allowed limit
- finish with an appropriate all mechanism, usually -all once you are sure the list is complete
If you are unsure whether a sender needs to be included, check its documentation or your hosting provider’s mail settings.
3. Enable DKIM signing
In the mail or domain settings of your control panel, enable DKIM for the domain. The system should generate a selector and private key, then provide a TXT record for DNS.
After publishing the record:
- wait for DNS propagation
- send a test email to confirm the signature is present
- verify that the receiving side shows DKIM as passing
If you migrated from another host, check whether the old DKIM selector is still used anywhere before removing it.
4. Add a DMARC record
Start with a monitoring policy if you are not sure all systems are correctly configured. A common staged approach is:
- begin with p=none
- review aggregate reports
- fix legitimate failures
- move to p=quarantine
- finally move to p=reject when ready
A basic DMARC record should also include a reporting address, such as rua, so you can receive aggregate reports.
Example structure:
- v=DMARC1; p=none; rua=mailto:[email protected]
Make sure the mailbox used for reports is monitored, because these messages can be frequent.
Recommended rollout strategy
If your domain has never used these records before, do not switch everything to a strict policy immediately. A safe rollout reduces the chance of blocking legitimate mail.
Phase 1: inventory and baseline
- identify all sending systems
- publish a complete SPF record
- enable DKIM on the main mail platform
- add DMARC with monitoring only
Phase 2: validate
- send test emails from each system
- check authentication results in the message headers
- confirm that DMARC reports show only expected sources
- fix alignment issues for services that send on your behalf
Phase 3: enforce
- change DMARC policy to quarantine or reject
- review reports after each change
- keep documentation of authorized senders for future updates
How to troubleshoot common issues
Email is still going to spam
Authentication is important, but it is not the only factor. Also review:
- sending reputation of your IP or domain
- content quality and formatting
- mail volume spikes
- missing reverse DNS or poor server reputation
- recipient engagement and bounce rates
Still, if SPF, DKIM or DMARC is failing, fix that first. It is often the foundation of broader delivery issues.
SPF passes for one service but fails for another
This usually means a sender was forgotten in the SPF record. Check whether a website, plugin, helpdesk, or external platform is sending mail on behalf of your domain.
DKIM shows as failing after migration
Possible causes include:
- wrong selector in DNS
- private key not installed on the new server
- DNS record not propagated yet
- mail relay is signing with a different domain
After a migration, it is common to need both DNS updates and mail service configuration changes.
DMARC fails even though SPF or DKIM passed
DMARC requires alignment. If the visible From domain is different from the authenticated domain, DMARC can still fail. This happens often with third-party services that send mail using their own infrastructure but your brand name in the From address.
Check whether the provider supports:
- custom DKIM signing for your domain
- custom return-path or bounce domain
- aligned SPF settings
Best practices for business email deliverability
- Use SPF, DKIM and DMARC together, not separately.
- Keep DNS records clean and document every sender.
- Rotate DKIM keys when your platform recommends it.
- Start DMARC in monitoring mode, then enforce gradually.
- Use a dedicated mailbox for DMARC reports.
- Review authentication after every DNS or hosting change.
- Make sure website forms use a trusted SMTP service instead of unauthenticated local mail, if possible.
- Test after migrations, especially when moving between hosting environments or changing control panels.
For hosted business mail, these practices reduce avoidable delivery issues and help maintain a stable sender reputation across European mailbox providers.
Example checklist before going live
- All legitimate senders are listed in SPF
- There is only one SPF record for the domain
- DKIM is enabled for each sending platform
- The DKIM selector exists in DNS and matches the signing system
- DMARC is published at the correct name
- DMARC reports are going to a monitored mailbox
- Test messages pass SPF, DKIM and DMARC
- Web forms and third-party tools are not using unauthorised senders
FAQ
Do I need all three records?
Yes, for best results. SPF and DKIM authenticate your mail in different ways, and DMARC uses both to apply policy and reporting. In practice, a modern business domain should use all three.
Can SPF alone stop spoofing?
No. SPF helps restrict which servers may send mail, but it does not fully protect the visible From address and can break with forwarding. DMARC is the stronger anti-spoofing layer because it adds alignment and policy.
Does DKIM protect the content of the email?
DKIM protects message integrity by detecting changes after signing. It does not encrypt the message content. If you need confidentiality, you need separate encryption solutions.
What happens if I have more than one mail provider?
You can support multiple providers, but you must list them correctly in SPF and configure DKIM for each one if needed. DMARC will then validate whether each provider is aligned to your domain.
How long do DNS changes take?
Propagation depends on TTL values and DNS caching. Some changes appear quickly, while others can take longer. It is good practice to wait and retest after making updates, especially during migration or troubleshooting.
Should I set DMARC to reject immediately?
Usually not. Start with monitoring so you can discover all legitimate senders. Once you are confident that only approved systems send mail for your domain, move to quarantine or reject.
Can my hosting provider configure these for me?
In many managed hosting setups, yes. Some providers enable DKIM by default and generate SPF guidance in the control panel. However, you still need to confirm that all services used by your business are covered correctly.
Conclusion
SPF, DKIM and DMARC are essential DNS records for any domain that sends business email. SPF authorizes senders, DKIM signs messages, and DMARC defines what receivers should do when authentication fails. Together they improve inbox placement, reduce spoofing, and make email delivery more predictable across hosting platforms and mailbox providers.
If you manage email through a control panel or hosted platform, review these records after every migration, DNS change, or new service integration. A properly configured authentication setup is one of the most effective ways to protect your domain and support reliable email delivery.