SPF, DKIM and DMARC are email authentication standards that help receiving mail servers verify that messages really come from your domain. If you send business email through a hosting platform, a control panel such as Plesk, or any third-party mail service, these records are essential for improving deliverability and reducing the chance of your messages being marked as spam or rejected.
They work together, but they do different jobs. SPF tells the recipient which servers are allowed to send email for your domain. DKIM adds a cryptographic signature to prove the message was not altered and was authorised by your domain. DMARC tells the receiving server how to handle messages that fail SPF or DKIM checks, and it also gives you reporting so you can monitor abuse and misconfiguration.
What SPF, DKIM and DMARC do
Email delivery is based on trust. Without authentication, a mailbox provider has little proof that a message claiming to be from your domain is legitimate. That makes spoofing easier and increases the risk of your mail being filtered, quarantined, or rejected.
SPF: who is allowed to send
SPF stands for Sender Policy Framework. It is a DNS record that lists the servers and services allowed to send mail for your domain. When a receiving mail server gets a message, it checks the sender IP address against your SPF record.
If the IP is listed, SPF passes. If not, SPF fails. This is useful for preventing unauthorised systems from sending mail on your behalf, but SPF alone does not protect the message content or the visible From address in all cases.
DKIM: proving the message was signed by your domain
DKIM stands for DomainKeys Identified Mail. It adds a digital signature to outgoing email using a private key on the sending server. The recipient uses the public key published in DNS to verify that the signature is valid.
DKIM helps confirm that the message really came from an approved system and that the content was not changed in transit. It is especially important when you send email through a hosting platform, transaction mail service, or applications such as contact forms, billing systems, and ticketing tools.
DMARC: policy and reporting
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on SPF and DKIM by checking whether the authenticated domain aligns with the visible sender domain in the From header.
DMARC lets you choose a policy:
- none – monitor only, no enforcement
- quarantine – suspicious messages may be sent to spam
- reject – unauthorised messages should be rejected
It also provides reporting, which helps you see who is sending mail for your domain and whether any mail streams are failing authentication.
Why these records matter for email deliverability
Mail providers such as Microsoft, Google, and many corporate spam filters use SPF, DKIM and DMARC as part of their trust signals. Even if your email content is legitimate, missing or incorrect authentication can reduce inbox placement.
Common delivery problems include:
- messages landing in spam or junk folders
- mail rejected with authentication-related errors
- spoofed messages appearing to come from your domain
- poor reputation for domains used by marketing, support, or transactional systems
- difficulty diagnosing why certain recipients do not receive messages
For hosting customers, this is often noticed after setting up mailbox accounts, moving to a new mail server, or using website applications that send mail through the server. In these cases, correct DNS setup is just as important as the mailbox configuration itself.
How SPF, DKIM and DMARC work together
These three standards are most effective when configured as a set.
- SPF checks whether the sending server is authorised.
- DKIM checks whether the message was signed by the domain and not altered.
- DMARC checks alignment and defines what to do if authentication fails.
A message can pass DMARC if either SPF or DKIM passes and aligns with the domain in the From address. This is important because some services send on behalf of your domain from shared infrastructure, while others sign mail with DKIM but may not match SPF perfectly.
In practice, the best approach is to configure all three. That gives you the strongest chance of inbox delivery and reduces the risk of spoofing.
Where to configure them in a hosting control panel
If you manage your domain through a hosting platform or control panel such as Plesk, the records are usually added in your DNS zone. Depending on your setup, some parts may be managed automatically by the mail server, while others need manual checks.
Typical DNS locations
- SPF is added as a TXT record at the root of the domain.
- DKIM is usually created as a TXT record for a selector such as
selector._domainkey. - DMARC is added as a TXT record at
_dmarc.
If your DNS is hosted elsewhere, you must update the records there, not only in the mail panel. This is a common issue when the domain uses external DNS management.
In Plesk or similar mail management tools
Many hosting panels can generate DKIM keys and suggest SPF settings automatically. This is helpful, but you should still review the result to ensure it matches your actual mail flow.
Check that:
- the mailbox server is listed in SPF if it sends mail directly
- third-party services such as CRM, invoicing, or newsletter tools are included if they send mail for the domain
- DKIM is enabled for the domain and signs outgoing mail
- DMARC is published with a policy appropriate for your current setup
How to create a correct SPF record
An SPF record should contain only the systems that are genuinely allowed to send email for your domain. Keeping it accurate is important because an overly broad record can create security risks, while an incomplete record can cause legitimate email to fail.
Basic SPF examples
A simple record for a server sending directly from its own IP might look like this:
v=spf1 ip4:203.0.113.10 -all
If you also use a third-party mail provider, you may need to include their SPF mechanism as well:
v=spf1 ip4:203.0.113.10 include:mailservice.example -all
The final -all means “fail any sender not listed”. Some domains use ~all as a softer policy during testing, but for a stable setup it is better to be precise and use a strict policy when you are confident the record is complete.
Important SPF rules
- Publish only one SPF record per domain.
- Keep the record within DNS lookup limits to avoid permerror.
- Include all legitimate sending sources: mail server, hosted platform, helpdesk, newsletter service, and application mail if needed.
- Update SPF whenever your sending services change.
SPF is often the first record to break after a migration. If you move to a new hosting platform or change your control panel mail configuration, review the SPF record immediately.
How DKIM signing works
DKIM uses a key pair. The private key remains on the outgoing mail server. The public key is published in DNS. When a message is sent, the server signs selected headers and the body. The recipient verifies the signature against the public key.
What DKIM protects
- the authenticity of the sender domain
- the integrity of the message headers and body
- proof that the mail passed through a server with the private key
DKIM is especially helpful when SPF is affected by forwarding, mailing lists, or relay systems. Because DKIM is tied to the message content rather than only the sending IP, it often survives intermediate handling better than SPF alone.
Example DKIM DNS structure
A DKIM record is usually published like this:
selector._domainkey.example.com
The value contains the public key and related parameters. The selector name may vary depending on your mail software or hosting control panel.
Practical DKIM tips
- Enable DKIM for every domain that sends mail.
- Make sure the selector in DNS matches the selector used by the mail server.
- Regenerate keys only when needed, because changing keys without updating DNS can break delivery.
- After migration, verify that outgoing mail is still signed.
How DMARC policy and alignment work
DMARC adds a layer of control on top of SPF and DKIM. It checks whether the domain used in authentication aligns with the domain visible to the recipient in the From header.
Alignment matters because some systems may pass SPF for an envelope sender that is different from the user-facing address. DMARC closes that gap by requiring a meaningful match.
Starting with monitoring
It is common to begin with a monitoring policy:
v=DMARC1; p=none; rua=mailto:[email protected]
This allows you to collect reports without rejecting messages. Once you confirm that all legitimate mail sources are authenticated correctly, you can move to stricter policies such as quarantine or reject.
Suggested DMARC rollout
- Publish SPF and DKIM first.
- Set DMARC to
p=noneand collect reports. - Review legitimate sending sources and fix any failures.
- Move to
p=quarantineif needed. - Move to
p=rejectwhen confident everything is aligned.
This staged approach is particularly useful for hosted business email environments where multiple systems may send on behalf of the same domain.
Common problems and how to fix them
Problem: SPF fails after a migration
This usually means the new mail server IP was not added to the SPF record, or the old server is still listed while the new one is missing. Review all systems that send mail, including the hosting platform, website, and any external applications.
Problem: DKIM is not passing
Check whether the DNS public key exists and whether the selector matches the one used by the sending server. Also confirm that the mail server is configured to sign outgoing messages and that DNS changes have fully propagated.
Problem: DMARC reports show legitimate mail failing
This is often caused by misalignment. The message may be sent through a service that passes SPF or DKIM for a different domain. Fix the sender settings so that the authenticated domain matches the visible From domain, or configure DKIM signing for your own domain.
Problem: too many DNS lookups in SPF
SPF has a lookup limit. If your record includes too many nested include statements or complex mechanisms, it may fail. Simplify the record by removing unused services and consolidating sending sources where possible.
Problem: forwarded mail fails SPF
This is a known limitation of SPF. Forwarding can change the sending path so the original source no longer matches the SPF record. DKIM and DMARC help here, because DKIM can remain valid if the message is not altered.
Best practices for business email deliverability
- Use a single consistent domain for your business mailbox accounts.
- Authenticate all sending systems, including forms, invoices, support tools, and CRM software.
- Keep SPF records short and accurate.
- Enable DKIM on every outbound mail stream.
- Roll out DMARC gradually and review reports regularly.
- After changing hosting, DNS, or control panel settings, test outgoing mail.
- Keep your mail server software and control panel updated.
- Use a monitored mailbox for DMARC report addresses so failures are not missed.
For hosting customers, a good rule is to review email authentication whenever you add a new mailbox, install a new website plugin that sends mail, or connect a third-party service to your domain.
How to test whether your records are correct
After publishing SPF, DKIM, and DMARC, send test messages to accounts at common mailbox providers and inspect the full headers. You can confirm whether authentication passed and whether DMARC aligned correctly.
Look for:
- spf=pass
- dkim=pass
- dmarc=pass
You can also use external email testing tools to check DNS syntax and identify configuration issues. If your hosting panel provides mail logs or message tracing, use those logs to confirm which server sent the message and whether DKIM signing was applied.
FAQ
Do I need all three records?
Yes, if you want the best deliverability and protection against spoofing. SPF, DKIM, and DMARC each solve a different problem, and using them together gives the most reliable result.
Is SPF enough on its own?
No. SPF can fail in forwarding scenarios and does not fully protect the visible sender identity. DKIM and DMARC complete the picture.
Can I use DMARC without DKIM?
Technically yes, but it is not recommended. DMARC works best when both SPF and DKIM are configured correctly. DKIM often helps preserve authentication through forwarding.
What happens if my SPF record is wrong?
Legitimate messages may be treated as suspicious, which can hurt inbox placement. In some cases, receiving servers may reject the message entirely.
How long does DNS take to update?
DNS changes can appear quickly, but full propagation depends on TTL values and caching at different resolvers. Always allow time before assuming a record is still not working.
Should I set DMARC to reject right away?
Usually not. Start with monitoring, fix any legitimate sending sources, then move to a stricter policy. This avoids accidentally blocking business email.
Where do I find the correct DKIM selector?
The selector is normally shown in your mail server or control panel settings. If you use a hosting platform, check the domain’s email authentication section or the outgoing mail configuration.
Conclusion
SPF, DKIM and DMARC are the foundation of modern email authentication. For any business using hosted mailboxes, a control panel, or application-generated email, they are essential for delivery, trust, and brand protection.
Start by identifying every system that sends mail for your domain, publish a precise SPF record, enable DKIM signing, and then add DMARC with reporting. Once your configuration is correct, you will have a much better chance of reaching the inbox and a far clearer view of any delivery issues that appear later.