What SPF, DKIM, and DMARC Do

When your domain sends email, three authentication standards help receiving mail servers decide whether the message is legitimate: SPF, DKIM, and DMARC. In a hosting environment, these records are often set in the DNS zone of your domain and can strongly affect inbox placement, spam filtering, and whether your messages are accepted at all.

If you manage email for a business domain through a hosting control panel such as Plesk, understanding how these mechanisms work is essential. Misconfigured SPF, missing DKIM signatures, or a strict DMARC policy can cause email delivery problems, especially for transactional messages, contact form notifications, password resets, and shared hosting mailboxes.

In this article, you will learn what SPF, DKIM, and DMARC do, how they work together, how to check them, and what to do when your email is marked as spam or rejected by another mail server.

What SPF, DKIM, and DMARC are

SPF, DKIM, and DMARC are email authentication methods. Their purpose is to help receiving servers verify that an email really comes from the domain it claims to come from.

  • SPF tells receiving servers which mail servers are allowed to send email for your domain.
  • DKIM adds a digital signature to outgoing messages so the recipient can verify the message was not altered and was sent by an authorized server.
  • DMARC defines what receiving servers should do if SPF or DKIM checks fail and provides reporting about authentication results.

These standards do not guarantee inbox placement on their own, but they significantly improve trust and deliverability. They also reduce the risk that spammers can spoof your domain.

Why email authentication matters for hosting customers

For businesses using hosted email, authentication is one of the most common causes of delivery issues. A message may leave your mailbox successfully, but still be rejected, delayed, or moved to spam because the receiving server does not trust the sending domain.

This is especially relevant in hosting environments where:

  • the domain uses a third-party email service while DNS remains in the hosting control panel;
  • email is sent from the server’s local mail service, but SPF does not include the server IP;
  • WordPress, a contact form, or an application sends mail without DKIM signing;
  • multiple services send email from the same domain, but only some are authorized in DNS;
  • a strict DMARC policy rejects messages that do not align with SPF or DKIM.

In practical terms, authentication problems can affect:

  • outbound business email;
  • automated notifications from your website;
  • invoice and order emails;
  • password reset and verification messages;
  • mail reputation and domain trust.

How SPF works

SPF stands for Sender Policy Framework. It is a DNS TXT record that lists which servers are allowed to send email on behalf of a domain.

When a receiving mail server gets a message, it checks the sending IP address against the SPF record for the domain in the envelope sender or Return-Path. If the IP is authorized, SPF passes. If not, it fails or produces another result such as softfail or neutral.

Example SPF record

A simple SPF record might look like this:

v=spf1 ip4:203.0.113.10 include:mail.provider.com -all

This means:

  • v=spf1 identifies the record as SPF;
  • ip4:203.0.113.10 authorizes that IPv4 address;
  • include:mail.provider.com authorizes servers listed by another provider;
  • -all tells receivers that any other server is not allowed.

What SPF does well

  • Prevents unauthorized servers from sending mail for your domain.
  • Helps reduce spoofing and certain phishing attempts.
  • Improves deliverability when properly aligned with your actual sending infrastructure.

Limitations of SPF

  • SPF checks the sending IP, not the visible From address by itself.
  • SPF can break if you use too many includes or exceed DNS lookup limits.
  • Forwarded email can fail SPF because the forwarder changes the sending path.
  • SPF alone is not enough to fully protect domain identity.

How DKIM works

DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to outgoing email headers. The signature is verified using a public key published in your DNS zone.

Unlike SPF, DKIM is tied to the message itself. If the message is changed after signing, verification may fail. DKIM helps prove that the mail was authorized by the domain owner and not altered in transit.

Example DKIM setup

A DKIM setup usually includes:

  • a selector, such as default or mail;
  • a DNS TXT record that stores the public key;
  • an outgoing mail server configured to sign messages with the matching private key.

Example DNS name:

default._domainkey.example.com

Example DKIM TXT value:

v=DKIM1; k=rsa; p=MIIBI...

What DKIM does well

  • Helps prove that a message was authorized by the domain.
  • Survives common forwarding scenarios better than SPF in many cases.
  • Supports DMARC alignment when the signing domain matches the visible From domain.
  • Protects message integrity by detecting modification in transit.

Limitations of DKIM

  • Does not stop all spoofing by itself if misconfigured.
  • Can fail if the message is altered by mailing lists, gateways, or filters.
  • Requires both DNS and server-side signing to be configured correctly.

How DMARC works

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It uses SPF and DKIM results and adds a policy that tells receiving servers what to do if authentication does not pass.

DMARC also requires alignment. This means the domain in the visible From address must match, or closely align with, the domain used by SPF or DKIM.

Example DMARC record

A basic DMARC record might look like this:

v=DMARC1; p=none; rua=mailto:[email protected]

This means:

  • v=DMARC1 identifies the record;
  • p=none requests monitoring only, without blocking;
  • rua specifies where aggregate reports should be sent.

DMARC policy options

  • none - monitor authentication results without enforcing rejection or quarantine.
  • quarantine - ask receivers to place failing messages in spam or quarantine.
  • reject - ask receivers to reject failing messages completely.

Why DMARC is important

  • Helps prevent domain spoofing and impersonation.
  • Improves visibility through reporting.
  • Lets you enforce a stronger policy once SPF and DKIM are working correctly.

How SPF, DKIM, and DMARC work together

These three mechanisms are designed to complement each other rather than replace one another.

  • SPF verifies the sending server’s IP.
  • DKIM verifies the message signature.
  • DMARC checks whether SPF or DKIM passed and whether the authenticated domain aligns with the From address.

A message can pass DMARC if either SPF or DKIM passes with alignment. That is why DKIM is often helpful when email is forwarded, and SPF is useful for confirming the sending infrastructure.

For hosted email and control panel environments, the most reliable setup is usually:

  • a correct SPF record that includes all legitimate senders;
  • DKIM enabled for every service that sends mail as your domain;
  • a DMARC policy that starts in monitoring mode and is tightened after validation.

Common email delivery problems caused by misconfiguration

If SPF, DKIM, or DMARC are not configured properly, you may notice one or more of the following issues:

  • messages arriving in spam folders;
  • receiving servers rejecting messages with authentication errors;
  • website contact forms not delivering reliably;
  • outbound mail appearing “unauthenticated” in mail headers;
  • DMARC reports showing repeated failures from unknown sources;
  • messages from third-party services being blocked because they are not listed in SPF.

Typical causes in hosting environments

  • SPF record does not include the actual sending server IP.
  • Multiple SPF records exist for the same domain.
  • DKIM is disabled in the control panel or mail service.
  • Website scripts send email without using the domain’s authenticated SMTP service.
  • DMARC is set to reject before SPF/DKIM are fully working.
  • The From address uses a different domain than the authenticated sender.

How to check SPF, DKIM, and DMARC in a hosting control panel

If you use a hosting platform or Plesk-based environment, the exact steps may vary, but the general workflow is similar.

1. Check your DNS zone

Open the DNS management section for your domain and look for TXT records related to:

  • v=spf1 for SPF;
  • v=DKIM1 or a selector-based DKIM record;
  • v=DMARC1 for DMARC.

Make sure there is only one SPF record. If multiple SPF TXT records exist, many receivers will treat this as a failure.

2. Verify the sending server

Confirm which service actually sends your email:

  • local mail server on the hosting account;
  • SMTP relay provided by the host;
  • external mail service such as Microsoft 365, Google Workspace, or another provider;
  • application server or website form using PHP mail or an SMTP plugin.

Your SPF record must include every legitimate sending source.

3. Enable DKIM signing

In many hosting control panels, DKIM can be enabled per domain. Once enabled, the platform generates the DNS record or provides the key to publish. After propagation, outgoing emails should include a DKIM-Signature header.

If you use external email services, DKIM is usually configured in the provider’s admin panel and then published in your DNS zone.

4. Review your DMARC policy

If you are just starting, use p=none to monitor authentication results. Once you are confident that all legitimate mail passes SPF and/or DKIM, you can move to quarantine and eventually reject.

Do not set a strict policy too early, especially if multiple systems send mail from the same domain.

How to troubleshoot SPF, DKIM, and DMARC issues

When email is not delivering correctly, work through the problem step by step.

Check the message headers

Open the full message source or headers in the receiving mailbox and look for results such as:

  • spf=pass or spf=fail
  • dkim=pass or dkim=fail
  • dmarc=pass or dmarc=fail

The headers often show which server sent the message and why authentication failed.

Compare the From domain and authenticated domains

DMARC depends on alignment. If the email shows From: [email protected] but SPF or DKIM authenticates a different domain, DMARC may fail even if SPF or DKIM technically passed.

Make sure there is only one SPF record

Having more than one SPF TXT record for a domain is a common configuration mistake. Consolidate all authorized sending sources into one record.

Watch DNS lookup limits

SPF records can trigger multiple DNS lookups through includes and redirects. Exceeding the lookup limit may cause SPF to fail. If your SPF record is complex, simplify it by removing unnecessary includes or using the provider’s recommended record format.

Confirm DKIM is active for all senders

If your hosting platform signs mail, but a third-party application sends mail without DKIM, the message may fail DMARC. Each sending system should be checked individually.

Test from a real mailbox

Send a message to a mailbox you control and inspect the results in the destination’s message headers. You can also use online email testing tools to review SPF, DKIM, and DMARC status.

Best practices for hosted email

To keep email deliverability stable, follow these practical recommendations:

  • Use SMTP authentication for website and application email instead of unauthenticated local sending where possible.
  • Enable DKIM on every domain that sends mail.
  • Maintain a single, clean SPF record with all authorized senders.
  • Start DMARC with monitoring and move to enforcement gradually.
  • Keep the visible From address aligned with the authenticated domain.
  • Review DNS changes after migrations, hosting moves, or email provider changes.
  • Recheck authentication after adding CRM tools, billing systems, newsletters, or contact forms.

In managed hosting environments, mail delivery often breaks after a service change because the DNS records were not updated to match the new sender. A quick review of SPF, DKIM, and DMARC after any migration can prevent longer-term spam issues.

Example scenario: a website contact form stops delivering

Suppose a contact form on a hosted WordPress site sends messages from [email protected]. The website is hosted on one server, but the actual email account is on another provider.

Possible issue:

  • The form uses PHP mail, so the sending server IP is the website host.
  • The SPF record only authorizes the email provider, not the website host.
  • DKIM is enabled only on the mailbox provider, not on the website mail path.
  • DMARC is set to reject, so receiving servers reject the mismatched mail.

Possible fix:

  • Configure the website to send through authenticated SMTP.
  • Add the website host or mail relay to SPF if it is a legitimate sender.
  • Enable DKIM signing on the actual outgoing mail path.
  • Keep DMARC in monitoring mode until the final setup is validated.

Frequently asked questions

Do I need SPF, DKIM, and DMARC for every domain?

If a domain sends email, it should have all three where possible. Even small business domains benefit from them, especially if the domain is used for invoices, forms, password resets, or customer communication.

Can I use SPF without DKIM?

Yes, but it is not recommended. SPF alone is not enough for strong email authentication, and it can fail in forwarding scenarios. DKIM adds an important second layer.

Can DMARC work without SPF or DKIM?

No. DMARC relies on SPF and/or DKIM passing with alignment. Without them, DMARC has nothing to evaluate.

Why do forwarded emails sometimes fail SPF?

Because forwarding changes the sending IP. The forwarder is not listed in the original SPF record, so SPF may fail even if the original sender was legitimate. DKIM can help preserve authentication in these cases.

What does a DMARC policy of none do?

It does not block mail. It tells receivers to monitor authentication and send reports. This is the safest starting point when you are still validating your setup.

How long do DNS changes take to work?

DNS propagation can take minutes or longer depending on TTL values and caching. In practice, allow time for changes to spread before retesting.

Should I add multiple SPF records if I use several services?

No. Use a single SPF record and combine all valid senders into it. Multiple SPF records for the same domain usually cause problems.

Can hosting support help with these records?

Yes. In a managed hosting or control panel environment, support can often help verify DNS records, mail routing, and DKIM status. You should still know which systems are sending mail so the records reflect your real setup.

Conclusion

SPF, DKIM, and DMARC are the foundation of modern email authentication. For hosting customers, they are not just technical extras; they directly affect whether business email reaches inboxes, avoids spam filters, and resists domain spoofing.

In most cases, the best approach is to make sure your DNS zone accurately reflects all legitimate sending sources, enable DKIM signing on every mail path, and use DMARC to monitor first and enforce later. If you are troubleshooting delivery issues in a hosting control panel or Plesk environment, checking these three records should be one of the first steps.

When configured correctly, SPF, DKIM, and DMARC work together to improve trust, reduce spoofing, and make your domain’s email more reliable.

  • 0 Users Found This Useful
Was this answer helpful?